[EPIC] Metadata in DDO.sol adds complexity

[trentmc]

Motivation: having a separate contract for metadata adds extra complexity, both in code and in peoples' mental models. The metadata could easily be with the ERC20 datatoken smart contract itself. By doing so it would be simpler, more maintainable, easier to understand.

How: Options:

1. EIP1046 is a standard to extend ERC20 with metadata. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1046.md
2. EIP1155 is a standard where a single smart contract holds >1 different ERC20 (and ERC721) tokens. It also has metadata support (given that ERC721 needs it). 1155 is being widely adopted.
3. Leverage blob. Datatoken contract already has a blob field. Store metadata in there. Need a new function to update the blob
4. Use NFT-ized base copyright. See multi-repo-issue#22

Analysis (by Trent):

• all four are fairly simple
• (1) is probably simplest. Maintains our 1 contract : 1 token mental model. Minimizes risk in that no new solidity to write.
• (2) is simple, and uses a well-known standard. Bonus: sets up for NFTs naturally. Bonus: low gas costs. Problem: breaks 1 contract : 1 token mental model, which at first glance seems ok but at second glance has two issues: (a) could be problematic on bridges (b) doesn't have flexibility for different datatoken templates. To address (b) we could have different 1155 deployments for different templates, but that adds a lot of complexity, not good for v4, could always extend later. I don't think it it will be as much of an issue when we go to more efficient chains.
• (3) is simple too, but does mean adding a bit more custom functionality, and it's not leveraging a standard
• (4) makes sense to do for many reasons beyond just fixing metadata. It's simple and follows an existing standard.
• Summary: (2) is too complex for now. (1)(3)(4) are acceptable. (4) is best.

TODOs:

• [ ] Do multi-repo-issue#22 first, then update the TODOs here. Maybe most things are done!
• [ ] Finalize design
• [ ] Update contracts repo
• [ ] Update ocean.js
• [ ] Update ocean.py
• [ ] Update react and market
• [ ] Update docs.oceanprotocol.com and other documentation (anywhere we talk about Ocean architecture)

Notes:

• Concern: Trent was worried that it's a huge pain to search across >>1 datatoken contracts in order to populate a metadata cache (Aquarius).
• Solution: Alex reassured Trent that this can be fairly efficient // not expensive, especially because the datatoken factory has records / logs of all DT contracts that have been deployed.

[kremalicious]

To me the ideal solution would be to kill the metadata contract and store json files in IPFS/Arweave/whatever, and then reference their hashes in the ERC721 metadata. What's the reason for not doing that?

As this issue is labeled as v4 not sure what's supposed to happen here

[kaimeinke]

This has been exactly the solution Pierre Gronlier, CTO of Gaia-X, has proposed during previous talks. @trentmc has voiced an opinion on that.

[trentmc]

We can close this, now that we are using "V4 Planning" section in GSlides to track everything.

There are other issues that cover this.