preface

All products whose main selling point is technical features are semi-finished products.

The hype and debate about EVM and ZK EVM have been going on for some time, especially after Vitalik classified the types of ZK EVM. Popular science articles about difficult concepts such as bytecode, virtual machine, compatibility, etc. have emerged one after another. However, what these words mean and where the popularization of ZK EVM will lead the public chain landscape have not been clearly explained.

The ZK track has also officially become hot. If the previous ZK-Rollup limited it to the local L2 field, then at this moment it has a vague trend of becoming a general technology for the entire blockchain network. R3PO believes that ZK EVM will to some extent end the coexistence of multiple chains.

In this historical process of replacement, more new projects will inevitably emerge. R3PO is committed to exploring potential value. We will start with an intuitive understanding of EVM and explore the future direction of the public chain.

Image description: Solution for transferring files between different operating systems

Image source: R3PO

Consider the following scenario:

Alice wants to send a Word document running on Windows to Bob, but Bob only has a Mac that can use Pages, so Bob cannot open the document. How can we solve this problem? If we do not consider Bob installing the Mac version of Word and copying the text in the article, there are four remaining options:

1. Alice uploads the article to the cloud, such as Google Docs, and Bob can open and edit the document on a cross-platform browser;

2. Alice gives Word.exe and the document to the other party. Bob can use Crossover or a virtual machine (VM) to simulate the Windows environment, so that he can run the .exe application on the Mac and open the document.

  • Crossover can only support Word.exe running alone, but it can't do anything with other .exe applications.

  • A virtual machine (VM) will install a Windows subsystem on your Mac, and any .exe application can be run in the Windows subsystem;

3. Alice converts the document into a file format that Java can understand and gives it to the other party. Bob can install the Java environment on Mac to open the document.

4. Alice converts the document into a binary file and sends it to the other party. Bob can open the document with the most basic compatibility.

If you can understand the above process, try to make the following concept substitution:

  • Operating systems such as Windows and macOS --> public chains such as Ethereum and Cosmos;

  • Application formats such as .exe and .dmg --> Dapps of different public chains;

  • Word document --> on-chain assets;

  • Crossover --> Cross-chain bridge;

  • Virtual Machine (VM) --> EVM with lower compatibility, such as Polygon Hermez, which is a ZK VM that implements functions in accordance with EVM and requires manual iteration to keep synchronized updates;

  • JVM --> EVM, language-level equivalent compatibility, such as the planned Scroll, whose ZK EVM is completely equivalent to EVM, which can be understood as EVM with ZK features;

  • Binary compatibility --> This is EVM or Ethereum itself;

The characteristics of the entire VM and EVM are as described above, and their operation mode is basically similar to the process of transferring files across operating systems. In R3PO's view, the biggest trend is that ZK EVM will not only replace the existing EVM compatible solutions, but will eventually lead to Ethereum becoming the only application layer communication protocol, while other public chains will become specific purpose chains in specific fields, similar to Linux being active in the server field and Windows being active among ordinary users.

We will elaborate on the reasons for this conclusion below.

 

If you want to know others, you must first know yourself: the essence of ecology is the two-way rush of developers and users

EVM has promoted Ethereum's victory in the public chain competition. This victory is not due to Ethereum's "computing power superiority", but mainly due to compatibility, because the old generation of Ethereum killers such as EOS, the previous generation of Ethereum killers such as Solona, ​​and the new generation of Ethereum killers such as Aptos have all boasted of their own ultra-high TPS speeds.

However, Ethereum still stands firm, maintaining its absolute leading edge in TVL and the number of Dapps with a single-digit TPS. This advantage can be attributed to the ecological clustering effect. But why, after other public chains have become compatible with EVM and vigorously built cross-chain bridges, the gap has not narrowed, but instead has shown signs of further widening in the bear market?

R3PO believes that the solution to the problem can be found from a more certain starting point.

The starting point is the developer experience. The current Web 3 is still in its very early stages and can be compared to the Internet 2000 years ago. It is still the domain of geeks and early adopters. Even with a token mechanism, most users are still in CeDeFi built by CEX and TradiFi. There are very few real on-chain users. Ethereum has only 400,000 active addresses, but its TVL is as high as US$32 billion, with a market value of US$200 billion.

