Feature: Verify contracts on Sourcify by default

[kuzdogan]

Component

Forge

Describe the feature you would like

I'm suggesting Foundry to verify contracts on Sourcify by default on forge create --verify or forge verify-contract, event without --verification-provider sourcify or --verifier sourcify.

IMO contracts should be verified everywhere and not Etherscan only. I am suggesting Foundry verifies the contracts on Sourcify alongside Etherscan unless another verifier is explicitly stated with --verifier or --verification-provider. Since Sourcify does not require an API key, it can be enabled by default.

Disclaimer: I am working on the project Sourcify

[iainnash]

Would be great to allow parallel verification (maybe comma between providers or --disable-sourcify).

[CodeSandwich]

One more point, Sourcify is the better default, because it works without being logged in. The current default is to require passing an Etherscan API key, to NOT need it you need to pass a --verifier sourcify parameter.

[kuzdogan]

Hey :) Can I bump this

[zerosnacks]

Hi @kuzdogan,

Generally supportive of the idea but given the amount of time it usually takes to verify these contracts I think it is unreasonable to enable multi-vendor verification by default. Ideally Foundry would be able to interface with a single API and then verify once, having that API distribute the verification to the different vendors.

IIRC there was a sort of collective of verified source code hosts planning to do something like this but I cannot find the name or reference.

A good reference for model like this is could be https://docs.flashbots.net/flashbots-protect/mev-share#examples / https://docs.flashbots.net/flashbots-protect/quick-start#faster-transactions where users just interact with rpc.flashbots.net/fast and then the API shares it with all registered builders.

Sourcify is in a good spot to propose something like this, if it isn't doing it already.

[iainnash]

Sourcify does this quite well but unfortunately etherscan has not integrated.

…

On Tue, Jul 2, 2024 at 13:39 zerosnacks ***@***.***> wrote: Hi @kuzdogan <https://github.com/kuzdogan>, Generally supportive of the idea but given the amount of time it usually takes to verify these contracts I think it is unreasonable to enable multi-verification by default. Ideally Foundry would be able to interface with a single API and then verify once, having that API distribute the verification to the different vendors. IIRC there was a sort of collective of verified source code hosts planning to do something like this but I cannot find the name or reference — Reply to this email directly, view it on GitHub <#4944 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCOC24BA5PSKG2GMBU4DZKKGNVAVCNFSM6AAAAAAYCEBZZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBSHEYTKMZXGM> . You are receiving this because you commented.Message ID: ***@***.***>

[kuzdogan]

Hi @kuzdogan,

Generally supportive of the idea but given the amount of time it usually takes to verify these contracts I think it is unreasonable to enable multi-vendor verification by default. Ideally Foundry would be able to interface with a single API and then verify once, having that API distribute the verification to the different vendors.

Hey thanks for the response! Do you mean verification times in general or Sourcify specifically? Admittedly our infra is not doing well in terms of speed, but we're moving and hopefully in a few weeks we'll be more responsive.

One additional consideration here is that our current API does not have a ticketing/receipt system and the requests hang until the verifications complete. This is quite suboptimal but that's something we inherited from the old codebase but will be different in our v2 API.

IIRC there was a sort of collective of verified source code hosts planning to do something like this but I cannot find the name or reference.

Yes you are referring to Verifier Alliance :) We're part of the collective. The shared database is still in the making. The idea there is that each Verifier pushes the contracts they receive to the DB. So it wouldn't matter if you verify on Sourcify, Blockscout or Tenderly.

A good reference for model like this is could be https://docs.flashbots.net/flashbots-protect/mev-share#examples / https://docs.flashbots.net/flashbots-protect/quick-start#faster-transactions where users just interact with rpc.flashbots.net/fast and then the API shares it with all registered builders.

Sourcify is in a good spot to propose something like this, if it isn't doing it already.

Yes we are actually considering pushing automatically to Etherscan if a contract gets verified on us. A lot of people have been asking this and it's been a common misconception. For us, the more verifiers have the contract, the better.

Also we are building a "unified" verification plugin in Remix in this direction. ethereum/sourcify#1331 Instead of "Etherscan" "Sourcify" plugins where will be a single verification plugin that supports all, and by default submit to verification on all of them.

[kuzdogan]

Hello again, is there any progress on this?

In the meantime, we released the "unified" Remix plugin in the same manner: https://x.com/SourcifyEth/status/1849450860600021229

If you need any help or input from our side please let me know.

[kuzdogan]

Amazing! Thanks a lot

Just, can't we still keep Sourcify verification on, even when the Etherscan api keys are passed?

In the Remix plugin above, the rationale is that by default you verify it everywhere, unless you explicitly turn off.