Page Comparison

...

• 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 

...

• 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 nftsNFTs.

  • 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.

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

  Recommend solution 1 and get_nfts_hash endpoint removed and get_nfts_contract used alternatively  

  • For xferaddress, users would need to empty their NFTs using multiple calls to remallnfts first before they can transfer

    • 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

    • Burnexpired could skip fioaddresses that have NFTs mapped and come back to those at the end if we wanted to optimize burn.

Discussion

• • • 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.

  • Casey Gardiner will spec out any updates to burnexpired.