Against the backdrop of a huge disparity between the number of users and the amount of capital deposited, competing for developer power has become the most important way to maintain the ecosystem. The logic is that whoever can persist until the emergence of truly billion-level consumer applications will be able to become the public chain that truly becomes the infrastructure of the next generation of the Internet, just like the World Wide Web and Netscape Navigator in the past.

Ethereum provides developers with the most complete development experience.

In a sense, this is also an imitation of the success of the Java language. Before Java, the biggest problem with the C/C++ language was that programmers had to consider the adaptation of software and hardware. For example, 32-bit numeric types could not be directly migrated to 16-bit machines.

Image Description: JVM architecture

Image source: Wikipedia

In addition to improvements in language usability, the biggest improvement of Java lies in the design of the JVM. In a nutshell, its characteristic lies in "hardware softening", which achieves the same adaptation to different hardware through language scheduling. Once implemented in EVM, it can run on any device, truly realizing cross-platform development without the need to consider hardware issues.

With the help of JVM, Java has become one of the most mainstream development languages ​​in the world. It may not be specialized in a certain field, but it can be applied to any field. This is the essence of compatibility.

The same is true for EVM and the Ethereum development ecosystem. Developers only need to develop for EVM once, and they can continue to follow the Ethereum ecosystem and make continuous progress without having to consider the compatibility of public chain upgrades, hardware differences, etc.

Image Caption: EVM Architecture

Image source: ethereum.org

Solidity is not perfect, and EVM is not without problems, but the best compatibility is enough to ensure the loyalty of developers. As more and more public chains become compatible with EVM, this compatibility gains passive benefits. The workload of inter-chain migration is small enough, and other public chains are just localized versions of Ethereum Dapp, which will ultimately benefit the dominance of the Ethereum ecosystem.

Image description: EVM working diagram

Image source: R3PO

And language-level compatibility also helps ensure the efficiency and security of the EVM.

The virtual machine (VM) in the above picture refers to the operation mode between different operating systems. For example, Parallels Desktop can ensure that the Windows subsystem can be run on the Mac, but it is necessary to first allocate specific software and hardware resources from the original system to establish the subsystem, and then install the Windows application in the subsystem. Only then can the application run. However, due to the limitations of allocated resources, its operating efficiency cannot be compared with native applications.

EVM is similar to JVM, and it performs compatibility operations at the Solidity language level. Developers use the API provided by Infura to interact with the main network, and use Truffle to develop, test and deploy smart contracts, etc. The development kit is fully available. After completing the adaptation to EVM, Dapp can run on any public chain compatible with EVM.

Not only for developers, EVM-level compatible development ensures that the experience provided to any user is completely consistent, preserving a minimum seed user group for the Ethereum ecosystem. The Ethereum ecosystem maintains its leading edge over other public chains with only developers and a small number of users.

EVM is based on JVM. There is no need to consider too many hardware and coding issues. You only need to develop the functions that the application really needs. It can be adapted once and used on multiple terminals.

The meaning of ecology is development + application + user, and EVM plays the role of initializing the flywheel in ecological construction.

 

If you want to judge others, you must first judge yourself: EVM compatibility will not help competitors win

EVM has contributed to the success of Ethereum, but why can’t the “vampire plan” of other public chains compatible with EVM that suck blood from the Ethereum ecosystem work?

The logic of compatibility people:

  • For developers: Compatible with EVM to reduce the migration cost of Ethereum developers, and provide new public chain features such as higher TPS;

  • For users: Provide a certain degree of token incentives to encourage user migration;

  • Complete the replacement of Ethereum.

 

Logic loopholes of compatibility people:

  • For developers: EVM compatibility is not native EVM after all, and there are hidden migration costs;

  • For users: Ethereum has the highest security except for the Bitcoin network. This security cannot be compared with short-term temptations such as gold farming and airdrops.

  • Result: Ethereum still occupies the most mainstream position.

