Author: PSE Trading Analyst: @Calvin

“In general, my own view is that in the short term, optimistic rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves.”

This is straight from Vitalik's blog, "An Incomplete Guide to Rollups."

ZK is the ideal for ETH. Zero-Knowledge Proofs (abbreviated as ZK) in the Ethereum ecosystem reveal its potential in cracking the blockchain's trilemma - the trade-off between security, scalability, and decentralization. Without need to access complete transaction details, boosting scalability without compromising security.

The introduction of ZK has strengthened the aspect of ETH's decentralized traits (lowering the entry node barriers) ensuring network dispersion and censorship resistance. It's like ETH has become a dragon at sea, nearly indestructible.

Why is ZK so critical while user experience are awful? And why ZK can't make a large-scale implementation?

I.Issues with Zero-Knowledge Proofs Rollup at Present

I attribute the current bottleneck of Zero-Knowledge Proofs to three aspects: compatibility issues, efficiency issues, and data structure issues.

1.1 “EVM compatibility” and “EVM equivalence.”

Since the Ethereum Virtual Machine (EVM) has risen to a position akin to JavaScript in the blockchain domain, it has become the universal language of the new value Internet. With numerous tools, services, libraries, and infrastructure, the widespread adoption of EVM has almost become an inevitable trend in the current technological environment.

*There is a saying on the Internet, "Everything that can be implemented with JavaScript will eventually be implemented in JavaScript."

Within this, there's an essential but easily confused concept, which is “EVM compatibility” and “EVM equivalence.”

The gap between these two can be understood in terms of “degree of closeness” and “implementation method.”

“Compatible”: A system can execute and comprehend EVM bytecode in some way, supporting smart contracts written in Solidity or other EVM languages.
“Equivalent”: EVM equivalence is a higher standard. An EVM-equivalent system not only can execute EVM bytecode but matches the EVM precisely in behavior and path. All tools and libraries designed for Ethereum should also work on an EVM-equivalent system without any modification.

Advantages and Disadvantages of "EVM Equivalence":

Advantages:

Full toolchain and infrastructure support: Ethereum boasts a massive ecosystem of toolchains 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 be integrated seamlessly, as from their perspective, this L2 solution would seem like an another Ethereum network.
Easier to attract and migrate developers: Developers on Ethereum have already accustomed to EVM's behavior and features. If an L2 solution is EVM equivalent, developers can directly use familiar languages (such as Solidity) and tools on this L2 solution without needing to learn new programming models or languages.
Better contract compatibility: Many existing Ethereum contracts depend on specific EVM behaviors. If an L2 solution is EVM equivalent, these contracts can run on it without modification or with minimal changes.
Future EVM improvements and features: EVM continues to evolve and improve, and new EIPs (Ethereum Improvement Proposals) may introduce new features or optimizations. If an L2 solution is EVM equivalent, these enhancements and features can be easily implemented on it.

Disadvantages:

Technology are more complex: EVM is a sophisticated virtual machine; its behavior and features require deep understanding and accurate implementation. Achieving EVM equivalence in L2 solutions might encounter some technical challenges, like simulating EVM behavior in a different consensus environment or network model.
Performance and efficiency: EVM was designed for Ethereum, and its design might not fully suit for L2 solutions' characteristics and needs. For example, EVM uses 256-bit integers for computation, while many zk-proof systems naturally operate on prime fields. Directly implementing EVM might require introducing additional range checks and other operations, which potentially lowering performance and efficiency.
Flexibility and innovation constraints: Sticking to EVM equivalence might limit L2 solutions' flexibility and innovative capability. For instance, if an L2 solution wants to introduce a new feature or optimization, it must ensure that this change won't break its EVM equivalence.

The OP once wrote an article exploring EVM compatibility and EVM equivalence, initially using OVM then shifted towards EVM equivalence. This is what I think why the OP didn't outdo ARB in the early wild growth stage, as it did not achieve EVM equivalence, and thus had a compatibility gap with ARB. Now it has been amended, even surpassing ARB in terms of compatibility.

From this perspective, we can understand the critical significance of EVM compatibility-achieving equivalence is crucial to attract developers, which in turn leads to users and the development of 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 the blockchain system, which ensuring the system's transparency and auditability.

