meta: contract verification experience

[zerosnacks]

Describe the feature you would like

Recently I wanted to verify contracts on multiple verification providers and we can improve the developer experience around this. I would argue that developers by default would want to verify everywhere at once.

We should make it very easy (a default) to at least verify automatically on Etherscan + Verifier Alliance in one go.
Because of the https://verifieralliance.org/ both Blockscout and Sourcify (Argot Collective) can be verified at once by verifying on Sourcify. Ideally Etherscan would join the Verifier Alliance but this has not yet happened.

From personal experience - what currently happens is that if a user runs into any issues they eventually find a way to work around it and because they have resolved their own problem there is little incentive to report it as an issue.

Confused on what to do next if a verification failure occurs users often end up running the deploy script again. Not many users write their scripts to be idempotent so users can easily end up deploying contracts multiple times.

Let's discuss how we can improve the developer experience around this.

Goal

Goal is to be able to create actionable items for improving the developer experience around deployment and make it feel more robust and have more helpful dialogue when things do go wrong so users know what to do

Action list

(derived from examples below)

• Make it possible to verify on Etherscan + Sourcify in one go
• Make --verifier-api-key work with --verifier etherscan
• Perform a dry-run API key check prior to running to make sure it is valid, warn the user and do not deploy

Common questions

• How do I verify on Blockscout and Etherscan at once when I run forge script --verify?
• Let's say my verification (partially) failed but my contracts deployed, how do I rerun ONLY the verification process?

Common user experiences that raise the question "uh... what do I do now?" when verifying

Verifying on Blockscout

forge script script/Counter.s.sol --rpc-url <SEPOLIA_RPC_URL> --verify --verifier blockscout --broadcast --keystore <KEYSTORE>

and I get the following

==========================

##### sepolia
✅  [Success] Hash: 0xa7486709fbb1bc28da16126aceebf91a14aa4caf97fe4129938003869a8e9a75
Contract Address: 0xC8320C3CC70dc234298Bb84616f108d61a8215E0
Block: 8383084
Paid: 0.00000147893596998 ETH (151395 gas * 0.009768724 gwei)

✅ Sequence #1 on sepolia | Total Paid: 0.00000147893596998 ETH (151395 gas * avg 0.009768724 gwei)
                                                                                                                                                                

==========================

ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.
##
Start verification for (1) contracts
Start verifying contract `0xC8320C3CC70dc234298Bb84616f108d61a8215E0` deployed on sepolia
EVM version: cancun
Compiler version: 0.8.30

Submitting verification for [src/Counter.sol:Counter] 0xC8320C3CC70dc234298Bb84616f108d61a8215E0.
Error: Encountered an error verifying this contract:
Response: `NOTOK`
Details:
                        `Missing/Invalid API Key`

My contract has been deployed but Blockscout says my API key is missing.

Ah right, okay let's retry this when passing a valid API key

forge script script/Counter.s.sol --rpc-url <SEPOLIA_RPC_URL> --verify --verifier blockscout --verifier-api-key <VALID_API_KEY> --broadcast --keystore <KEYSTORE>

[⠊] Compiling...
No files changed, compilation skipped
Enter keystore password:
Script ran successfully.

## Setting up 1 EVM.

==========================

Chain 11155111

Estimated gas price: 0.018543661 gwei

Estimated total gas used for script: 196813

Estimated amount required: 0.000003649633552393 ETH

==========================

##### sepolia
✅  [Success] Hash: 0x8c988c0cc03f5f33c4ffcc9149386338b7467ff7eee8504f29b5afab02d4c45b
Contract Address: 0x1544Fc9e63e0c1c27A6467E7e0f18aBB996f4251
Block: 8383090
Paid: 0.000001444392929805 ETH (151395 gas * 0.009540559 gwei)

✅ Sequence #1 on sepolia | Total Paid: 0.000001444392929805 ETH (151395 gas * avg 0.009540559 gwei)
                                                                                                                                                                

==========================

ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.
##
Start verification for (1) contracts
Start verifying contract `0x1544Fc9e63e0c1c27A6467E7e0f18aBB996f4251` deployed on sepolia
EVM version: cancun
Compiler version: 0.8.30

Submitting verification for [src/Counter.sol:Counter] 0x1544Fc9e63e0c1c27A6467E7e0f18aBB996f4251.
Error: Encountered an error verifying this contract:
Response: `NOTOK`
Details:
                        `Invalid API Key (#err2)|SEPOLIA-`

Still fails, no clue why.

I also deployed the contract again now.

Verifying on Etherscan

On Etherscan - contract verification failing for whatever reason, no clear instructions on what to do now.

