bug(forge verify-bytecode): bytecode verification fails with solidity v0.8.26 optimization

[QGarchery]

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 (58bf161 2024-11-07T00:20:40.732513260Z)

What command(s) is the bug in?

forge verify-bytecode

Operating System

Linux

Describe the bug

Sometimes some constants are appended at the end of the creation bytecode. Those constants are not values of immutable variables. Here is a run in a dedicated repository with a minimal example.

Notice how the SOME_SLOT bytes are appended in v0.8.26 but not in v0.8.25.

From personal testing that I can't share at the moment, this seems to be causing forge verify-bytecode to not be able to verify a deployed contract. Are the extra bytes at the end of the creation code something that forge verify-bytecode can handle ?

If full reproducibility is needed I can try to provide another example

[zerosnacks]

Hi @QGarchery, this is possibly related to a change in the optimizer steps in solc between the versions (https://soliditylang.org/blog/2024/05/21/solidity-0.8.26-release-announcement/ introduced a new default sequence).

For reference:

0.8.25:

0x60808060405234603f577faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa805460ff19166001179055603a908160458239f35b600080fdfe600080fdfea26469706673582212206faa8db067b12b11ab75292229ab41a8cba9c2210f1082d987398b1b9542958564736f6c63430008180033

0.8.26 (and above):

0x60808060405234603857600160ff196000805160206078833981519152541617600080516020607883398151915255603a9081603e8239f35b600080fdfe600080fdfea2646970667358221220e9a8ec4a7cc1719f937319b8f1f885eda9d75c51db5993d45baf54b06816e9fc64736f6c634300081a0033aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

[grandizzy]

Per @zerosnacks comment and 0.8.26 release notes,

If you observe significantly degraded optimization quality in your project, we recommend temporarily switching back to the old sequence and opening an issue so that we can investigate.
The default sequence in Solidity v0.8.25 included the following steps:

dhfoDgvulfnTUtnIf [ xa[r]EscLM cCTUtTOntnfDIul Lcul Vcul [j] Tpeul xa[rul] xa[r]cL gvif CTUca[r]LSsTFOtfDnca[r]Iulc ] jmul[jul] VcTOcul jmul : fDnTOcmu

so that would be equivalent with following foundry.toml setting

[profile.default.optimizer_details.yulDetails]
optimizerSteps = "dhfoDgvulfnTUtnIf[xa[r]EscLMcCTUtTOntnfDIulLculVcul[j]Tpeulxa[rul]xa[r]cLgvifCTUca[r]LSsTFOtfDnca[r]Iulc]jmul[jul]VcTOculjmul:fDnTOcmu"

[QGarchery]

Using solc-0.8.26 --bin src/Counter.sol --optimize --via-ir:

60808060405234603657600160ff195f8051602060748339815191525416175f8051602060748339815191525560399081603b8239f35b5f80fdfe5f80fdfea264697066735822122002cd0c349a1b02c9105d19d5372d6283072a2f38dc38f5e802aa601bfa43107e64736f6c634300081a0033aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

adding --yul-optimizations 'dhfoD[xarrscLMcCTU]uljmul:fDnTOcmu' to the previous command, to switch back the old compiler sequence:

608060405234601b57600e6042565b604051603e9081606e8239f35b5f80fd5b90565b90602f601f603e92151590565b825460ff191660ff9091161790565b9055565b606b60017faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa6022565b56fe60806040525f80fdfea2646970667358221220fecb2398062ab49a718d83949ccc0183f5fd698078ae114215c174c0b3ec254664736f6c634300081a0033

[zerosnacks]

@QGarchery if I understand you correctly, we can mark this as resolved / not planned? If not I think a more suitable place to flag issues around this is the Solidity compiler: https://github.com/ethereum/solidity/issues as Foundry does not control bytecode generation itself and relies entirely on the compiler.

I don't think we should make forge verify-bytecode, if compiled w/ the same version, lenient to changes in the optimization sequence (either changes by default or specified by the user).

[QGarchery]

To be clear: I found that compiling and verifying with the same default values (the ones of the linked repository) does not make forge verify-bytecode go through. I understand that if different optimization sequences or different parameters are passed, then it's ok to reject the verification. But this is not what happens here, and the same optimization sequence (the default one for solidity 0.8.26) and the same compilation parameters were used.

This means that some deployed contract onchain can't be verified using forge verify-bytecode, or at least I have not found how to do it. For that reason, I don't think we can mark this issue as resolved yet

[zerosnacks]

cc @yash-atreya

[grandizzy]

@QGarchery is the 0.8.25 contract you want to verify compiled with same --via-ir as the 0.8.26 one?
If you add in https://github.com/QGarchery/appended-bytes config

[profile.default.optimizer_details.yulDetails]
optimizerSteps = "dhfoD[xarrscLMcCTU]uljmul:fDnTOcmu"

then test with 0.8.26 fails with

[FAIL: assertion failed: 0x45e6c88882654caeb66a50e076504c482d0500415a64736f6c634300081a0033 != 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa] testBytecode()

Even if not the same sequence as for 0.8.25

[FAIL: assertion failed: 0x87fb708fb633ce19687a176f46f05f07559b4e86cb64736f6c63430008190033 != 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa] testBytecode()

I don't think there's something we could do as foundry does not control this and you should probably open a solc ticket if still a problem?

[QGarchery]

Closing, you are right: this quirk of the compiler does not seem to be the issue for verifying the contract.
I used this simple contract and deployed it on base to see if it would cause an issue, and it does not:
forge verify-bytecode 0x8990DdAb0c5b5eB93cc52ba619eC7A1f00066479 Counter --rpc-url $BASE_RPC --etherscan-api-key $BASESCAN_API_KEY

Still having an issue, but I can't share much at the moment, and I can't yet pinpoint what is the problem exactly. Will open another issue when I know more.

Thanks for your help and your patience !

[grandizzy]

awesome! btw #9311 is now merged which should pick your key from foundry.toml as you mention here #8100

[kuzdogan]

Came across this from the Solidity chat. Curious, is the custom optimization sequence the reason the verification was not working? I wasn't able to fully understand if the problem is resolved. I'm also happy to help with the verification issues and want to learn more what's the issue here.