The proof construction of ZK Rollup is relatively complex, requiring all data to be available on-chain. This ensures strong security and integrity but also increases the complexity and cost of data storage, which is very different compare with OP.

Optimistic Rollup: OP Rollup adopts an optimistic strategy where transactions are assumed to be valid unless someone objects. This approach does not require all data to be stored on-chain but only enough information to allow anyone to challenge the validity of a transaction. Therefore, OP Rollup's requirements for data verifiability are relatively low.

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 a validity proof. If the data size is too large, and all are stored on the main chain. It may cause a bottleneck issue.

With the growth of zkSync's data size, storing all the data on the main chain may become infeasible. This may require the introduction of external data verification, transforming the existing secondary verification method and reducing reliance on mainnet data.

The change brings about new challenges: how to ensure system security while reducing reliance on mainnet data?

Therefore, zkSync's shifted towards STARK is partly driven by this. Compared with STARK, STARK is more suitable for using external verifiable data.

From the above description, it is known that the implementation of ZK Rollup still needs to rely on ETH in aspect of more ZK-friendly improvements, such as the DA layer and improvements to EVM.

1.3 Efficiency Problems

In the blockchain field, the speed of the Sequencer (usually measured by transactions per second, TPS) is a critical metric for assessing the performance of a ZK system. The Sequencer is responsible for ordering and processing transactions. The processing capability directly determines the throughput of the entire chain.

However, in the current stage (e.g., Zksync), the processing capacity of a single Sequencer's processing is only about a few hundred transactions per second, exposing a significant performance bottleneck.

To increase TPS, there are two main approaches to consider: first, continue to enhance the capacity of individual Sequencer's , although doing so might increase the system's centralization risk; second, introduce more Sequencers to distribute the processing load. Although doing this enhances decentralization, coordinating multiple Sequencers might increase latency and decrease overall TPS. This issue highlights a challenge that needs careful balancing, namely, appropriated equilibrium between enhancing performance and maintaining decentralization.

The direction of ZK technology development, as demonstrated by zkSync, leans towards promoting decentralized Sequencer processes. This choice makes performance continue to be a significant bottleneck in the development of ZK technology. While using multiple Sequencers and modular design offers some solutions, practical operation may involve complicated coordination and synchronization issues. This might not only affect the system's response time and throughput but may also brings new security and reliability challenges.

The performance issue remains a key unresolved challenge. Future research and development may need to focus on how to improve the ZK system's performance and scalability without sacrificing decentralization principles, through optimizing algorithms, coordination strategies, and hardware support, etc.

II.Zero-Knowledge Proofs are the Ultimate Ideal for ETH

2.1

"Ethereum was initially envisioned as an upgraded version of cryptocurrency, providing advanced functionality through highly generalized programming languages. The Ethereum protocol goes far beyond the defination of currency."

ETH's future goes beyond being a platform for transferring value. The ultimate goal is to forge a trustworthy, scalable, privacy-protected new digital world.

Zero-Knowledge Proofs (ZKPs) are a critical step in helping ETH move toward higher goals. They are not only a technological advancement for ETH but also embody its culture and philosophy, representing 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 mutual understanding. This decentralized trust model may overturn existing social, financial, governmental structures, and trigger a societal revolution.

ETH redefines the concept of privacy through ZKPs, allowing people to enjoy both privacy and security without choosing between them.

The implementation of ZK will allow lightweight verification processes for ETH nodes, enabling them to verify transaction validity even without knowledge of the entire dataset. This reduces the computational and storage requirements for running node, thereby lowing the entry barrier. Quote Vitalik Buterin's words, "even phones can participate in running ETH nodes."

By lowering hardware and maintenance requirements for nodes, ZKPs enable more participants to join the network, enhancing decentralization.

2.3

ZK's implementation, by protecting the privacy of transactions, can prevent any central authority from tracking and intervening in specific transactions. Further decentralization ensures no single point of failure, making the network more resistant to attacks or shutdowns.

Privacy protection encourages more participation, whether from individuals or organizations, allowing this open ecosystem to grow freely, unrestrained by central authorities.

