Original Author: @Calvin, PSE Trading Analyst
"In general, my view is that in the short term, Optimistic rollup has the advantage in EVM compatibility, while ZKrollup is expected to excel in simple payment layers, transactions, and other specific use cases.
However, in the medium to long term, ZK rollup will emerge victorious in all use cases as ZK-SNARK technology improves."
This is a quote from V God in his blog post "An Incomplete Guide to Rollups."
ZK is the ideal of ETH, and the application of zero-knowledge proofs (ZK) in the Ethereum ecosystem reveals its potential in solving the impossible triangle problem of blockchain (i.e., the trade-off between security, scalability, and decentralization) without accessing complete transaction details, improving system scalability without compromising security.
The introduction of ZK further strengthens the decentralization of the ETH system (lowering the node threshold), ensuring network decentralization and resistance to censorship, making ETH like a dragon entering the sea, difficult to erase.
With ZK being so important, why do people have such a poor user experience, and why is there no significant impact on the scale of implementation?
1. Current issues with zero-knowledge proof rollup
I attribute the current bottleneck of zero-knowledge proofs to three main aspects: compatibility issues, efficiency issues, and data structure issues.
1.1 The most important and urgent issue: compatibility issues
As the EVM (Ethereum Virtual Machine) has risen to a position similar to JavaScript in the blockchain field, it has become the universal language of the new value internet. With numerous tools, services, libraries, and infrastructure, the widespread use of EVM has become an inevitable trend in the current technological environment.
There is a saying in the internet: "Anything that can be implemented with JavaScript will eventually be implemented with JavaScript."
There is also an important but easily confused concept, "EVM compatibility" and "EVM equivalence."
Understanding the difference between these two in terms of "closeness" and "implementation" —
"Compatibility": A system can execute and understand EVM bytecode in a certain way, supporting smart contracts written in Solidity or other EVM languages.
"Equivalence": EVM equivalence is a higher standard. An EVM-equivalent system not only executes EVM bytecode but also completely matches EVM in behavior and path. All tools and libraries for Ethereum should be able to be used on an EVM-equivalent system without any modifications.
Advantages and disadvantages of "EVM equivalence":
Advantages:
Complete toolchain and infrastructure support: Ethereum has a large ecosystem of tools and infrastructure, including various development tools, testing frameworks, code libraries, and services. If an L2 solution is EVM-equivalent, all these tools and services can seamlessly integrate with it because from their perspective, this L2 solution is just another Ethereum network.
Easier to attract and migrate developers: Developers on Ethereum are already accustomed to the behavior and characteristics of EVM. If an L2 solution is EVM-equivalent, developers can directly use their familiar language (such as Solidity) and tools to develop on this L2 solution without needing to learn a new programming model or language.
Better contract compatibility: Many existing Ethereum contracts rely on specific behaviors of EVM. If an L2 solution is EVM-equivalent, these contracts can run on this L2 solution without modification or with minimal modifications.
Future EVM improvements and features: EVM is still evolving and improving, and new Ethereum Improvement Proposals (EIPs) may introduce new features or optimizations. If an L2 solution is EVM-equivalent, these improvements and features can be easily implemented on this L2 solution.
Disadvantages:
More complex technology: EVM is a complex virtual machine, and its behavior and characteristics need to be deeply understood and accurately implemented. Achieving EVM equivalence in an L2 solution may require solving some technical difficulties, such as how to simulate EVM behavior in a different consensus environment or network model.
Performance and efficiency: EVM is designed for Ethereum, and its design may not be entirely suitable for the characteristics and requirements of L2 solutions. For example, EVM uses 256-bit integers for calculations, while many zk-proof systems naturally work in prime fields. Directly implementing EVM may require introducing additional range checks and operations, which may reduce performance and efficiency.
Limitations on flexibility and innovation: Adhering to EVM equivalence may limit the flexibility and innovation of an L2 solution in certain aspects. For example, if an L2 solution wants to introduce a new feature or optimization, it must ensure that this change does not break its EVM equivalence.
OP has written an article exploring EVM compatibility and EVM equivalence. Initially, OP used OVM, but later transitioned to EVM equivalence. This is also an important reason why, in the early stages, OP did not compete with ARB, as it did not achieve EVM equivalence in terms of compatibility. However, this has now changed, and there are even indications of surpassing ARB in terms of compatibility.
From this perspective, we can also understand the importance of EVM compatibility, and even the need for equivalence to attract developers and users, thereby creating an ecosystem.
1.2 The technical environment of ZK rollup is not yet mature
From the perspective of data verifiability, data verifiability is a key feature in blockchain systems, ensuring the transparency and auditability of the system.
The proof construction of ZK Rollup is relatively complex, requiring all data to be available on the chain. This ensures strong security and integrity but also increases the complexity and cost of data storage, which differs significantly from OP.
Optimistic Rollup: OP Rollup adopts an optimistic strategy, where transactions are assumed to be valid unless someone objects. This method does not require storing all data on the chain, only enough information to allow anyone to challenge the validity of transactions. Therefore, the requirements for data verifiability in OP Rollup are relatively low.
ZK Rollup: ZK Rollup uses zero-knowledge proofs (ZK-SNARKs) to compress transactions and prove their validity. All transaction data must be available on the chain so that anyone can generate a proof of validity. If the data scale is too large and all stored on the main chain, it may encounter capacity bottleneck issues.
As the data scale of zkSync grows, storing all data on the main chain may become impractical. This may require the introduction of external data verification, transforming the existing secondary verification method and reducing reliance on mainnet data.
This change has led to new challenges: how to reduce reliance on mainnet data while ensuring the security of the system?
Therefore, the transition of zkSync to STARK is also partly due to this, as compared to SNARK, STARK is more suitable for using external verifiable data.
From the above description, the implementation of ZK rollup still requires more ZK-friendly improvements on ETH, such as DA layer and EVM improvements.
1.3 In addition, ZK rollup has other issues, such as efficiency issues:
In the blockchain field, the speed of the Sequencer (usually measured in transactions per second, TPS) is a key metric for evaluating the performance of ZK systems. The Sequencer is responsible for transaction ordering and processing, and its processing capacity directly determines the throughput of the entire chain.
However, in the current implementation (Zksync), the processing capacity of a single Sequencer is only about a few hundred transactions per second, exposing a significant performance bottleneck.
To increase TPS, there are two main approaches to consider: one is to continue to increase the capacity of a single Sequencer, but doing so may increase the centralization risk of the system; the other is to introduce more Sequencers to distribute the processing load, although this enhances the decentralization feature, coordinating multiple Sequencers may increase latency and reduce overall TPS. This issue highlights a challenge that requires careful balancing to find the right balance between improving performance and maintaining decentralization.
The development direction of ZK technology, as demonstrated by zkSync, tends to promote the decentralization of the Sequencer process. Such a choice will continue to make performance an important bottleneck in the development of ZK technology. Although using multiple Sequencers and modular design provides some solutions, it may involve complex coordination and synchronization issues in practice. This may not only affect the system's response time and throughput but also introduce new security and reliability challenges.
Performance issues remain a key challenge to be addressed. Future research and development may need to focus on how to improve the performance and scalability of ZK systems through optimization algorithms, coordination strategies, and hardware support, without sacrificing the principle of decentralization.
2. Zero-knowledge proofs are the ultimate ideal of ETH
We have discussed the current issues and challenges facing ZK, so what is the reason for persisting with ZK?
2.1
"The Ethereum protocol was initially envisioned as an upgraded version of cryptocurrency, providing advanced functionality through a highly universal programming language… The Ethereum protocol far exceeds the scope of currency."
The future of ETH is not limited to being a platform for value transfer; its ultimate ideal is to create a trusted, scalable, and privacy-preserving new digital world.
Zero-knowledge proofs are a crucial step in helping ETH move towards higher goals. They not only represent technological progress for ETH but also embody its culture and philosophy. They represent a new understanding and pursuit of privacy, security, and scalability.
2.2
Traditional social structures rely on centralized institutions to establish trust. Zero-knowledge proofs allow trust to be established without the need for mutual understanding. This decentralized trust model may disrupt existing social, financial, and governmental structures, sparking a social revolution.
Currently, Ethereum's structure sacrifices privacy for security and convenience. Through the introduction of zero-knowledge proofs, ETH redefines the concept of privacy. People no longer need to choose between privacy and security; they can enjoy both rights simultaneously.
The implementation of ZK will allow lightweight verification of ETH nodes, enabling the validation of transactions even without knowing all the data. This can reduce the computational and storage requirements for running nodes, thereby lowering the barrier to network participation. In V God's words, "even a mobile phone can participate in running an ETH node."
By reducing the hardware and maintenance requirements for running nodes, ZKP helps to enable more participants to join the network. This increases the decentralization of the network, thereby enhancing decentralization.
2.3
The implementation of ZK, by protecting the privacy of transactions, can prevent any central authority from tracking and interfering with specific transactions. In addition, decentralization further ensures that there are no single points of failure, making the network more resistant to attacks or shutdowns.
Privacy protection encourages more people to participate, whether individuals or organizations, allowing this open ecosystem to grow freely, unconstrained by central institutions.
Ultimately, the fusion of privacy and decentralization through ZK makes ETH a truly global network with unlimited potential and resilience, much like a dragon entering the sea, difficult to erase.
3. Reasonable path for the future implementation of zero-knowledge proofs
Necessity is the endpoint, the problem is the current situation, so what is the path?
First, the conclusion: it is to create an EVM-equivalent ZK rollup and wait for the current Ethereum to undergo EVM-friendly upgrades, both advancing together to help the perfect integration of ZK technology and ETH.
3.1 The four types of ZK rollup as mentioned by V God
- Type 1 (Fully Ethereum-equivalent)
Type 1 ZK-EVM is committed to being fully equivalent to Ethereum without compromise. It does not change any part, even if it makes proof generation difficult.
Advantages: Perfect compatibility.
Disadvantages: Long proof time.
Who is developing it?: ZK-EVM Community Edition.
- Type 2 (Fully EVM-equivalent)
Type 2 ZK-EVM aims to be fully equivalent to EVM but with changes to external data structures.
Advantages: Fully equivalent at the virtual machine level.
Disadvantages: Improved but still slow proof time.
Who is developing it?: Scroll and Polygon Hermez.
- Type 3 (Almost EVM-equivalent)
Type 3 ZK-EVM is almost equivalent to EVM but makes some compromises to further improve proof time and development convenience.
Advantages: Easier to build, faster proof time.
Disadvantages: More incompatibility.
Who is developing it?: Scroll and Polygon.
- Type 4 (High-level language equivalent)
Type 4 systems work by compiling directly from high-level languages, bypassing EVM execution.
Advantages: Very fast proof time.
Disadvantages: More incompatibility.
Who is developing it?: ZKSync and Nethermind's Warp project. (Note: StarkNet is not even EVM-compatible and is not part of the discussion)
The different types of ZK-EVM present a series of complex trade-offs between compatibility and efficiency.
Type 1 aims for complete compatibility but is constrained by long proof times, exposing the practical challenges of Ethereum's lack of consideration for ZK-friendly design.
Type 2 and Type 3 seek a balance between complete compatibility and proof efficiency, demonstrating the exploration and compromises of practical solutions under existing technological conditions.
Type 4 prioritizes efficiency but at the cost of sacrificing compatibility, making it slightly challenging for the ecosystem to develop.
3.2 Mutual upgrade of EVM and ZK: Striving to meet at the endpoint
The best path for ETH to implement ZK not only involves the implementation of ZK-EVM equivalent zero-knowledge proofs but also crucially involves the upgrade and transformation of EVM itself.
- EVM's ZK-friendly transformation
The ZK-friendly transformation of EVM is a complex but necessary process. EVM not only needs to be equivalent to ZK-EVM but also needs to consider the potential development of ZK-SNARK ASICs in the future.
- Mutual coordination between ZK-EVM and EVM
The coordination between ZK-EVM and EVM involves not only technical compatibility and efficiency but also integration in various aspects such as developer tools and precompiled support.
- Gradually moving towards the future of Type 1
Many people envision gradually achieving Type 1 through the continuous improvement of ZK-EVM and Ethereum itself. This process may be slow, but it outlines a clear path towards the future.
3.3 Joint efforts and coordination within the ecosystem are the bright spots
The challenge of implementing zero-knowledge proofs (ZK) on Ethereum is not just a technical issue but an exploration of finding the best path between ideals and reality. This process reveals how to gradually introduce faster and more efficient solutions while maintaining compatibility with existing infrastructure.
In this exploration, the ideal solution is to build a ZK solution that is fully equivalent to the existing EVM and then wait for the EVM itself to undergo ZK-friendly upgrades. The essence of this process lies in the synchronous efforts of both parties, advancing together, with the hope of meeting at some intermediate point.
This approach of joint efforts is not only reflected in technical implementation but also in guiding the entire community towards a more secure and scalable direction while retaining the unique value of Ethereum and its existing ecosystem. This process requires technical insight, strategic planning, and a keen understanding of the dynamic nature of the entire ecosystem.
Therefore, we can see that the implementation of ZK technology on Ethereum is not just a technological innovation but a transformative journey that involves the entire ecosystem. This journey will shape the future of Ethereum, seeking to balance innovation and stability, speed, and compatibility in the blockchain environment.
4. Conclusion
The advent of the ZK era not only marks a new chapter in the Ethereum ecosystem but also a historic leap. In this wave, Ethereum is not only expected to surpass existing internet systems in some aspects but also heralds the birth of a new, more advanced way of connection.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
