Adding support to etherscan-v2 #10298
Conversation
iainnash
requested review from
DaniPopes,
klkvr,
mattsse,
grandizzy,
yash-atreya and
zerosnacks
as code owners
|
@iainnash there's a new 0.13.1 version of block-explorers released, with fix for foundry-rs/block-explorers#82 Thank you! |
| [profile.default] | ||
|
|
||
| [etherscan] | ||
| mumbai = { key = "dummykey", chain = 80001, url = "https://api-testnet.polygonscan.com/" } |
There was a problem hiding this comment.
I think would be nice to have an optional version here in EtherscanOpts too, defaults to v1. @zerosnacks wdyt?
There was a problem hiding this comment.
Makes sense, I can add that.
Testing this it’s going to be nice to use one API key against all chains.
I made a tool called chains at zora which manages api keys and rpc urls globally. May be less useful now https://github.com/ourzora/chains-cli
There was a problem hiding this comment.
I'll get in touch with Etherscan to see whether switching to V2 by default and deprecating V1 support altogether makes sense. From the documentation it appears that V2 is available on all chains I would expect them to be and all the relevant RPC methods are available. If not I would agree that using an optional version field here defaulting to V1 would be a good idea.
There was a problem hiding this comment.
I think the transition should be gradual afaik the API key they accept is only the mainnet key and it will fail with other keys which need to hit the specific instances instead.
I can reach out and confirm with them.
There was a problem hiding this comment.
we'd recommend teams to switch to V2 entirely, all other API methods are available as well for existing code to check if a contract is verified and so on
There was a problem hiding this comment.
Given the above, I would be in favor of making this a breaking change for Foundry v1.2. We can point users to how they can get a new V2 compatible API key upon verification failure and we will document it in the release notes.
There was a problem hiding this comment.
Should I default to v2 and then prepare this PR to merge in?
There was a problem hiding this comment.
I'm all for using v2, but just to note sth that we noticed on migration from v1 to v2 on our internal services:
Etherscan has the same api limits on v2 vs v1. For us this caused some breakage as on v1 the limit is per chain and on v2 (given it's only one key) it is for all combined. Not sure if this can cause problems on multichain scripts.
There was a problem hiding this comment.
good concern @sakulstra, it is something we're thinking about and monitoring as users adopt V2
for now we observe most users fare well with a few chains and retry/backoff mechanisms
Motivation
Fixes #9196
For tests to pass and to merge this pr, an update to
block-explorersis first required: foundry-rs/block-explorers#82.Solution
Add case statements and proper flags for
ev2andetherscan-v2for verifying with etherscan v2 API which sets the /mode for the backend contracts to use different URL structures and logic for interacting with the etherscan API.Added one test, need to add more or update existing tests to handle new logic.
PR Checklist