forge verify-bytecode should not require Etherscan API key

[Thegaram]

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 (f2518c9 2024-08-06T00:19:05.428689000Z)

What command(s) is the bug in?

forge verify-bytecode

Operating System

macOS (Apple Silicon)

Describe the bug

This is a bug report, but it's possible that it's a misunderstanding.

The purpose of forge verify-bytecode is to check whether the contract source code in a local repo matches the bytecode deployed on chain at a specific address. To achieve this, forge could simply compile the contract (using the local compiler, optimizer, etc. configurations), then simulate deployment, then compare the result with the on-chain bytecode.

However, when I run this command I keep getting Etherscan API key is required for verification. Why is Etherscan required for verifying the contract bytecode? Since compiler parameters could be read from foundry.toml, and constructor arguments can be provided by the user, Etherscan should be optional.

Original feature request: #6893
Original implementation: #7319

cc @mds1 @yash-atreya

[mds1]

I believe the Etherscan API key is required to also verify the init code, which is harder to fetch than runtime code, therefore it's fetched from Etherscan. The reason you have to also verify the actual initcode used is because malicious initcode can e.g. set storage slots that shouldn't be set, then still return the same runtime code. So only verifying runtime code is not a sufficient safety guarantee.

#8510 will add a feature to skip initcode verification, and when using that I'd assume you don't need the etherscan API key, but cc @zerosnacks @klkvr to confirm

[klkvr]

right, we need etherscan API to be able to fetch contract creation transaction. Knowing creation tx allows us to simulate local creation code execution at the needed block to later compare its result with on-chain runtime code

[zerosnacks]

Marking as not planned given the conversation above, the Etherscan API is a hard requirement for fetching the contract creation transaction / initcode.

Please note that in #8510 we are adding support for additional block explorers, some of who do not require an API key.

[Thegaram]

The reason you have to also verify the actual initcode used is because malicious initcode can e.g. set storage slots that shouldn't be set, then still return the same runtime code.

That makes sense, thank you! I'd like to use this command to verify a proxy's implementation contract, so storage is not relevant. But I agree it's best to default to full verification.

#8510 will add a feature to skip initcode verification

Looking forward to it!