foundry
foundry copied to clipboard
foundry-rs
Feature: Verify contracts on Sourcify by default
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.
To foster decentralization in Ethereum source-code verification and increase "full match" adoption, I am suggesting Foundry verifies the contracts on Sourcify alongside Etherscan unless another verifier is explicitly stated with --verifier or --verification-provider.
Additional context
Sourcify is an open-source multi-EVM chain smart contract verification service. The verified contract repository is accessible to everyone and pinned on IPFS, without Sourcify being the single data owner. Additionally, Sourcify makes use of the Solidity Contract Metadata and its IPFS hash appended to the bytecode to achieve "full match"es, that is, a byte-by-byte match of the original deployed source code (See in action on https://playground.sourcify.dev/)
It is important to have tooling support because if not done directly on the contract development and deployment pipeline, source code verification gets more difficult, especially because the contract metadata hash is easily affected by smaller changes.
Disclaimer: I am working on the project Sourcify
Would be great to allow parallel verification (maybe comma between providers or --disable-sourcify).
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.
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.
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 https://github.com/foundry-rs/foundry/issues/4944#issuecomment-2202915373, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGMCOC24BA5PSKG2GMBU4DZKKGNVAVCNFSM6AAAAAAYCEBZZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBSHEYTKMZXGM . You are receiving this because you commented.Message ID: @.***>
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/fastand 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. https://github.com/ethereum/sourcify/issues/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.