PSE Trading: Where is the way out for zero-knowledge proofs?
Original author:@Calvin，PSE Trading Analyst
“Overall, my view is that in the short term, Optimistic rollup has the upper hand in terms of EVM compatibility, while ZKrollup is expected to be better in simple payment layers, transactions, and other specific use cases.
However, in the medium to long term, ZK rollup will win in all use cases as ZK-SNARK technology improves.
This is V god in his blog An Incomplete Guide to RollupsThe original words in the article.
ZK is the ideal of ETH. The application of Zero-Knowledge Proofs (hereinafter referred to as ZK) in the Ethereum ecosystem reveals its ability to solve the impossible triangle problem of the blockchain (ie, security, scalability and decentralization). centralization) without having to access full transaction details, improving the scalability of the system without compromising security.
The introduction of ZK has further strengthened the decentralization of the ETH system (lowering the node threshold) and ensured the decentralization and anti-censorship capabilities of the network, making ETH like a dragon into the sea and difficult to erase.
For such an important ZK, why is everyone’s experience of using it so poor, and why can’t it make any waves when it is implemented on a large scale?
1. Zero-knowledge proof rollup current problems
I attribute the reason why the current zero-knowledge proof is still in the bottleneck period to three 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 JavaScript-like status in the blockchain space, it has become the lingua franca of a new Internet of Value. With numerous tools, services, libraries, and infrastructure, the widespread application of EVM has almost become an inevitable trend in the current technology environment.
There is a saying circulating on the Internet: Everything that can be implemented in JavaScript will eventually be implemented in JavaScript.
Another important but easily confused concept is EVM compatible and EVM equivalent.
Understand the gap between the two in terms of proximity and implementation method——
Compatible: A system is able to execute and understand EVM bytecode in a way that supports smart contracts written in Solidity or other EVM languages.
Equivalent: EVM equivalence is a higher standard. An EVM-equivalent system is not only able to execute EVM bytecode, but also exactly matches the EVM in behavior and paths. All tools and libraries targeting Ethereum should also work on EVM-equivalent systems without any modifications.
EVM Equivalent Advantages and Disadvantages:
Advantage:
Full toolchain and infrastructure support: Ethereum has a large toolchain and infrastructure ecosystem, including various development tools, testing frameworks, code libraries, and services. If an L2 solution is EVM equivalent, then all these tools and services can seamlessly integrate with it, because from their point of view, this L2 solution is like another Ethereum network.
Easier to attract and migrate developers: Developers on Ethereum are already accustomed to the behavior and features of the EVM. If an L2 solution is EVM equivalent, then developers can directly use the language (such as Solidity) and tools they are already familiar with to develop on this L2 solution without learning a new programming model or language.
Better contract compatibility: Many existing Ethereum contracts rely on specific behaviors of the EVM. If an L2 solution is EVM equivalent, then these contracts can run on that L2 solution with no or minimal modifications.
Future EVM improvements and features: The EVM is still evolving and improving, and new EIPs (Ethereum Improvement Proposals) may introduce new features or optimizations. If an L2 solution is EVM equivalent, then these improvements and features can be easily implemented on this L2 solution.
Disadvantages:
The technology is more complex: EVM is a complex virtual machine whose behavior and characteristics require in-depth understanding and accurate implementation. Achieving EVM equivalence in L2 solutions may require solving some technical difficulties, such as how to simulate the behavior of EVM in a different consensus environment or network model.
Performance and Efficiency: The EVM was designed for Ethereum, and its design may not be entirely suitable for the characteristics and needs of L2 solutions. For example, the EVM uses 256-bit integers for calculations, while many zk-proof systems work more naturally on prime fields. Implementing EVM directly may require the introduction of additional operations such as range checks, which may reduce performance and efficiency.
Limitations on flexibility and innovation: Insisting on EVM equivalence may limit the flexibility and innovation capabilities of L2 solutions in certain aspects. For example, if an L2 solution wants to introduce a new feature or optimization, then it must ensure that this change does not break its EVM equivalence.
The OP wrote an article exploring EVM compatibility and EVM equivalence. At the beginning, the OP used OVM and later changed to EVM equivalence. This is also an important reason why I think the OP did not do ARB in the initial barbaric growth period. There is a gap between EVM equivalent and ARB in compatibility, but now it has been changed, and it even surpasses ARB in compatibility. mean.
From this perspective, we can also understand the importance of EVM compatibility, and even equivalence must be achieved to attract developers, thereby creating users and thus an ecosystem.
1.2 The technical environment of ZK rollup is actually immature
From the perspective of data verifiability, data verifiability is a key feature in the blockchain system, which ensures the transparency and auditability of the system.
The proof construction of ZK Rollup is relatively complex and requires that all data must be available on the chain. This ensures strong security and integrity, but also increases the complexity and cost of data storage, which is very different from the OP.
Optimistic Rollup: OP Rollup employs an optimistic strategy where transactions are assumed to be valid unless someone raises objections. This approach does not require storing all data on-chain, just enough information to allow anyone to challenge the validity of a transaction. Therefore, OP Rollup has relatively low requirements in terms of data verifiability.
ZK Rollup: ZK Rollup utilizes zero-knowledge proofs (ZK-SNARKs) to compress transactions and prove their validity. All transaction data must be available on-chain so that anyone can generate proofs of validity. If the data scale is too large and all of it is stored on the main chain, it may encounter capacity bottlenecks.
As the data size of zkSync grows, it may become unfeasible to store all data on the main chain. This may require the introduction of external data verification, thereby transforming the existing secondary verification method and reducing reliance on mainnet data.
Such changes raise new challenges: How to ensure system security while reducing reliance on main chain data?
Therefore, zkSyncs transformation to STARK was partly triggered by this, because STARK is better suited to using externally verifiable data than SNARK.
As we know from the above description, the implementation of ZK rollup also needs to rely on ETH for more ZK-friendly improvements, such as improvements to the DA layer and EVM.
1.3 In addition to ZK rollup, there are some other problems, such as efficiency problems:
In the field of blockchain, the speed of Sequencer (usually measured by the number of transactions per second, TPS) is a key indicator for evaluating the performance of the ZK system. Sequencer is responsible for the sorting and processing of transactions, and its processing capacity directly determines the throughput of the entire chain.
However, in the current implementation (Zksync), the processing power of a single sequencer is only about a few hundred transactions per second, a limitation that exposes a significant performance bottleneck.
In order to expand TPS, there are two main ways to consider: one is to continue to improve the capability 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 doing so Enhanced decentralization, but coordinating multiple Sequencers may increase latency and reduce overall TPS. This issue highlights a carefully weighed challenge of finding the right balance between improving performance and maintaining decentralization.
The development direction of ZK technology, as demonstrated by zkSync, tends to promote the decentralized Sequencer process. Such a choice will allow performance to continue to be an important bottleneck in the development of ZK technology. While employing multiple sequencers and a modular design offer some solutions, in practice complex coordination and synchronization issues may be involved. This may not only affect the response time and throughput of the system, but may also introduce new security and reliability challenges.
Performance issues remain a key challenge to be resolved. Future research and development may need to focus on how to improve the performance and scalability of the ZK system by optimizing algorithms, coordination strategies, and hardware support without sacrificing the principle of decentralization.
2. Zero-knowledge proof is the ultimate ideal of ETH
We have talked about ZKs current problems and the difficulties it faces, so what is the reason for ZKs death?
2.1
The Ethereum protocol was originally conceived as an upgraded version of cryptocurrencies, providing advanced functionality through a highly general-purpose programming language...The Ethereum protocol goes far beyond currency.
The future of ETH is not limited to being a value transfer platform, its ultimate ideal is to create a new digital world that is credible, scalable, and privacy guaranteed.
And zero-knowledge proof is a key step to help ETH move towards a higher goal. Zero-knowledge proof is not only the technological progress of ETH, but also the embodiment of its culture and philosophy. It represents 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 knowledge. This decentralized trust model could disrupt existing social, financial, and government structures and trigger a social revolution.
The current structure of Ethereum sacrifices privacy for security and convenience. ETH redefines the concept of privacy through the introduction of zero-knowledge proof. People no longer have to choose between privacy and security, but can enjoy both rights at the same time.
The implementation of ZK will allow ETH nodes a lightweight verification process to verify the validity of transactions even without knowing all the data. This can reduce the computing and storage requirements for node operation, thereby lowering the barrier to participation in the network. According to Buterin’s original words, “Mobile phones can participate in running ETH nodes.”
By reducing the hardware and maintenance requirements for node operation, ZKP helps enable more participants to join the network. This increases the decentralization of the network, thereby enhancing decentralization.
2.3
The implementation of ZK can prevent any central authority from tracking and interfering with specific transactions by protecting the privacy of transactions. In addition, decentralization further ensures that there is no single point of failure, making the network more difficult to be attacked or shut down.
Privacy protection encourages more people to participate, whether they are individuals or organizations, so that this open ecosystem can grow freely without the constraints of a central authority.
In the end, ZK makes ETH a truly global network through the integration of privacy and decentralization, with unlimited potential and elasticity, as indelible as a dragon entering the sea.
3. Zero-knowledge proves a reasonable path for future implementation
Necessity is the destination, the problem is the status quo, so what is the path?
Let me talk about the conclusion first: it is to do the ZK rollup equivalent to EVM, and wait for the current Ethereum to upgrade the ZK friendly EVM, and both sides go hand in hand to help the perfect integration of ZK technology and ETH.
3.1 The four types of ZKrollup mentioned by V God
Type 1 (full Ethereum equivalent)
Type 1 ZK-EVM strives for complete, no-compromise equivalence with Ethereum. It doesnt change any part, even if it makes generating proofs difficult.
Advantages: perfect compatibility.
Disadvantage: Long proof time.
Who is developing it? : ZK-EVM Community Edition.
Type 2 (full EVM equivalent)
Type 2 ZK-EVM pursues full equivalence to EVM, but with some changes to the external data structures.
Advantage: Exactly equivalent at the virtual machine level.
Disadvantage: 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 some compromises are made to further improve proof time and development convenience.
Advantages: Easier to build, faster proof time.
Disadvantage: more incompatibilities.
Who is developing it? : Scroll and Polygon.
Type 4 (high-level language equivalent)
Type 4 systems work by compiling directly from a high-level language and do not execute through the EVM.
Advantages: Very fast proof time.
Disadvantage: more incompatibilities.
Who is developing it? : ZKSync and Netherminds Warp project. (note, StarkNet is not even EVM compatible and is out of the discussion)
The different types of ZK-EVM present a complex set of trade-offs between compatibility and efficiency.
Type 1 aims at complete compatibility, but is subject to the long proof time, exposing the real challenge that Ethereum has not considered the ZK-friendly design.
Type 2 and Type 3 seek a balance between full compatibility and proof efficiency, showing the exploration and compromise of practical solutions under existing technical conditions.
Type 4 takes the pursuit of efficiency as the primary goal, but at the expense of compatibility, making the ecological development a little difficult.
3.2 Joint upgrade of EVM and ZK: work together to meet at the end
The best path for ETH to implement ZK involves not only the implementation of ZK EVM equivalent zero-knowledge proof, but more importantly, the upgrade and transformation of EVM itself.
ZK-friendly transformation of EVM
The ZK-friendly transformation of the EVM is a complex but necessary process. Not only does the EVM need to be equivalent to the ZK-EVM, it must also take into account the possible future development of ZK-SNARK ASICs.
Bidirectional collaboration between ZK-EVM and EVM
The synergy between ZK-EVM and EVM not only lies in technical compatibility and efficiency, but also involves the integration of developer tools, pre-compilation support and other aspects.
Step by step towards a Type 1 future
Through the continuous improvement of ZK-EVM and Ethereum itself, it is the vision of many people to gradually realize Type 1. The process may be slow, but it charts a clear path to the future.
3.3 Joint efforts and collaboration within the ecology are the light
The challenge of implementing zero-knowledge proof (ZK) on Ethereum is not just a technical issue, but an exploration to find the best path between ideal and reality. This process reveals how to gradually introduce faster and more efficient solutions while maintaining compatibility with existing infrastructure.
In this exploration process, the ideal solution is to build a ZK solution that is completely equivalent to the existing EVM, and then wait for the ZK-friendly upgrade of the EVM itself. The essence of this process is that both parties work simultaneously and move forward together, hoping to meet at some midway point.
This idea of joint efforts is not only reflected in technical implementation, but also in how to guide the entire community to develop in a more secure and scalable direction on the basis of retaining the unique value of Ethereum and the existing ecology. This process requires technical insight, strategic planning, and a keen understanding of the dynamics of the entire ecosystem.
Therefore, we can see that the landing of ZK technology on Ethereum is not only a technological innovation, but a journey of change that the entire ecosystem participates in. This journey will shape the future of Ethereum, seeking to balance innovation with stability, speed and compatibility in a blockchain environment.
4. Summary
The opening of the ZK era not only marks a new chapter in the Ethereum ecosystem, but also a historic leap. In this wave of trends, Ethereum is not only expected to surpass the existing Internet system in some aspects, but also heralds the birth of a new and more advanced connection method.
