Potential schema for a key-value store based cache

[udbhav-s]

A combination of asset ownership arrays with a state keeping track of the last checked frontier for all accounts would help with fast checks for all RPC commands, while still keeping it simple to start with an empty store and build it on-demand as the metanode handles requests.

Schema

{
  "templates": {
    "<template1IpfsCid>": {
      "templateIpfsJson": {},
      "assets": {
        "<asset1BlockHash>": [send1Block, receive1Block, send2Block, receive2Block],
        // ...
      },
    },
    // ...
  },
  "accounts": {
    "ban_1nft....": {
      "lastCheckedFrontier": "B7EE.....",
    },
    // ...
  },
}

Actions

1) Get current owner of an asset

• If block hash for the asset exists in templates[assetTemplateId] get the owner of the last block in the array, else start with the mint block
• Recursively look for valid sends and update the array
• Once you reach the frontier of a receiving account that hasn't sent the NFT, return the owner of the last block in the array

2) Get ownership history of an asset

• Run (1) and return the contents of the asset array

3) Get current holders of a template

• Update blocks from lastCheckedFrontier (or from the start if it doesn't exist) of the minting account to the current frontier, and add any new assets that were minted to the template
• For all assets in the template, run (1) to update their owners
• Return owner of the last block of each asset array

4) Get all assets owned by account

• The lastCheckedFrontier of an account indicates that all prior NFT transactions in the account's history have been cached in the state, and you only need read from that block to check for new changes
• Update blocks from lastCheckedFrontier (or beginning) of the account to the current frontier, updating all the asset arrays whenever it encounters a valid send or receive
• Set current frontier to lastCheckedFrontier
• Return all assets where the last owner in the array is the account

[ghost]

I have implemented most of this. One part I left out was the ability to specify the frontier, to speed up the api calls on NFTS that we know didn't change ownership (because we own them)

#17