An Analysis of Various zkEVMs on the Occasion of the Launch of zkSync 2.0 Mainnet
Each type of ZK Rollup's zkEVM makes trade-offs among various performances, and there is no absolute superiority or inferiority.Author: IOBC Capital
The development path of Ethereum is increasingly leaning towards Modular Blockchain, which essentially combines Layer 1 data sharding and Layer 2 Rollups scalability, forming a modular architecture that drives Ethereum to realize its original intention of being a "world computer." Among the technical paths for Rollups, ZK Rollup is considered the ultimate goal for Ethereum's scalability.
ZK Rollup
The core working mechanism of ZK Rollup is to compress and store the on-chain user state in a Merkle tree, while transferring the changes in user state off-chain, ensuring the correctness of this off-chain user state change process through zksnark/zkstark proofs. In simpler terms, ZK Rollup can be understood as using zksnark or zkstark to process sub-linear amounts of data to verify a linear number of statements. For example, 1000 statements require 10 verifier checks, while 10,000 statements require 11 verifier checks. Therefore, the result is that ZK Rollup can achieve scalability for Ethereum.
The general blockchain transaction processing process of ZK Rollup is as follows:
- Users lock their assets in the zk rollup smart contract on L1;
- Users submit transactions involving these assets to L2, where certain roles (Sequencer, most early projects were centralized, and some projects have begun to adopt decentralized methods) collect these transactions into ordered batches according to certain rules, generating validity proofs (zksnark/zkstark) and aggregated state updates for each batch;
- This state update and proof are submitted to the zk rollup smart contract on L1 and verified, which updates the blockchain on L1;
- Users can use this L1 state (depending on different data availability mechanisms) to retrieve their assets, achieving complete self-custody, so zk rollup is also considered to inherit Ethereum's security.
The Necessity of zkEVM
It is well known that the first generation of ZK Rollups does not support EVM, has poor programmability and composability, and can only be limited to specific scenarios, such as: Loopring can only be limited to Payments & Swaps; Immutable can only be limited to NFT Minting & Trading & Games; zksync1.0 actually does not support zkEVM. It lacks universality.
Later, leading ZK Rollups began to explore developing a code execution environment on ZK Rollup that supports EVM bytecode, allowing smart contracts on Ethereum to migrate to ZK Rollup without having to rewrite code from scratch.
EVM is the first Turing-complete blockchain virtual machine, released in 2015. It is the most tested blockchain virtual machine to date and is a very important infrastructure for smart contracts on Ethereum. Even when discussing other blockchains, EVM compatibility is often used as a judgment dimension, as EVM compatibility represents not only the smart contract execution environment but also the available Ethereum ecosystem and toolset, and more importantly, the significant network effects. Therefore, ZK Rollups also dare not overlook this aspect.
zkEVM can be understood as running EVM as a smart contract engine within ZK Rollup. The goal of zkEVM is to fully bring the Ethereum experience to L2 without losing the performance advantages of Rollup.
As of now, leading general-purpose ZK Rollup projects such as zkSync2.0, Polygon Hermez2.0, and Scroll have successively launched zkEVM testnets, while StarkNet has entered the Alpha Mainnet phase.
Classification of zkEVM Compatibility
Current ZK Rollups' zkEVM is not fully compatible with Ethereum itself, let alone the ultimate vision of "Ethereum equivalence." Therefore, not only is Ethereum's own upgrade plan accommodating Rollup-friendly features, but various ZK Rollup projects have also been continuously addressing compatibility issues with Ethereum.
Vitalik has categorized zkEVM general ZK Rollups into four types based on their compatibility with existing EVM infrastructure:
Type-1: Fully Equivalent to Ethereum
Type-1 zkEVM strives to be fully and uncompromisingly equivalent to Ethereum. It requires no changes to any part of the Ethereum system, does not replace hashes, state trees, transaction trees, precompiles, or any other consensus logic. In short, Type-1 zkEVM is fully equivalent to Ethereum.
Type-1 zkEVM can verify Ethereum blocks like Ethereum itself, or at least verify the execution layer (including all transaction executions, smart contracts, and account logic, excluding beacon chain consensus logic).
Type-1 zkEVM is what Ethereum ultimately needs and is the most ideal choice for Rollups. On one hand, Type-1 zkEVM allows Rollups to reuse a large amount of infrastructure (e.g., Ethereum Execution Clients, Block Explorers, Block Production, etc.); on the other hand, Type-1 zkEVM can make Ethereum Layer 1 itself more scalable, as some modifications to Ethereum explored on Type-1 zkEVM may be introduced into Ethereum itself in the future.
Of course, Type-1 zkEVM also has its drawbacks. Ethereum was not originally designed with ZK-friendly features, so many parts of the Ethereum protocol require significant computation to perform ZK proofs. Like Ethereum, Type-1 cannot alleviate the inefficiencies in this regard (it takes a long time to generate proofs). The current industry solutions proposed for this issue mainly involve: cleverly engineering large-scale parallel proof generation, or achieving hardware acceleration through ZK-SNARK ASICs.
Currently, there are two main teams exploring Type-1 ZK-EVM, one is the Privacy and Scaling Explorations team, and the other is Taiko.
Type-2: Fully Equivalent to EVM
Type-2 zkEVM aims to be fully equivalent to EVM but not fully equivalent to Ethereum. They are fully compatible with existing applications but require some minor modifications to Ethereum to make development easier and generate proofs faster.
Type-2 zkEVM makes some modifications to data structures like block structure and state trees. Since these structures cannot be directly accessed by EVM itself, applications running on Ethereum can almost run directly on Type-2 zkEVM Rollup. Although Ethereum execution clients cannot be used as-is, they can still be utilized with some modifications, and EVM debugging tools and most other development tools can also be used.
By removing some unnecessary and ZK-unfriendly parts of the Ethereum stack, Type-2 zkEVM's proof generation time is faster than that of Type-1 zkEVM. Although these modifications significantly improve the efficiency of the prover, they do not fundamentally solve the problem of slow proof generation time. In summary, the proof generation time for Type-2 is still quite slow.
Type-3: Almost Equivalent to EVM
Type-3 zkEVM is almost equivalent to EVM, sacrificing some compatibility but making EVM easier to develop.
Type-3 zkEVM sacrifices some equivalence by removing some features that are difficult to implement in zkEVM (such as precompiles) and making adjustments in handling contract code, memory, or stack, resulting in more verifier time and making EVM easier to develop.
Due to the sacrifices in compatibility, some applications that use precompiles removed by Type-3 zkEVM need to be rewritten.
Currently, Scroll and Polygon fall under Type-3. Of course, in the long run, no zkEVM team has publicly stated a willingness to remain at Type-3. Both Scroll and Polygon Hermez are progressing towards Type-2 zkEVM, although many complex precompiles have yet to be implemented.
Type-4: High-Level Language Equivalent
Type-4 actually belongs to zkVM. Type-4 systems work by taking the source code of smart contracts written in high-level languages (Solidity, Vyper) and compiling it into a language explicitly designed to be ZK-SNARK friendly.
The advantages and disadvantages are clear. There are very fast verification times because Type-4 does not perform ZK proofs on all different parts of each EVM execution step but starts from a higher-level code, thus reducing costs and achieving faster verification times. However, compatibility is poor; contracts in Type-4 systems have different addresses than their addresses in EVM; handwritten EVM bytecode is harder to use; and much debugging infrastructure cannot be inherited because it runs on EVM bytecode.
In summary, Type-4 is equivalent at the language level, with a significant gap in compatibility compared to bytecode-level equivalence. According to Vitalik, currently, Zksync belongs to Type-4, although it may increase compatibility with EVM bytecode over time; the warp project based on Nethermind is building a compiler from Solidity to Starkware's Cairo, which will also turn StarkNet into Type-4.
Comparison of Various zkEVMs
There is no absolute superiority or inferiority among these zkEVMs. They simply make trade-offs between compatibility and speed; Type-1 zkEVM has the highest compatibility with Ethereum but slower proof generation speed; Type-4 zkEVM has poorer compatibility with Ethereum but faster verification speed. Moreover, we find that existing star projects of ZK Rollup, including Zksync, StarkNet, Polygon, Scroll, etc., belong to Type-4/Type-3, which have lower compatibility with Ethereum.
Vitalik hopes that over time, through the combination of improvements in zkEVM and improvements in Ethereum itself, all zkEVMs will ultimately become Type-1. The benefit of this is that in the future, there will be multiple zkEVMs that can be used for both ZK Rollup and for validating the Ethereum chain itself (Ethereum will become more ZK-SNARK friendly in the future).
Vitalik's views generally easily reach a consensus across the industry, and I also strongly agree. Type-1 zkEVM projects are naturally the most popular in the Ethereum ecosystem and align well with Ethereum L1. However, Type-4 zkVM is also a good technical solution choice for execution layer projects. There are two main considerations:
- Under the narrative of Modular Blockchain, zkVM is more convenient for interfacing with other L1s. If one steps out of the mindset of only making Ethereum ecosystem L2s, and chooses to adopt zkVM without bytecode-level compatibility with the Ethereum virtual machine, it may actually facilitate future integration with other L1 consensus layers;
- The current performance ceiling of ZK Rollup is limited by proof generation speed, and Type-4 zkVM has advantages. The speed of proof generation for the execution layer is still very important; maximizing the performance of the execution layer for L2 is also a good idea. Although it is said that future efficiency in proof generation can be improved through ASIC hardware acceleration, the effectiveness is still uncertain, and the faster proof generation speed of Type-4 zkVM is a significant advantage.
Of course, the compatibility and speed of zkEVM are not the only metrics developers consider when choosing which ZK Rollup to build applications on. Many other factors can influence their choices, such as:
- Costs: Which tokens are used to pay fees, and the extent to which L2 fees are reduced is also a very important consideration, but since most general-purpose ZK Rollup projects are still in the testnet phase, comparisons cannot yet be made;
- Proof generation rules: Which individuals are supported as Provers, and even which hardware is used to accelerate proof generation;
- L2 transaction ordering rules: whether to use a single Sequencer or a decentralized method;
- Self-custody: whether there is a clear mechanism to ensure that user assets can still be recovered on L1 in the event of an accident on L2;
- Data availability: The cost of complete data availability is naturally higher; whether it is acceptable that some ZK Rollups adopt lower-cost data availability models.
In summary, each type of ZK Rollup's zkEVM makes trade-offs among various performances, and there is no absolute superiority or inferiority.
