[Compilers] bytecodehash property in metadata settings doesn't have ipfs option

[kumaryash90]

Which compiler are you using?

• zksolc
• zkvyper

Which version of Solidity or Vyper?

0.8.17

zksolc/zkvyper version?

1.3.15

Explain the issue

While the latest zksolc compiler versions have a "metadata" option in settings, it doesn't allow setting it equal to "ipfs", which is usually a default setting for solc compiler.

i.e. it should be possible to set the bytecodehash below to ipfs

zksolc: {
    version: "1.3.15",
    compilerSource: "binary",
    settings: {
      metadata: {
        bytecodeHash: "none",
      },
      optimizer: {
        enabled: true,
      },
    },
  },

Link to your repo?

No response

[idea404]

Hi @kumaryash90

Thanks for bringing this up, our team is looking into this. Adding more hash formats should be possible there as long as they are padded to 256 bits.

[kumaryash90]

@idea404 we use the encoded ipfs hash for thirdweb's contract explorer

Basically when a contract is deployed via thirdweb CLI, the compiler metadata is uploaded to ipfs (this ipfs hash matches the one appended at the end of the bytecode) -- this allows thirdweb dashboard to read the bytecode, decode ipfs hash and pull the compiler metadata from ipfs to display the source code and abi etc, for e.g. https://thirdweb.com/mumbai/0xc15a838374d694E95a17C0F1BBe1b0d35EC2Fa4A

In case of zksync, right now we store the ipfs uri for each deployed contract in a registry since we can't decode it from the bytecode. Once the ipfs option is supported, we'd be able to display zksync deployed contracts on thirdweb dashboard like other chains, as well as simplify contract verification, without resorting to a registry.

[hedgar2017]

Hey @kumaryash90, we have a few more questions to clarify the mechanics of IPFS you'd like to rely on:

1. Do you need ipfs URLs in standard JSON output?
2. What/who is responsible for uploading the metadata to IPFS storage?
3. Do you depend on CBOR or literal content enabled by the fields below?

   "metadata": {
      // Reflects the setting used in the input json, defaults to "true"
      "appendCBOR": true,
      // Reflects the setting used in the input json, defaults to "ipfs"
      "bytecodeHash": "ipfs",
      // Reflects the setting used in the input json, defaults to "false"
      "useLiteralContent": true
    },

We can be handling it all somewhat differently. Anything can break your assumptions if you have any.

[kumaryash90]

@hedgar2017

1. Yes ipfs URLs in standard JSON output would be needed
2. We upload the metadata to IPFS when deploying the contract (or while publishing on our website)
3. CBOR is how we do it right now

But let me know what will work and what won't. And how much this metadata setup will follow solc output.

[hedgar2017]

@hedgar2017

1. Yes ipfs URLs in standard JSON output would be needed

2. We upload the metadata to IPFS when deploying the contract (or while publishing on our website)

3. CBOR is how we do it right now

But let me know what will work and what won't. And how much this metadata setup will follow solc output.

Thanks for the info.

In this case it will take a little longer, as:

1. We'll have to look at how solc generates those URLs and reverse-engineer in Rust.
2. Apparently, there is no minimal IPFS Rust library.
3. CBOR is doable, but we'll have to adjust the bytecode encoding so its size is a multiple of 32 after appending it.

[kumaryash90]

hey @hedgar2017 any updates on this?

[hedgar2017]

hey @hedgar2017 any updates on this?

Not yet.

This support turned to be non-trivial on our architecture. We'll try to find resources to investigate how to implement this properly.

[kumaryash90]

Thanks @hedgar2017. Appreciate it.
Please keep me informed about any progress or how I might assist on this.

[hedgar2017]

Hey @kumaryash90, would it work if we kept IPFS hashes in these URLs in metadata (e.g. "dweb:/ipfs/QmSZ3HNGZom6N6eb8d74Y7UQAKAGRkXgbinwVVLaiuGb3S\"), and appended the IPFS hash of the metadata to the bytecode in the same manner we're doing it with keccak256?