In fact, other public chains are caught in a dilemma. If they are compatible with EVM, there is a risk of becoming the de facto side chain of Ethereum, but if they are not compatible, there is the consequence of becoming an isolated island. Under the premise that everyone is eager for traffic, it becomes a helpless move that they have to do.

Image description: List of EVM compatible solutions

Image source: R3PO

At this time, other public chains are mainly taking the initiative, while Ethereum is busy improving its old problems, such as PoW to PoS, L2 road selection, account abstraction implementation, DankSharding, etc. In terms of compatibility paths, there are mainly three types: realizing EVM, achieving inter-chain compatibility with the help of applications, and EVM-compatible chains.

 

The public chain achieves EVM compatibility, represented by BNB Chain and others.

Exchange public chains such as BNB Chain or OKX Chain, with their user base and project operation capabilities, their on-chain TVL and ecology should not be underestimated. Take BNB Chain as an example. According to DeFi Llama data, 492 protocols are running on it, with a TVL of US$6 billion. In terms of scale and volume, it is the second largest public chain after Ethereum.

Its main operating mode "imitates" Ethereum. For example, its largest DEX Pancakeswap was originally a forked version of Uniswap. The same Dapp can be seamlessly switched between the two public chains. Behind this is the huge advantage brought by EVM compatibility. The project party only needs to focus on operations without having to develop products from scratch.

 

On-chain EVM compatibility, represented by Solona.

Solona is a single blockchain with a PoH mechanism. It has long been the only public chain among the top ten public chain projects by market value that is not compatible with EVM. However, this does not mean that it cannot communicate with EVM-compatible chains. The Neon project running on the chain provides EVM compatibility.

This kind of compatibility can be understood as nested compatibility, rather than direct compatibility at the public chain level.

Neon provides a development experience that is highly similar to EVM itself, such as Solidity language programming support, seamless smart contract deployment experience, direct calls to MetaMask, and development kits such as Truffle.

 

Compatible with EVM chain, represented by EVMOS.

There are more options for modular blockchains such as Cosmos or Polkadot, and the applications on them can themselves become L1-level public chains. EVMOS is both a child chain of Cosmos and a public chain that provides EVM compatibility. This means that EVMOS can not only "transfer" EVM compatibility between Cosmos, but also provide EVM compatibility between any other public chains.

In addition to being an EVM compatibility provider, it can also be used as a public chain to deploy applications such as DeFi. For example, the DEX Exswap on it is a forked version of Uniswap.

 

Summary of this paragraph:

It is this broad compatibility that has enabled the entire public chain world to be connected, and the link is EVM compatibility, cross-chain bridges, and exchanges. In view of this, R3PO summarizes the specific schools of compatibility as above to warm up for the terminator role of ZK EVM.

 

If you want to win over others, you must win over yourself first: ZK EVM is Ethereum’s proactive attack

If Ethereum was unable to take care of itself when other public chains were busy being compatible with EVM, after the PoS merger was successful and the L2 technology route was determined, ZK became the common technology for the entire public chain track, and the combination of ZK technology and EVM will also facilitate the evolution of Ethereum's modular architecture.

ZK technology is not limited to the L2 field. It has its place in Dapp, public chain and other upper and lower layers. However, the hottest ZK EVM track is a bit mixed. R3PO makes a brief summary of this, striving to remove the dross and retain the essence.

Image caption: Compatibility and performance of different EVMs

Image source: vitalik.eth

Vitalik once gave the relationship between compatibility and performance of different EVM classifications. It can be found that the lower the level of implementation, the stronger the compatibility, but the worse the performance. This reason is actually very simple. You can understand it by thinking about the poor performance and extremely strong security of the Ethereum mainnet.

  • The closer to the bottom layer, the closer to the operation mode of the native EVM, and the stronger the compatibility, but the performance will also be severely limited;

  • The closer to the upper layer, the more it tests the ability of its own EVM compatibility solution. The greater the difference with Ethereum's native EVM, the worse the compatibility, but it will also bring greater customization freedom and greatly optimize performance.

Polygon Hermez was mentioned in the previous article and classified as ZK VM, but in fact Hermez calls itself a ZK EVM solution. It seems to be only one letter difference, but their compatibility and security are very different.

