debt: use the single Etherscan V2 API endpoint for unified verification / query flow w/ single API key

[zerosnacks]

Component

Other (please describe)

Describe the feature you would like

We currently have a lot of code in place to handle multichain Etherscan verification due to the different endpoints and API keys associated with each.

With the release of Etherscan V2 there is now a single unified API endpoint: https://docs.etherscan.io/etherscan-v2 accessible with a single API key

Additional context

It is currently still in beta but worth exploring

Part of this ticket would be to double check if there are no breaking changes in the V2 API

Note: it requires passing a ?chainid=n as a parameter where n is the chain id: https://docs.etherscan.io/etherscan-v2/getting-started/v2-quickstart#if-youre-coming-from-v1

[iainnash]

Has this been started or would taking a first PR pass be helpful?

[zerosnacks]

Hi @iainnash, this is definitely something we will want to do, just outside of the scope of our 1.0 milestone due to scope of the change (I expect we can simplify quite a lot of code and likely make breaking changes). We also have to be mindful that the Etherscan API V2 is still in beta. A first PR pass to explore this would be very useful, even if it is just a draft!

[zerosnacks]

Update, diff'd against Etherscan V1, V2 removes support for - other than that all changes have been additive:

23888 (Blast Testnet)
420 (Optimism Goerli Testnet)
5 (Goerli)
59140 (Linea Goerli)

These have all been deprecated, Blast Testnet being replaced by 168587773

I think we are fine with moving ahead with the implementation

[iainnash]

Sounds good.

…

On Thu, Dec 19, 2024 at 09:47 zerosnacks ***@***.***> wrote: Update, diff'd against Etherscan V1, V2 removes support for: 23888 (Blast Testnet) 420 (Optimism Goerli Testnet) 5 (Goerli) 59140 (Linea Goerli) These have all been deprecated, Blast Testnet being replaced by 168587773 I think we are fine with moving ahead with the implementation — Reply to this email directly, view it on GitHub <#9196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCOGV6B5XVAB332AM3OL2GLMABAVCNFSM6AAAAABQS7FELGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJUGQYDAOJRGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zerosnacks]

Optimistically assigned this to you @iainnash, let me know if I misunderstood you or have any questions

[iainnash]

Yep thanks! None right now will try to get to this early next week.

[iainnash]

It seems like the best place for this to be implemented is in block-explorers unless there is a desire to move this logic into foundry core such as how sourcify is done.

[zerosnacks]

It seems like the best place for this to be implemented is in block-explorers unless there is a desire to move this logic into foundry core such as how sourcify is done.

Changes in the verification API endpoint (e.g. .submit_contract_verification binding) should be added to block-explorers if necessary but the async flow of actually interacting with the endpoint should be part of Foundry's forge-verify crate

[iainnash]

Submitted this PR to get the verification api endpoint updated to allow requesting with V2 endpoint.
foundry-rs/block-explorers#73

Next would be updating the forge-verify side of the code to support a new flag or adapter for V2.