PSE Trading: Where is the way out for zero-knowledge proofs?

Original post by @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 and long term, ZK rollup will win in all use cases with the improvement of ZK-SNARK technology. "

These are the original words of God V in his blog "An Incomplete Guide to Rollups".

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.

PSE Trading: Where is the way out for zero-knowledge proof?

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 enter the sea like a dragon and be difficult to erase.

With such an important ZK, why does everyone have such a bad experience in using it, and the large-scale implementation can’t cause any waves?

1. Zero-knowledge proof rollup current problem

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 main and most pressing issue: Compatibility issues

As the EVM (Ethereum Virtual Machine) has risen to Java-like status in the blockchain space, it has become the lingua franca of the new internet of value. With numerous tools, services, libraries, and infrastructure, the widespread use of EVM has almost become an inevitable trend in the current technology environment.

There is a saying circulating on the Internet: "Anything that can be implemented in Java will be implemented in Java in the end".

Another important but confusing concept is "EVM compatibility" and "EVM equivalent".

Understand the gap between the two from the "closeness" 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 bar. An EVM-equivalent system is not only capable of executing EVM bytecode, but also exactly matches the EVM in behavior and path. All tools and libraries targeting Ethereum should also work on EVM equivalent systems without any modification.

"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 have become accustomed to the behavior and characteristics 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 behavior of the EVM. If an L2 solution is EVM equivalent, then these contracts can run on this L2 solution with no or minimal modification.
  • Future EVM improvements and features: EVM is still evolving and improving, and new EIPs (Ethereum Improvement Proposals) may introduce new features or optimizations. These improvements and features can be easily implemented on an L2 solution if it is EVM equivalent.

Disadvantages:

  • More technically complex: The EVM is a complex virtual machine whose behavior and features require deep 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: EVM is designed for Ethereum, and its design may not be fully suitable for the characteristics and needs of L2 solutions. For example, the EVM uses 256-bit integers for computation, while many zk-proof systems work more naturally on prime-number fields. Implementing the EVM directly may require introducing additional operations such as range checking, 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 some respects. 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 wrote an article to explore EVM compatibility and EVM equivalence. At the beginning, the OVM used by OP was 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 significance of EVM compatibility, and even equivalence is required to attract developers, thereby creating users, and thereby creating an ecology.

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 structure 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 is very different from the OP.

  • Optimistic Rollup: OP Rollup employs an optimistic strategy where transactions are assumed to be valid unless disputed. This approach does not require all data to be stored on-chain, only enough information to allow anyone to challenge the validity of the 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 zkSync's data size grows, it may become unfeasible to store all data on the main chain. This may require the introduction of external data verification, thereby changing the existing secondary verification method and reducing dependence on main network data.

Such changes have raised new challenges: how to ensure the security of the system while reducing the dependence on the main chain data?

Therefore, the transformation of zkSync to STARK is also partly triggered by this, because STARK is more suitable for using external verifiable data than SNARK.

According to the above description, the implementation of ZK rollup still needs to rely on ETH for more ZK-friendly improvements, such as the improvement of 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 process of decentralized sequencer. Such a choice will make performance continue to be an important bottleneck in the development of ZK technology. Although the use of multiple sequencers and modular design provides a certain solution, in practice, complex coordination and synchronization problems may be involved. Not only could this affect the response time and throughput of the system, it could 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 ZK's current problems and the difficulties it is facing, so what is the reason for ZK's 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.

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 build trust. Zero-knowledge proofs allow trust to be established without mutual knowledge. This decentralized trust model has the potential to upend existing social, financial, and governmental structures, triggering 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 a lightweight verification process for ETH nodes to verify the validity of transactions even without knowing the full data. This can reduce the computing and storage requirements for node operation, thereby lowering the threshold for participating in the network. According to the original words of V God, "Mobile phones can participate in running ETH nodes".

By reducing the hardware and maintenance requirements for nodes to run, ZKPs help enable more participants to join the network. This increases the decentralized nature 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’s talk about the conclusion first: it is to do the equivalent ZK rollup of EVM, and wait for the current Ethereum to upgrade the ZK-friendly EVM, and go hand in hand to help the perfect integration of ZK technology and ETH. **

3.1 The four types of ZKrollup in the mouth of God V

  • Type 1 (full Ethereum equivalent)

Type 1 ZK-EVM aims to be completely equivalent to Ethereum without compromise. It doesn't change anything, 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 seeks to be fully equivalent to the EVM, but with 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 ease.

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, without execution through the EVM.

Advantage: Very fast proof time.

Disadvantage: more incompatibilities.

Who is developing it? : ZKSync and Nethermind's Warp project. (note, StarkNet is not even EVM compatible and is out of the discussion)

PSE Trading: Where is the way out for zero-knowledge proof?

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, which exposes the real challenge that Ethereum has not considered 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, but it must also take into account the possible future development of ZK-SNARK ASICs.

  • Two-way collaboration between ZK-EVM and EVM

The collaboration between ZK-EVM and EVM lies not only in compatibility and efficiency at the technical level, but also in the integration of developer tools and pre-compilation support.

  • Step by step towards a Type 1 future

It is the vision of many people to gradually realize Type 1 through the continuous improvement of ZK-EVM and Ethereum itself. 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 in tandem and move forward together in order to meet at some intermediate 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 a blockchain environment that balances innovation and stability, speed and compatibility.

4. Summary

The opening of the ZK era not only marks a new chapter in the Ethereum ecology, 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.

View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate app
Community
English
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)