bug(forge verify-bytecode): partial bytecode verification not working as expected

[blmalone]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge verify-bytecode "$address" "$contract_name" --rpc-url "$MAINNET_RPC_URL" --json

What command(s) is the bug in?

forge verify-bytecode

Operating System

macOS (Apple Silicon)

Describe the bug

Steps to reproduce

# Clone optimism repo and compile the contracts 
git clone https://github.com/ethereum-optimism/optimism
cd optimism
git checkout op-contracts/v1.3.0
pnpm clean
pnpm install
pnpm build
cd packages/contracts-bedrock
rm -rf lib/
forge clean
forge install
forge build

# This should have matched=true on a partial verification
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url "$MAINNET_RPC_URL" --json

git checkout op-contracts/v1.2.0
rm -rf lib/
forge clean
forge install
forge build
# This should have matched=false on a partial verification - but it returns 'true'. 
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url "$MAINNET_RPC_URL" --json

Notice that SystemConfig has completely different source code at each of these optimism repo tagged commits:

• v1.2.0: https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.2.0/packages/contracts-bedrock/src/L1/SystemConfig.sol
• v1.3.0: https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.3.0/packages/contracts-bedrock/src/L1/SystemConfig.sol

Actual Results

First forge verify-bytecode command output with tag op-contracts/v1.3.0:

[{"bytecode_type":"creation","matched":true,"verification_type":"partial"},{"bytecode_type":"runtime","matched":true,"verification_type":"partial"}]

Second forge verify-bytecode command output with tag op-contracts/v1.2.0:

[{"bytecode_type":"creation","matched":false,"verification_type":"full","message":"Creation code did not match - this may be due to varying compiler settings"},{"bytecode_type":"runtime","matched":true,"verification_type":"partial"}]

	v1.2.0	v1.3.0
Actual Creation Code Match	No	Yes
Actual Runtime Code Match	Yes	Yes

Expected Results

	v1.2.0	v1.3.0
Expected Creation Code Match	No	Yes
Expected Runtime Code Match	No	Yes

[blmalone]

@zerosnacks @yash-atreya When can we expect a fix for this?

It's a tool we would like to use on internally. Right now, it's not in a condition that we can reliably say we trust.

[blmalone]

@zerosnacks @yash-atreya
Maybe you can also provide some clarity to me on the following example:

The OptimismMintableERC20Factory.sol contract doesn't verify as I'd expect against the given optimism repo commit e6ef3a900c42c8722e72c2e2314027f85d12ced5. Etherscan link.

Expected Result:
I'd expect that both the creation and the runtime bytecode match partially.
e.g.

[
    {"bytecode_type":"creation","matched":true,"verification_type":"partial"}, 
    {"bytecode_type":"runtime","matched":true,"verification_type":"partial"}
]

Actual Result:
The creation code matches partially but the runtime code does not match. In fact, it attempts a full match on the runtime code after a partial match on the creation code.

cd optimism/packages/contracts-bedrock
rm -rf lib && git checkout e6ef3a900c42c8722e72c2e2314027f85d12ced5 && forge clean && forge build

Run the verify script:

forge verify-bytecode 0xE01efbeb1089D1d1dB9c6c8b135C934C0734c846 OptimismMintableERC20Factory --etherscan-api-key $ETHERSCAN_API_KEY --json

Output of the script:

[
  {
    "bytecode_type": "creation",
    "matched": true,
    "verification_type": "partial"
  },
  {
    "bytecode_type": "runtime",
    "matched": false,
    "verification_type": "full",
    "message": "Runtime code did not match - this may be due to varying compiler settings"
  }
]

[yash-atreya]

@blmalone

I have a partial fix up, sorry for the delay. #8402.

[blmalone]

@yash-atreya Thanks - I don't think #8402 should close this issue but it's good to get that json print message fixed 👍🏻

[blmalone]

@yash-atreya Can confirm all test cases listed above are now working as expected. Thanks.