search

bobanetwork / boba_legacy

Monorepo implementing Boba, a compute layer for Ethereum
https://boba.network
MIT License
61 stars 59 forks source link

ERC721 Metadata and NFT Bridges #13

Open souradeep-das opened 2 years ago

souradeep-das commented 2 years ago

Categorizing ERC721s into three types on the basis of metadata, as per our interests

  1. ERC721 with derivable metaData (more common) tokenURI returns in the form baseURI + tokenID
  2. ERC721 with custom metaData not 1) andtokenURI is unique for each token (non-derivable on-chain) or is dependent on custom salt or fully on-chain metadata
  3. ERC721 with no metadata (non- ERC721Metadata)

Currently, we can support 1). With the StandardERC721 representation, the baseURI can be specified while deploying the representation on the opposite layer. so, metadata can be derivable for representation ERC721s on the other side

We also support 3). However - the representation ERC721 would still be ERC721Metadata compliant and would return "" for tokenURI, which we can avoid by having a second plain ERC721Standard(without metaData interfaces). Associated with #12, checks to make sure both original-representation contracts comply to same ERC165 ids can be made on registerPair()

We do not have support for 2). yet. Some forms of these - which do not confirm to the type 1) but still can be fully derived with existing data - can be supported with the customERC721 here - #8

Other forms - where the metadata generated depends on unique user/oracle inputs (for example Turing Monsters) might require - sending this extra data between layers ( just so because this metadata cannot be generated one the representation ERC721) However, To make the bridge support generally all-kinds of these ERC721s we need to send the tokenURI between the layers (since the bridge cannot or doesn't know how to access the unique salts)

Approach -1 could be- If the ERC721 confirms to ERC721Metadata, get the tokenURI and add a new param while sending the xDomain message. If it doesn't send "". On the message receiving end -make the bridge: mint + setTokenURI on the representation ERC721.

Approach -2 To further reduce gas, since most of the ERC721s confirm to the baseURI+tokenId, format - sending over tokenURI for each could just be wasting gas. With this approach we separate and provide choice to either bridge With/Without Metadata. and we keep baseURI on representation contract to allow resolving

baseURI contracts non baseURI (onchain)
with Metadata overriden by baseURI sets to actual metadata
without Metadata baseURI handles data sets to empty metadata

The problem though is with sending over the tokenURI of contracts like (TuringMonsters - which have onchain metadata and rely on inputs/salt etc to recreate the metadata)

The onchain tokenURI for these will be too long, taking up gas 10x, and so maybe communicating the metadata directly may not be usable. other on-chain NFTs could have dynamic metadata factors which might make it hard to use anything but the tokenURI - which i think makes it hard to have a general bridge for every on-chain ones? (unless they can be fully derived on the opposite layer)

For Turing monsters specifically, to make it bridgeable then, i think would require a customised solution? Which would mean- specifying a notion - to work with the NFT Bridges an on-chain ERC721 would need to reveal a second method with encoded salt data it wants to pass?

Ideas, concerns, suggestions? any other approaches? did I miss something? Is it worth adding either approach-1 or approach-2 for supporting the smaller set of NFTs

souradeep-das commented 2 years ago

although it's hard to generalize the bridge for these custom metadata ERC721s, one possible approach could be -

  1. For these specialized ERC721s in discussion have the requirement of a special method called 'bridgeExtraData()' to enable metadata or data transfer between layers. If there is a need for multiple seed/data to be transferred, the bridgeExtraData() needs to expose the final encoded data that will be sent along.
  2. Provide this option to the users - to, for instance, withdrawWithExtraData() on the NFTBridges - where if the contract declares an bridgeExtraData() method, use the encoded data on the xDomain message, if not try sending the tokenURI. This works as an override
  3. the handling of this extraData could depend on the representation contract on the other side, extraData can be passed along with the mint() method

The representation contract on the other layer choses to use this extra data or not, so the data doesn't impact the message, or even if someone isn't aware of this.

The goal could be to - not have a necessity of ERC721s to comply with a standard to be bridge compatible, if we can preserve that for almost all types of ERC721s, and require compliance for only a small fraction of special ones, could be a good direction