NFT Signatures - remallnfts vs. search performance

Owned by Eric Butz
Last updated: Sept 08, 2021
2 min read

Solution 1. Vector table

Overview:

Pros:

  • similar architecture to addaddress

  • remallnfts works as spec'd

    • Vector can be emptied in single call without iterating through all the objects. This allows for remallnfts to work flawlessly

  • Allows transfer address and burnaddress to work as spec’d

Cons:

  • Limit on number of NFTs that can be mapped

    • Requires limit on number of NFTs that can be mapped to any single FIO Address due to vector search linear compute time on checking existing entries and checking for items to remove. Like addpubaddress vector but more limited since it iterates with a larger object

  • Requires update to support get_nfts_hash

    • Can’t do it unless all the data is duplicated in another table mapped by sha256 (fioaddress+chaincode+contractaddress+tokenid => hash)

    • If mapped, we would need an admin cleanup task these cannot be deleted with all vector entries w/ remallnfts, back to square one.

  • Does this support get_nfts_contract?

Solution 2. Multi-index container 

Overview:

Pros:

  • Unlimited NFTs due to use of multi index container

  • Good search time adding/removing small entries

  • Supports get_nfts_hash

Cons:

  • Cannot automatically remove all NFTs.

    • Can do 5 at a time, newest to oldest or vice versa

    • By making remallnfts have less custom error responses and removing some other checks I may be able to salvage enough cpu time to clean out more NFTs in a single call.

  • Updates required to remove NFTs for a FIO Address in xferaddress, burnaddress, and burnexpired.

    • For xferaddress

      • Transfer the address immediately

      • Enter the Address into the burnnfts queue.

        • This blocks the adding of new NFTs to the Address.

      • Block addition of new NFTs for that FIO Address as long as it is in the burnnfts queue

    • For burnaddress

      • Proceed with burn as currently spec’d (burn the Address immediately).

      • Enter the Address into the burnnfts queue.

        • This blocks the adding of new NFTs to the Address.

      • A new user can re-register the address, but if they attempt to add an NFT they would be blocked until the Address is cleared from the burnnfts queue.

    • For burnexpired, we would need to iterate through the burning of NFTS for every FIO Address that is getting burned

      • Proceed with burnexpired as currently spec’d (burn all Addresses even if they have mapped NFTS)

      • Enter the address into the burnnfts queue if there are NFTs.

        • This blocks the adding of new NFTs to the Address.

      • A new user can re-register the address, but if they attempt to add an NFT they would be blocked until the Address is cleared from the burnnfts queue.

TBD:

  • Need to spec out the burnnfts table

Discussion

  • Based on discussion with Adam, Pawel, and Eric:

    • Proceed with Solution #2

    • @Adam Androulidakis will spec out the NFT Signature updates required to accommodate the burnnfts queue. ( https://fioprotocol.atlassian.net/browse/BD-2839 )

    • @Adam Androulidakis spec out new burnnfts admin call ( )

    • @Casey Gardiner will spec out any updates to burnexpired (Also tracked in )