forge verify-bytecode

[yash-atreya]

Motivation

Ref #6893

Solution

Still a WIP

1. Implement a new command forge verify-bytecode. Placing the source code for this under https://github.com/foundry-rs/foundry/tree/master/crates/forge/bin/cmd/verify as bytecode.rs

2. Use ETH_RPC_URL to get runtime bytecode, etherscan api to get the constructor arguments and configs such as EVM version, compiler version, and optimizations. (https://docs.etherscan.io/api-endpoints/contracts#get-contract-source-code-for-verified-contract-source-codes) and lastly the creation code to be extracted from the creation_tx data.

3. Re: --verfication-type flag — Sourcify indicates whether its a partial or full match. If the user has specified a different verification type to sourcify, we can either throw an error or warn and continue with partial verification as default.

4. Re: verifying runtime code by running a fork at specified --block. If the block is not specified we can fetch the creationTxHash from etherscan and then use the ETH_RPC_URL to get block, run the fork and verify runtime code.

[yash-atreya]

@klkvr @mattsse need some help here.
I'm trying to test this on WETH9. Here's the foundry project containing WETH9 local source code for it.

Here's the command I ran

RUST_LOG=info forge vb 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 WETH9 --rpc-url https://eth.merkle.io 

The creation code onchain does not match the locally built one. I'm probably missing something here, would appreciate your help.

[mattsse]

some nits

[yash-atreya]

#7326 created cyclical dependencies between forge and foundry_verify refactored VerifyBytecodeArgs to solve the issue.

[yash-atreya]

@mattsse Facing an issue with forking and deploying the contract to verify the runtime bytecode.
I get the following error when on using provider::send_transaction to deploy the contract.

Error: 
(code: -32603, message: method eth_sendTransaction not supported, data: None)

I'm probably missing something about forking and its rpc.

[yash-atreya]

Facing some issues with constructor_args and metadata_hash being in varying locations in the bytecode. Have found a possible solution that should solve it.

[Evalir]

looking good—some comments

[mattsse]

few more nits

[Evalir]

looking good to me, pending @mds1 / @mattsse / @DaniPopes

[mds1]

This is working great, looks like all my feedback has been addressed, thank you! 🙌