The ZK VM/EVM implemented on Polygon Hermez is essentially a one-to-one "replication" of the EVM's functions, similar to the relationship between WBTC and BTC, and the relationship between the shadow and the main body. In daily operations, as long as the development team keeps updating, its user experience is no different from EVM. However, it is not a language-level implementation after all. It can only be said that this is a rhetoric whitewash under commercial competition.

Recently, StarkNet released ZK EVM Kakarot, which uses Cairo language and is used to run Ethereum smart contracts on StarkNet. This can be considered as the first ZK EVM to enter the testing phase. Other ZK EVM players waiting in the pipeline include Taiko, Scroll, zkSync 2.0, and others.

Why has ZK EVM become such a hot track, and why is it the terminator of the public chain? At present, in the commercial competition stage, the information released by various project parties is not comprehensive. R3PO tries to give its own understanding, just as a starting point.

Image description Ethereum architecture in the ZK EVM era

Image credit: R3PO

For the first question, the answer is that ZK EVM is actually the real home for future Dapps.

In the existing cognition, Dapp either runs on the public chain or on the L2 network. But in the view of R3PO, ZK EVM will directly carry the application layer in the future.

As shown in the above figure, the future ZK EVM will become a collection of EVM, Rollup and cross-chain bridge functions. It itself is an EVM and does not need to be explained. Let’s focus on explaining the latter two functions.

The L2 level Rollup is too low-level. In order to pursue higher performance, let’s take StarkNet developed by StarkWare as an example. It plans to use ZK recursive proof to verify the validity of the data. The recursion can be infinitely expanded in a “post-test-before” manner. ZK can ensure the overall finiteness of the data scale. Therefore, StarkNet itself can be used as the verification layer for the application and L3 above it.

The cross-chain bridge itself is easier to understand. The essence of the cross-chain bridge is to exchange and transfer assets between different public chains. If both parties achieve EVM compatibility, there is no need for a cross-chain bridge as an intermediary. ZK itself is safer than the current cross-chain bridge solution with frequent vulnerabilities. Therefore, ZK EVM is a better cross-chain bridge solution.

For the second question, the answer is that ZK EVM will turn the entire public chain into an EVM chain.

Even public chains such as Solona and Aptos that are not compatible with EVM can be connected through Evmos. From this perspective, ZK EVM is Ethereum's proactive attack. If you don't connect to me, I will also be compatible with you. In this way, Ethereum's ecological advantages will be further magnified.

The Move ecological public chains such as Aptos and Sui claim that their Move VM is also a development mechanism similar to EVM. Theoretically, the Move language adapted from Rust is indeed better than Solidity, but its biggest disadvantage is that time waits for no one, and it is questionable whether it can build its own traffic and ecology, which in turn leads to the dilemma of whether other public chains are compatible with EVM.

 

Conclusion

Whether a public chain can achieve market success depends on its own efforts, but it also needs to consider the course of history.

In the development process of ZK EVM, we can clearly feel the difficulty of the struggle of the public chains behind it. In the tug-of-war between Ethereum and a number of public chains, endless romantic stories have been created. At this time, the match point has come to the life-and-death game between new species such as EVMOS and Move VM and ZK EVM. R3PO believes that the future public chain landscape must be based on the interoperability brought by EVM compatibility as a competitive premise, and users and developers are still the whole meaning of the story.

If ZK EVM progresses smoothly, it is very likely that Ethereum will become the Windows of the public chain world, running the richest application layer and ensuring itself as the safest and most robust settlement layer.

It will take at least five years for ZK technology to mature on a large scale. With the large-scale acceleration of capital and market, the time may be slowed down to about three years. By then, we will be able to witness whether today's predictions will come true.

Copyright Statement: If you need to reprint, please add our assistant on WeChat for communication. We reserve the right to pursue legal liability for any unauthorized reprint or plagiarism.

Disclaimer: The market is risky and investment should be cautious. Please strictly abide by the local laws and regulations when considering any opinions, views or conclusions in this article. The above content does not constitute any investment advice.