You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose a feature for the zkSync block explorer that automatically verifies all instances of a child contract once the initial instance has been verified. Currently, on zkSync, each deployment of a child contract created by a factory contract requires individual verification. This process can be quite repetitive and time-consuming, especially for projects that frequently deploy new instances of the same contract e.g. a pool contract created by a pool factory.
🤔 Rationale
The rationale behind this feature is to streamline the developer experience and reduce the redundancy in the contract verification process. On Etherscan, once a contract is verified, all subsequent deployments of the same contract (with the same bytecode) are automatically recognized and marked as verified. This approach significantly eases the burden on developers, as they don’t need to repeatedly verify each instance of a contract that has already been verified once. Adopting a similar feature in the zkSync block explorer would greatly enhance usability and efficiency, particularly for projects involving factory patterns or multiple deployments of identical contracts.
📋 Additional Context
This feature would be particularly beneficial in environments where contracts are frequently cloned or deployed en masse, such as in DeFi projects, NFT collections, or any other application utilizing factory contracts for creating multiple instances of the same contract. The current requirement to verify each deployed instance separately can act as a bottleneck and deter developers from utilizing zkSync to its full potential. Implementing this feature would align zkSync's developer tools more closely with industry standards and improve its overall attractiveness as a Layer 2 solution.
The text was updated successfully, but these errors were encountered:
Improving automation certainly brings benefits, but it's also important to understand its impact on the overall performance of the platform. Is there a potential increase in workload or a decrease in performance with the addition of these features?
How can these features affect projects that may have different verification needs? It's important to understand the overall impact on the ecosystem.
🌟 Feature Request
📝 Description
I would like to propose a feature for the zkSync block explorer that automatically verifies all instances of a child contract once the initial instance has been verified. Currently, on zkSync, each deployment of a child contract created by a factory contract requires individual verification. This process can be quite repetitive and time-consuming, especially for projects that frequently deploy new instances of the same contract e.g. a pool contract created by a pool factory.
🤔 Rationale
The rationale behind this feature is to streamline the developer experience and reduce the redundancy in the contract verification process. On Etherscan, once a contract is verified, all subsequent deployments of the same contract (with the same bytecode) are automatically recognized and marked as verified. This approach significantly eases the burden on developers, as they don’t need to repeatedly verify each instance of a contract that has already been verified once. Adopting a similar feature in the zkSync block explorer would greatly enhance usability and efficiency, particularly for projects involving factory patterns or multiple deployments of identical contracts.
📋 Additional Context
This feature would be particularly beneficial in environments where contracts are frequently cloned or deployed en masse, such as in DeFi projects, NFT collections, or any other application utilizing factory contracts for creating multiple instances of the same contract. The current requirement to verify each deployed instance separately can act as a bottleneck and deter developers from utilizing zkSync to its full potential. Implementing this feature would align zkSync's developer tools more closely with industry standards and improve its overall attractiveness as a Layer 2 solution.
The text was updated successfully, but these errors were encountered: