Feature Request: Automated and Semi-Automated Verification of Child Contracts Created by Factory Contracts
Introduction
Sourcify plays a pivotal role in enhancing the transparency and trustworthiness of the Ethereum ecosystem by providing smart contract verification services. However, the current process requires manual verification for each contract, including child contracts created by a factory contract. This feature request proposes two methods to streamline this process: a fully automated method and a semi-automated method.
Description
1. Fully Automated Verification Process
This method involves automatically verifying all child contracts generated by a verified factory contract. It leverages the deterministic nature of smart contracts, where the bytecode of child contracts can be accurately predicted based on the verified child contract source code that(in most cases) constitute part of the verified source code of the factory contract.
Benefits:
- Reduces manual effort and time for developers.
- Ensures consistency in contract verification.
- Enhances user confidence in contract integrity.
Implementation Considerations:
- Compile and generate the bytecode for the child contracts using the child contract source code present in the factory contract's source code.
- Implement security checks to ensure the integrity of the automated verification process.
2. Semi-Automated Verification Process (Etherscan-like Approach)
This approach requires manual verification of at least one child contract. Once a single child contract is verified, all other existing and future child contracts created by the same factory contract are automatically verified.
Benefits:
- Balances automation with manual oversight.
- Provides flexibility and control to developers.
- Streamlines the verification process for similar contracts.
Implementation Considerations:
- Integrate a system to recognize verified child contracts and apply the verification status to identical child contracts from the same factory.
- Ensure the process accounts for variations in contract creation and initialization parameters.
Impact and Benefits
Implementing these features would significantly enhance the efficiency of the contract verification process on Sourcify. It would reduce the workload for developers and increase the adoption of Sourcify as a trusted verification platform in the Ethereum ecosystem. Moreover, it aligns with the broader goal of fostering transparency and trust in blockchain technology.
Conclusion
We kindly request the Sourcify team to consider these feature proposals. The introduction of automated or even semi-automated verification processes for child contracts created by factory contracts would be a significant step forward in improving the user experience and operational efficiency of Sourcify.
View in Huly HI-483
Thanks for your input. I see and acknowledge the presented benefits but the current Sourcify implementation has several limitations making this not possible:
- Sourcify is currently based on a filesystem, meaning we can't straightforwardly add metadata to contracts in our repo that this contract is a Factory/Child.
- Sourcify is not a block explorer, meaning we don't actively listen to and index chains.
- We actually do listen to chains on our monitoring service to automatically verify contracts that are published to IPFS. In fact in this case if the child contract is verified once, we could've verified the child automatically, see Monitoring docs. However, here the limitation is that noticing a child contract creation requires trace access in the RPC and whereas external creations are detected simply be checking
tx.to==null. Even if the RPC supports traces, it is not implemented yet in Monitor.
We are actually transitioning into a DB system. Beyond many benefits, this would allow us to check if the contract being deployed is actually similar to an existing contract by directly looking at the bytecode. When that's implemented we can easily do this and this is something we want.