[Deployment] Generating metadata hash from compiler metadata

[akroeger-circle]

Team or Project

No response

Environment

Mainnet

L2 block number

No response

zkSolc Version

1.3.19

zksync-ethers Version

na

Minimal Reproducible Code or Repo Link

Command to extract metadata:

cat "$(jq -jr '.buildInfo' artifacts-zk/contracts/path/to/Contract.sol/Contract.dbg.json | sed 's|^\.\./\.\./\.\./|artifacts-zk/|')" | jq -jr '.output.contracts["contracts/path/to/Contract.sol"].Contract.metadata' > Contract.json

Metadata schema:

{
  "optimizer_settings": "LOREMIPSUM",
  "solc_metadata": "{\"compiler\":{\"version\":\"0.6.12+commit.27d51765\"},\"language\":\"Solidity\"...",
  "zk_version": "1.3.19"
}

Does this work on other EVMs? (If yes, please list at least 1 of them)

NA

Description of What Your Contract Does

No response

Additional Details

By default, it appears that zkSolc will append a keccak256 hash to the end of the compiled bytecode.

How can this hash be generated using metadata in hardhat-zksync artifacts? Is the metadata extracted above the correct item to hash?

[gleenai[bot]]

To generate the metadata hash from the compiler metadata in a hardhat-zksync environment, you are indeed on the right track by extracting the metadata from the compiler artifacts. The metadata hash is typically a keccak256 hash of the contract's metadata, which includes details about the compiler version, optimization settings, and other relevant contract details.

Here’s how you can generate the hash:

1. Extract the Metadata: You've already outlined the command to extract the metadata from the hardhat-zksync artifacts. Ensure that the metadata JSON you extract contains all the necessary information about the contract.

2. Generate the Hash:

   • You can use a JavaScript library like ethers.js to compute the keccak256 hash of the metadata string. Here’s a simple example using ethers.js:

     const { ethers } = require('ethers');
     const metadata = require('./path/to/Contract.json'); // adjust path as necessary
     const metadataString = JSON.stringify(metadata);
     const metadataHash = ethers.utils.keccak256(ethers.utils.toUtf8Bytes(metadataString));
     console.log(metadataHash);

3. Verify the Hash:

   • Ensure that the hash you compute matches the hash appended to the bytecode by zkSolc. This can be checked by comparing it with the hash present in the deployed contract bytecode if available.

The metadata you've extracted seems appropriate for generating the hash. Make sure that the JSON string used for hashing is correctly formatted and includes all relevant contract metadata as expected by the zkSolc compiler.

For more detailed guidance and troubleshooting, you might want to visit the ZKsync developers discussions on Github.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[MexicanAce]

Hi @akroeger-circle 👋 ! You are correct that the metadata field you've found contains the information needed for this hash. You can find the struct Metadata here in the era-compiler-solidity Rust code to confirm: https://github.com/matter-labs/era-compiler-solidity/blob/a6bb196b2a0ac60aece76442924707137d37b858/era-compiler-solidity/src/project/contract/metadata.rs#L11

I'm not entirely sure the exact shell code needed to replicate the generation of this keccack256 has from the JSON/string form of the metadata, but here's the Rust version of converting the Metadata JSON into bytes and then into the hash: https://github.com/matter-labs/era-compiler-solidity/blob/a6bb196b2a0ac60aece76442924707137d37b858/era-compiler-solidity/src/project/contract/mod.rs#L109

Note that serde_json uses the same order as the struct's field definition unless explicitly modified and that serde_json::to_vec serializes the data into a canonical byte format.

[MexicanAce]

It might be helpful to also provide additional context into why you want to recreate this hash, as this hash generation is not something we generally see developers attempt to recreate.

[akroeger-circle]

Thanks @MexicanAce! I was able to figure it out.

I'm using an older version of the compiler, so the schema matches an older version of the metadata struct--this one here:

https://github.com/matter-labs/era-compiler-solidity/blob/f7573459d185cea382c3daf95c59ace1f86b8322/src/project/contract/metadata.rs

The JSON outputted by hardhat-zksync in the artifacts has the JSON keys in the wrong order.

The Rust schema is:

{
  "solc_metadata: "",
  "zk_version": "",
  "optimizer_settings": ""
}

The hardhat artifact metadata schema is:

{
  "optimizer_settings": "",
  "solc_metadata: "",
  "zk_version": ""
}

Arranging the keys in the correct order allows the hash to be generated such that it matches the compiled bytecode.

[akroeger-circle]

I'm not sure if that's still the case in the latest version of the Hardhat extension, but could be worth checking.