feat(forge verify-contract): --guess-constructor-args

[klkvr]

Component

Forge

Describe the feature you would like

It would be convenient to have an option to specify --guess-constructor-args flag on forge verify-contract command which will try to find constructor arguments for contract without need to explicitly provide them when running the command.

It can be done in 3 steps:

1. Fetch contract deployment transaction with Etherscan API: https://docs.etherscan.io/api-endpoints/contracts#get-contract-creator-and-creation-tx-hash
2. Fetch contract creation code from transaction
3. Use contract ABI to calculate length of abi-encoded constructor arguments and take a suffix of creation code with this length.

The most interesting part is fetching the creation code (step 2). For contracts deployed by EOAs it is pretty simple (we can just take tx.data field). But for contracts deployed with CREATE/CREATE2 it would require tracing of transaction execution which takes time and requires endpoint with archive data which is not available to everyone.

It might also make sense to add a CLI command forge get-constructor-args <CONTRACT> <CREATION_CODE> which will basically perform a step 3 above. This might be useful because users may have init code from broadcast artifacts or Etherscan UI

Additional context

No response

[PaulRBerg]

This feature would be extraordinarily helpful.

The most difficult part about verifying contracts is the ABI-encoding of the constructor params. We need to resort to complicated nested terminal commands like this:

forge verify-contract ADDR \
--constructor-args \
$(cast abi-encode ...)

[Evalir]

agreed this would be super helpful—are you up for it @klkvr ?

[klkvr]

sure! but i have a lot of stuff on me atm, so i could start with it in a week or two

[Evalir]

yep no rush—everyone's on the holidays rn. Feel free to go at it whenever! will assign so we don't lose track

[klkvr]

Hey @Evalir I have opened PR to support fetching of contract creation tx for block-explorers.

I will also need to somehow be able to get access to RPC-endpoint of the corresponding network to get/trace deployment tx. It seems that it is not possible to get rpc endpoint from configuration by chain_id without iterating over each of endpoints and comparing eth_chainId response.

I can see 2 ways to solve this:

1. Force users to specify --rpc-url when --guess-constructor-args is used.
2. Add logic to query Etherscan geth proxy using the same endpoint and API key

Option 1 messes up UX a little bit. But it might be a good thing because it will be clear that there is some additional RPC stuff going on under the hood.

Option 2 is better for UX but hard to implement in a clean way because Etherscan Geth proxy doesn't work as a standard RPC-endpoint, you have to specify method as a query parameter, so we can't just reuse the same logic as for usual RPC-endpoints. Also, Etherscan doesn't support archive eth_getStorageAt queries, so verification of contracts created by contracts won't work.

Do you see any other options and what do you think about those?

[Evalir]

Hmmm, yeah I think we can go with option one—we can add a little note on the --guess-constructor-args that lets the user know why this needs --rpc-url, even if it's a little bit cumbersome @klkvr