Description
Background
Solidity currently outputs Contract Metadata as a JSON file either with solc --metadata
flag or by having it in outputSelection
.
Example outputSelection
"outputSelection": {
"*": {
"*": [
...
"metadata"
],
}
}
One use case of the file is source code verification by appending its hash in the onchain bytecode, which acts as a "compilation fingerprint". The file contains two types of information about the contract:
- How to interface with this contract (ABI, userdoc, devdoc)
- How to reproduce this compilation (language, version, compilerSettings, sources)
Motivation
All other problems of the metadata.json aside, one problem is that the name "metadata" is generic. It is used in different places in similar contexts for different things. When one mentions "metadata" it can mean:
- Solidity's metadata output JSON file
- The bytecode metadata in CBOR encoding
- General contract metadata such as names
- NFT metadata
While the list can go longer the common ambiguity is between 1. and 2.. As we also plan to propose a separate metadata section in EOF, I thought this might be a good time to tackle this ambiguity.
Proposal
I propose to name this JSON file output by the Solidity compiler to be a "blueprint"
- "Blueprint" is not used anywhere within the Ethereum context.
- The name is a good analogy describing the file. It is indeed a description of how to build the contract.
Obviously it is not straightforward to change it overnight as it would be a breaking change. There will likely be a transition period until the community and the tooling catches up with the changes. We can discuss and weigh the advantages and disadvantages to decide if this is worth pursuing or not.