--extra-output metadata option outputs different metadata than the expected compilation JSON output with bytecode_hash = "ipfs"

[joaquim-verges]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (4fcd7e0 2022-05-26T00:04:48.079145Z)

What command(s) is the bug in?

forge build

Operating System

macOS (Apple Silicon)

Describe the bug

When outputting the solc compilation metadata using --extra-output metadata or --extra-output-files metadata the resulting metadata is not matching the bytecode IPFS hash of the compiled contract.

To reproduce in a fresh project:

forge init
forge build --extra-output metadata

then inspect the json output in out/Contract.sol/Contract.json.

I've done the same setup with hardhat and raw solcjs, both produce the expected metadata that matches exactly the IPFS hash appended to the bytecode.

For the same, empty contract, here's the metadata that hardhat outputs:

{
  "compiler": { "version": "0.8.13+commit.abaa5c0e" },
  "language": "Solidity",
  "output": {
    "abi": [],
    "devdoc": { "kind": "dev", "methods": {}, "version": 1 },
    "userdoc": { "kind": "user", "methods": {}, "version": 1 }
  },
  "settings": {
    "compilationTarget": { "contracts/Contract.sol": "Contract" },
    "evmVersion": "london",
    "libraries": {},
    "metadata": { "bytecodeHash": "ipfs" },
    "optimizer": { "enabled": false, "runs": 200 },
    "remappings": []
  },
  "sources": {
    "contracts/Contract.sol": {
      "keccak256": "0x88c53f90b24a07c57711738987ddc81838a43c4ab7b6ce2986f1b470500ebe86",
      "license": "UNLICENSED",
      "urls": [
        "bzz-raw://58178e99c552a2042318a4be96c35abdda48f5a1537a5c5c27c234b5dda43f2f",
        "dweb:/ipfs/QmTgVWYsTQyBx7PsNtmUaryTF27cjLQseyk4sxYGChd5ui"
      ]
    }
  },
  "version": 1
}

and here's the metadata that forge outputs:

{
    "compiler": { "version": "0.8.13+commit.abaa5c0e" },
    "language": "Solidity",
    "output": {
      "abi": [],
      "devdoc": { "kind": "dev", "methods": {}, "version": 1 },
      "userdoc": { "kind": "user", "methods": {}, "version": 1 }
    },
    "settings": {
      "compilationTarget": {
        "/Users/joaquim/solidity_projects/foundry_metadata_tests/src/Contract.sol": "Contract"
      },
      "remappings": [
        ":ds-test/=/Users/joaquim/solidity_projects/foundry_metadata_tests/lib/forge-std/lib/ds-test/src/",
        ":forge-std/=/Users/joaquim/solidity_projects/foundry_metadata_tests/lib/forge-std/src/",
        ":src/=/Users/joaquim/solidity_projects/foundry_metadata_tests/src/"
      ],
      "optimizer": { "enabled": true, "runs": 200 },
      "metadata": { "bytecodeHash": "ipfs" },
      "outputSelection": {},
      "evmVersion": "london"
    },
    "sources": {
      "/Users/joaquim/solidity_projects/foundry_metadata_tests/src/Contract.sol": {
        "keccak256": "0x88c53f90b24a07c57711738987ddc81838a43c4ab7b6ce2986f1b470500ebe86",
        "urls": [
          "bzz-raw://58178e99c552a2042318a4be96c35abdda48f5a1537a5c5c27c234b5dda43f2f",
          "dweb:/ipfs/QmTgVWYsTQyBx7PsNtmUaryTF27cjLQseyk4sxYGChd5ui"
        ],
        "license": "UNLICENSED"
      }
    },
    "version": 1
  }

Both hardhat and solcjs output metadata with relative paths, but forge outputs absolute paths. This seems strange to me as this metadata is supposed to be used to help re-compile the contracts on other machines, absolute paths make no sense to me here.

I've looked at the ethers-rs source and have noticed the function: with_stripped_file_prefixes

This seems relevant to my problem, is it possible that forge is not calling this function to strip the base paths out of the compilation artifacts, therefore causing a mismatch between the IPFS hash of the metadata and the IPFS hash appended to the bytecode by the compiler?

Might be totally wrong on this, but it's my best guess.

Any help on figuring out this mystery would be greatly appreciated, I can provide sample test code to compare extracted IPFS hashes from bytecode and computed IPFS hashes from a file if it helps.

[sambacha]

Try bytecodehash: none

[mattsse]

thanks for reporting

looks like gakonst/ethers-rs#1307 only fixed the problem partially.

[mattsse]

Ref #1315

[mattsse]

should be fixed by 1317

[joaquim-verges]

thanks for the quick turn around @mattsse ! Should I expect the ether-rs change to be pulled in the next forge nightly build?

[joaquim-verges]

@mattsse what's the easiest way for me to test this fix?

[mattsse]

we haven't bumped it yet on foundry

the easiest way would be to build it forge yourself with patched ethers is by following this: https://github.com/foundry-rs/foundry/blob/master/Cargo.toml#L52

then cargo build --bin forge --release and the binary will be in target/release/forge

[joaquim-verges]

@mattsse Thank you! the metadata output now has relative paths has expected.

However, I'm still not getting a match between the output metadata IPFS hash and the IPFS hash appended to the bytecode by solc.

In my investigation, I found a few issues in ethers-rs related to json serialization/deserialization. I'm going to create a new issue over there with my findings, to keep the conversation focused.

Thank you again for your hard work.

[joaquim-verges]

@mattsse FYI, opened gakonst/ethers-rs#1325 - the serialization of the compiler metadata output is altering its original contents, resulting in a different IPFS hash than the one that gets appended to the bytecode.

[onbjerg]

Is this solved?

[joaquim-verges]

Just tested it today. The new rawMetadata field is now present in the output.

I would suggest writing a test comparing the raw metadata and the parsed one. There's still some differences. Last one i noticed is a missing settings.evmVersion field.

[mattsse]

closed by gakonst/ethers-rs#1365 which added metadata string as raw string