Start verification for (1) contracts
Start verifying contract `0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653` deployed on sepolia
EVM version: cancun
Compiler version: 0.8.30

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Warning: Could not detect the deployment.; waiting 5 seconds before trying again (4 tries remaining)

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Warning: Could not detect the deployment.; waiting 5 seconds before trying again (3 tries remaining)

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Warning: Could not detect the deployment.; waiting 5 seconds before trying again (2 tries remaining)

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Warning: Could not detect the deployment.; waiting 5 seconds before trying again (1 tries remaining)

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Warning: Could not detect the deployment.; waiting 5 seconds before trying again (0 tries remaining)

Submitting verification for [src/Counter.sol:Counter] 0x3163084A4C2Fd035BCC2950B0D8aFC51a4484653.
Error: Failed to verify contract: Could not detect the deployment.

Transactions saved to: /home/user/test/broadcast/Counter.s.sol/11155111/run-latest.json

Sensitive values saved to: /home/user/test/cache/Counter.s.sol/11155111/run-latest.json

Error: Not all (0 / 1) contracts were verified!

---

forge script script/Counter.s.sol --rpc-url <SEPOLIA_RPC_URL> --verify --verifier etherscan --verifier-api-key <ETHERSCAN_API_KEY> --broadcast raising: Error: Missing etherscan key for chain 11155111

if I run with --etherscan-api-key instead of --verifier-api-key I have no issues, this is counterintuitive.

At least it does not end up deploying my contract (but why not?)

[⠊] Compiling...
No files changed, compilation skipped
Enter keystore password:
Script ran successfully.

## Setting up 1 EVM.

==========================

Chain 11155111

Estimated gas price: 0.009528402 gwei

Estimated total gas used for script: 196813

Estimated amount required: 0.000001875313382826 ETH

==========================

Transactions saved to: /home/user/test/broadcast/Counter.s.sol/11155111/run-latest.json

Sensitive values saved to: /home/user/test/cache/Counter.s.sol/11155111/run-latest.json

Error: Missing etherscan key for chain 11155111

[0xJem]

Improving this flow would be fantastic! A few thoughts:

• While it gets easier with scripts layered on top (you can see some of what we do at Olympus here (deployment) and here (verification)), just figuring out the flags for verification on Etherscan is a challenge.
• Verifying across a number of different services would be fantastic
• API key management would make this easier
  • Imagine verifying on etherscan and blockscout, and having to specify multiple API keys on every forge script call.
  • At least in my usage, API keys remain the same across projects, so it seems intuitive to have a profile/account (like cast wallet) with API keys for different services stored.
• If verification failed and I wanted to continue with the process, appending --resume seems intuitive
• Submitting to 4byte (since it can import using the ABI or source code) also seems aligned
• Project-level config in foundry.toml:
  • Whether to automatically verify upon deployment (with an override available to forge script to negate this)
  • Which services to verify with (so that it's not required with forge script)

[kuzdogan]

This great to see, thank you 🙏 Happy to contribute as much here

... (a default) to at least verify automatically on Etherscan + Verifier Alliance in one go.
Because of the https://verifieralliance.org/ both Blockscout and Sourcify (Argot Collective) can be verified at once by verifying on Sourcify.

• This is not fully accurate. Verifier Alliance is just a DB where verifiers "push" to. Pulling is optional and AFAIK none has implemented this yet. So if you verify on Blockscout/Routescan it will not necessarily appear on Sourcify and vice versa. So ideally it goes to all verifiers all at once.

...because they have resolved their own problem there is little incentive to report it as an issue.

• One way to tackle this on top of my mind is to have Github verification issue templates and lead the user to the URL to report these. The caveat would be that people report trivial errors.

users often end up running the deploy script again

• Maybe a warning and a user prompt would help here if a contract has been already deployed?

--verifier-api-key

• What do you mean with a --verifier-api-key? AFAIK blockscout does not require keys, neiter do Sourcify and Routescan. Only Etherscan does (now unified across chains with their v2)

Submitting to 4byte (since it can import using the ABI or source code) also seems aligned

• re: @0xJem
  Actually this is something we (verifiers) should've been doing, thanks for pointing this out

On a side note, we'd also love to see Foundry switch to our APIv2 (docs) which uses jobs + polling on the verification side (no hanging requests) and the lookup responses are a lot more richer (bytecodes, storageLayout, souceMaps etc.). We are deprecating the legacy API over time.

Edit: If you'll be updating the Sourcify implementation, it would be nice to have the creatorTxHash submitted alongside. Since we don't index chains we try to fetch this externally. Having it already in the req. makes things easier ethereum/sourcify#2113