New ENSIP: Contract Metadata Standard and Text Records

[NickSneo]

No description provided.

[oed]

What's the benefit of the compiled-metadata? It should already be stored in the contract bytecode. Duplicating this info on two onchain locations seems error prone?

For reference:

https://docs.sourcify.dev/blog/talk-about-onchain-metadata-hash/

[conor10]

@oed unfortunately not all metadata is on Sourcify and the contract bytecode is limited to IPFS hashes for source code. Plus, a significant amount of contract verification activity happens on Etherscan.

We want to ensure that the contract owner can be opinionated on where it resides and the format that it is in.

[oed]

@conor10 the metadata hash is set by the compiler, has nothing to do with Sourcify specifically. Imo it seems counterproductive to try to push a new standard for something that already exists and is used in practice.

[NickSneo]

@conor10 the metadata hash is set by the compiler, has nothing to do with Sourcify specifically. Imo it seems counterproductive to try to push a new standard for something that already exists and is used in practice.

Our idea is to have sources and compiler settings info available and since we already have a standard defined by solc we are reusing it here

It is true compiler stores the ipfs hash in runtime bytecode, but think of a scenario where I have not uploaded files on IPFS instead used a centralizd server and have sources on github. How do we verify the bytecode matches the compiled sources (for contract verification)?

To ensure this as long as we have sources (anywhere) and compiler settings we can verify the contract, doesn't matter if it is stored on ipfs (as required by compiler and runtime bytecode) or anywhere else

Let me know if this scenario makes sense, else what could be the other approach we can take?

[oed]

Let me know if this scenario makes sense, else what could be the other approach we can take?

Imo, the right approach to improve the situation is to improve the existing tools. For example, the solc compiler could export a CAR-file with the content that produced the metadata CID.
Shoehorning this into an ENS record feels like it's going to lead to a lot more developer confusion, when there are two competing places to look for this information.

Btw, I think the rest of your proposal makes sense 👍 It's a good idea to have more metadata available for contracts! I've tried to do something similar for Dapps hosted on ENS by recommending dapps use webmanifests: https://ethereum-magicians.org/t/new-erc-best-practices-for-dapps-dappspec/24407

[NickSneo]

Imo, the right approach to improve the situation is to improve the existing tools. For example, the solc compiler could export a CAR-file with the content that produced the metadata CID.

I will go through this, thank you!

Btw, I think the rest of your proposal makes sense 👍 It's a good idea to have more metadata available for contracts! I've tried to do something similar for Dapps hosted on ENS by recommending dapps use webmanifests: https://ethereum-magicians.org/t/new-erc-best-practices-for-dapps-dappspec/24407

https://ethereum-magicians.org/t/new-erc-best-practices-for-dapps-dappspec/24407#p-59521-immutable-subdomains-7 This really makes sense, your proposal aligns with what we are trying to achieve. Would love to get your input on our Enscribe, if we can learn something more from your proposed Dapp Spec

[NickSneo]

Tagging @kuzdogan @Arachnid , to get your inputs as well if it makes sense to include compiled-metadata or something else, some suggestion from @oed
The main thing we want to achieve is availability of sources and compiler settings (irrespective of centralised or decentralised storage is used to store sources) through ENS records, so it becomes easy to have local verification by users if they wish to

[oed]

The main thing we want to achieve is availability of sources and compiler settings (irrespective or centralised or decentralised storage is used to store sources) through ENS records, so it becomes easy to have local verification by users if they wish to

One thing I've been thinking about in terms of using ENS here would be a subdomain-resolver that lets any address <address>.example.eth automatically resolve to the IPFS metadata of the contract at that address (contenthash record).

1. The resolver parses the subdomain’s hex label into an Ethereum address.
2. It reads the contract’s runtime bytecode and extracts the CBOR trailer.
3. From the trailer it retrieves the embedded IPFS multihash, and converts it into a CID
4. Finally, it encodes and returns that CID as an ENS contenthash record (EIP-1577).

The CIDv1.sol contracts might come in handy here.

[kuzdogan]

I understand the benefit of storing the audits in the records as AFAIK there is no standard place to look for all audits. However I don't see the benefit of having the metadata/std-json in this spec.

• If it's in ipfs, you need to separately pin it on IPFS. Empirically we know people don't do this themselves for the Solidity metadata.json case.
• If the contract is verified as an exact match on Sourcify you can get the file on IPFS, pinned by Sourcify. Otherwise you can request from Sourcify, Etherscan etc. to get the necessary info.
• You also can't just trust the metadata file fetched as it's trivial to link another metadata in the spec. You still need to resolve and fetch everything, compile and verify using that metadata file if it indeed results with the same contract.
• Again, Vyper does not output a metadata.json

Also what's the motivation behind storing the proxy, ie. the resolved address? The address can change and if so you need to remember to update this field too. Instead you can just resolve onchain which address the implementation contract is in.

[NickSneo]

Hey @kuzdogan, thanks for the inputs

If it's in ipfs, you need to separately pin it on IPFS. Empirically we know people don't do this themselves for the Solidity metadata.json case.If the contract is verified as an exact match on Sourcify you can get the file on IPFS, pinned by Sourcify. Otherwise you can request from Sourcify, Etherscan etc. to get the necessary info.

What about the contract with partial match on Sourcify or verified on Etherscan, Etherscan do provide APIs to get sources but nothing to get contract metadata

You also can't just trust the metadata file fetched as it's trivial to link another metadata in the spec. You still need to resolve and fetch everything, compile and verify using that metadata file if it indeed results with the same contract.

We agree that we should push towards the best practices and decentralized way of extracting the metadata.json directly from runtime bytecode and ipfs but we want to add support for people who just uses Etherscan to verify and have sources in Github.

Probable Solution -> We remove the compiled-metadata field, and if we want to display/get ABI, sources and compiler version for any contract then on client side we can first check the ipfs address (for fully verified contracts) and if not rely on Sourcify or Etherscan APIs

Also what's the motivation behind storing the proxy, ie. the resolved address? The address can change and if so you need to remember to update this field too. Instead you can just resolve onchain which address the implementation contract is in.

Agree on this, we should remove the implementation address from the spec as it can be a hassle. Would it make sense to just have proxy type so we know how to get the implementation address?

[kuzdogan]

...but we want to add support for people who just uses Etherscan to verify and have sources in Github.

You mean you want to let people link to Etherscan/Github in this spec, or change the behavior of people who just do Etherscan/Github? If latter, I just want to emphasize it takes a lot more to change how people behave, and this spec needs direct support from tooling to make it effortless. Otherwise of course it's more than welcome to have spec that supports metadata :)

Agree on this, we should remove the implementation address from the spec as it can be a hassle. Would it make sense to just have proxy type so we know how to get the implementation address?

Yes the proxy type could make sense

[NickSneo]

Pushed a new commit to add multichain support for compiled-metadata resolver profile via cointype