Ultimately, ZK, through the blend of privacy and decentralization, makes ETH a truly global network, with boundless potential and resilience, aim to a indestructible dragon in the sea.

III.Reasonable Path for Implementing Zero-Knowledge Proofs in the Future

The necessity is the endpoint, the problem is the current state. So what's the path?

The conclusion is to settle up a ZK rollup that is equivalent to EVM, and await Ethereum's ZK-friendly upgrade to EVM. By simultaneously advancing both front to facilitate the seamless integration of ZK technology and ETH, which achieving a perfect fusion.

3.1 Four Types of ZK rollup According to Vitalik Buterin

Type 1 (Fully Ethereum Equivalent)

Type 1 ZK-EVM is dedicated to being entirely uncompromised and equivalent to Ethereum, even if this makes proof generation difficult.
- Advantages: Perfect compatibility.
- Disadvantages: Long proof time.
- Who's developing? ZK-EVM Community Edition.
Type 2 (Fully EVM Equivalent)

Type 2 ZK-EVM seeks full equivalence with EVM but modifies external data structures.
- Advantages: Fully equivalent at the virtual machine level.
- Disadvantages: Improved but still slow proof time.
- Who's developing? Scroll and Polygon Hermez.
Type 3 (Almost EVM Equivalent)

Type 3 ZK-EVM is almost equivalent to EVM but makes some compromises for further improving proof time and development convenience.
- Advantages: Easier to build, faster proof time.
- Disadvantages: More incompatibility.
- Who's developing? Scroll and Polygon.
Type 4 (High-Level Language Equivalent)

Type 4 systems working by compiling directly from high-level languages, not via EVM execution.
- Advantages: Very fast proof time.
- Disadvantages: More incompatibility.
- Who's developing? ZKSync and Nethermind's Warp project. (Note: StarkNet is not even EVM compatible, so it's 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 the lengthy proof time, revealing the real challenge of Ethereum's lack of consideration for ZK-friendly design. Type 2 and Type 3 seek balance between full compatibility and proof efficiency, displaying exploration and compromise in feasible solutions under existing technological conditions. Type 4 prioritizes efficiency but does so at the cost of compatibility, making ecosystem development slightly more difficult.

Certainly, here is the English translation of the text:

3.2 Joint Upgrade of EVM and ZK: Working Together to Meet at the End

The optimal path for ETH to implement ZK not only involves the implementation of ZK proof equivalent to ZK-EVM but also focuses on the upgrade and transformation of EVM itself.

ZK-Friendly Transformation of EVM

The ZK-friendly transformation of EVM is a complex but necessary process. EVM needs to be equivalent to ZK-EVM and must also consider the potential development of ZK-SNARK ASIC in the future.
Bi-Directional Collaboration between ZK-EVM and EVM

The collaboration between ZK-EVM and EVM extends beyond technical compatibility and efficiency, involving the integration of developer tools, pre-compilation support, and other aspects.
Gradually Moving Towards the Future of Type 1

The gradual realization of Type 1 through continuous improvements in ZK-EVM and Ethereum itself is the vision of many. This process may be slow, but it outlines a clear path to the future.

3.3 Joint Effort and Collaboration within the Ecosystem Is the Bright Spot

The challenge of implementing Zero-Knowledge Proofs (ZK) in Ethereum goes beyond mere technical issue. It's an exploration to find the optimal 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 exploratory process, the ideal approach is to build a ZK solution, which is fully equivalent to the existing EVM, and then await ZK-friendly upgrade of the EVM itself. The essence of this process is the synchronized effort and progress of both sides, aiming to meet at some middle point.

This collaborative effort is not just manifested in technical implementation but also in guiding the entire community towards a more secure and scalable direction while preserving Ethereum's unique value and existing ecosystem. This process requires technical insights, strategic planning, and a keen understanding of the dynamic ecosystem.

Therefore, we can see that the implementation of ZK technology on Ethereum is not only a technological innovation but also a transformative journey involving the entire ecosystem. This journey will shape the future of Ethereum, seeking a blockchain environment that balances innovation and stability, speed, and compatibility.

IV.Conclusion

The beginning of the ZK era not only marks a brand-new chapter in the Ethereum ecosystem but also represents a historic leap. In this wave of innovation, 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 way of connection.