Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename the Solidity contract metadata.json to Blueprint #15614

Open
kuzdogan opened this issue Dec 5, 2024 · 0 comments
Open

Rename the Solidity contract metadata.json to Blueprint #15614

kuzdogan opened this issue Dec 5, 2024 · 0 comments
Labels

Comments

@kuzdogan
Copy link
Member

kuzdogan commented Dec 5, 2024

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:

  1. How to interface with this contract (ABI, userdoc, devdoc)
  2. 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:

  1. Solidity's metadata output JSON file
  2. The bytecode metadata in CBOR encoding
  3. General contract metadata such as names
  4. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants
@kuzdogan and others