feat(forge verify-bytecode): support alternative block explorers + predeploys

[zerosnacks]

Motivation

Resolves #8482 (excl. interaction error depending on #8549)

Adds --verifier and --verifier-url arguments

Solution

• Adds support for all verification services supported by forge verify (excluding Sourcify, to be implemented in a follow-up) but opens the door for its future implementation.
• Includes a significant refactor (structure, not logic) to more closely tie verify-bytecode into the existing verification abstraction by adding a verify_bytecode method to be called on the verifier. This should make it easier to maintain.
• Moves verify command from lib into its own module.
• Adds support for skipping verification of a particular bytecode type (creation | runtime) by using --ignore.
• Support verifying predeployed/genesis contracts which do not have a creation tx. Methodology specified here: feat(forge verify-bytecode): support alternative block explorers + predeploys #8510 (comment)
• Adds various tests

[zerosnacks]

See: #8482 (comment), current PR does not address specific issue but is a strict improvement I feel.

[yash-atreya]

@zerosnacks @mattsse @mds1
I've uncovered an issue with the blockscout API. When trying to get the contract creation data such as, creator and creation tx hash, etherscan correctly returns the contract creator in case of a CREATE2 deployment. However, blockscout returns the default CREATE2 deployer address i.e 0x4e59b44847b379578588920ca78fbf26c0b4956c.

Try blockscout to get creation data of OP SystemConfig contract: https://eth.blockscout.com/api?module=contract&action=getcontractcreation&contractaddresses=0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1

VS

Try etherscan: https://api.etherscan.io/api?module=contract&action=getcontractcreation&contractaddresses=0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1&apiKey=YourApiKey

This breaks the fork simulation to get the runtime code, as the nonce is different from the actual contract creator. Verifying creation code still works though.

[yash-atreya]

@zerosnacks @mattsse @mds1 I've uncovered an issue with the blockscout API. When trying to get the contract creation data such as, creator and creation tx hash, etherscan correctly returns the contract creator in case of a CREATE2 deployment. However, blockscout returns the default CREATE2 deployer address i.e 0x4e59b44847b379578588920ca78fbf26c0b4956c.

Try blockscout to get creation data of OP SystemConfig contract: https://eth.blockscout.com/api?module=contract&action=getcontractcreation&contractaddresses=0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1

VS

Try etherscan: https://api.etherscan.io/api?module=contract&action=getcontractcreation&contractaddresses=0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1&apiKey=YourApiKey

This breaks the fork simulation to get the runtime code, as the nonce is different from the actual contract creator. Verifying creation code still works though.

Ref #8482 (comment), adding the --ignore makes much more sense now, but it is still a half-baked solution.

Moreover, adding the --ignore to run forge vb on genesis contracts, as suggested here #8482 (comment), is non-trivial since we depend upon the creation tx to run the fork sim and get runtime code. So doing --ignore creationcode, wouldn't work as runtime verification would fail with the current methodology.

What we could do is --ignore creationcode and then just directly try to match deployedBytecode from the artifact with the onchain runtime code instead of running and deploying on a fork. I think this would suffice your usecase of verifying predeployed contracts ?? @blmalone @mds1

[yash-atreya]

@mds1 replying to #8510 (comment).

Regarding constructor args, let me play it back to verify my understanding.

Yeah that's mostly right.

If those two args are not provided, default to etherscan.

Except this part. We don't default to etherscan as this would require the user passing an etherscan API key even if they're using blockscout.

Additionally, when comparing runtime bytecode equivalence, do we skip immutable references?

By skipping immutables, do you mean we don't check the immutables that are embedded in the runtime code?
If yes, then NO; we do check them. Runtime codes are compared entirely.

[blmalone]

@yash-atreya on @mds1's comment:

Additionally, when comparing runtime bytecode equivalence, do we skip immutable references? If so, this can let users pass dummy constructor arguments and simplify UX further. I think either approach (skipping vs. not skipping immutables) is ok, I don't feel strongly here

This is something we've since chatted about internally and believe it'll be a very useful feature. Skipping immutable checking is super useful for checking the runtime code without the constructor args being needed.

By skipping immutables, do you mean we don't check the immutables that are embedded in the runtime code?
If yes, then NO; we do check them. Runtime codes are compared entirely.

Exactly.

[mds1]

@yash-atreya that all sounds good!

By skipping immutables, do you mean we don't check the immutables that are embedded in the runtime code?
If yes, then NO; we do check them. Runtime codes are compared entirely.

Got it, in general I think that's the better and stronger approach. To take a step further, you can do: if no constructor arguments are passed AND no API key is passed (so forge has no constructor args), then it skips checking immutables. That would help cases like #8617. In this case you would also want to include a message in the output indicating this difference

[yash-atreya]

@mds1 @blmalone in favor of adding the feature of skipping immutable references, however as a follow on PR. The scope of this PR has already increased from supporting alternative block explorers to predeploys as well.

@klkvr please drop your final review and we can merge?

[blmalone]

@yash-atreya cool, we will look to test this asap 👍🏻

[klkvr]

lgtm

pending conflict

[blmalone]

@yash-atreya @klkvr There seems to be a test failing that's preventing a merge here.

[mattsse]

send it