One issue Scott Lewis and I have been discussing relates to the verification of deployed contracts. Currently, there exist central entities, such as Etherscan, who have a tendency to gatekeep verification mechanisms. This results in a suboptimal network experience. Rather than enabling trusted third-parties, we should instead develop a generalized verification protocol.
The protocol I have in mind is as follows:
Deploy a smart contract
Flatten this code (can be done using something like Foundry)
Wrap flattened file in checksum
Add salt which contains compiler version
Sign to verify origin
Deploy to IPFS
Frontends can then interact with IPFS to pull this payload via whichever RPC endpoint they’d prefer.
IMO, that would be part of a larger discussion regarding DID. There is no “one size fits all” solution for safety, but we can check prior works, including something like EAS.
while i agree on both @NormieHQ on the question on safety (interaction with malicious contracts)… and in relation on how…
and thus broader DID discussion.
I supposed another way of thinking would be… or addition to the COP would be.
a) given the same steps shared above… and the frontend pull the payload, that frontend would also need to do some sort of verification mech (either cross-check with others, etc); basically to filter out potential malicious codes?
b) given the same steps above… with an addition of a “code oracle” (my terminology might be wrong); but the idea of this is having this to scan through across dbs of known malicious codes or potential exploitation… from there the frontend can interact with the “oracle” to pull the IPFS and thus payload.
Hmmm… probably out of my league… lol. but just throwing out the ideas above…
It prevents people from interacting with malicious contracts by allowing them to readily verify the provenance of a contract that has been deployed on-chain as well as its associated code.
Currently, in order to verify a contract I’ve deployed, I have to go to Etherscan and do a bunch of crazy stuff that’s super complicated and annoying.
Then I have to do a bunch of additional work that I really don’t want to do with the compiler version and all that.
I hate to admit it, but in the past I’ve seen it take a day of work between a team of two of the best smart contract engineers I’ve ever seen (who are part of projects way bigger and cooler than any of mine) to simply verify a contract on Etherscan.
What a waste! Let’s automate away the annoying stuff so we can optimize the amount of time we have in a day.
I feel like this is something similar to what we are doing at Sourcify
It is open-sourced and the verified contract repository is published on IPFS.
The verification leverages the Solidity’s Contract Metadata which contains all relevant information for the compilation of the contract. By default the IPFS hash of this file is appended to the bytecode, which also acts similarly to a compilation fingerprint. Any change to the contract sources, settings etc. would change the fingerprint i.e. metadata hash. See it in action in the playground.sourcify.dev.
We support 70+ EVM chains and Canto is already a supported (and popular) Sourcify chain.
Obviously, this does not tackle the problem of preventing malicious contracts as Sourcify just verifies the given contract and does not have opinions on the code. This is another layer on top of the verification.
@zscole
Hi Zak. I’d like to ask something for your idea.
The scope of verification
Is this just checking the original source code is matched with bytecode on-chain?
Or checking the security also? like checking this contract have bad code or not.
Sign to verify origin
Why this process is needed? Why we need to check the origin? I think it just a smart contract and it is already deployed on blockchain so, we don’t need origin info.
But if scope of verification is checking security also, then it make sense for me.
Although this approach is a step in the right direction, there could be some improvements.
it could be to incorporate a decentralized naming system (DNS) or a decentralized identifier (DID) to enhance the discoverability of verified contracts. This way, users can easily access the contract information without relying solely on RPC endpoints.
