zkSync 2.0 Mainnet is about to launch—A brief analysis of various zkEVMs
TechFlow Selected TechFlow Selected
zkSync 2.0 Mainnet is about to launch—A brief analysis of various zkEVMs
Regarding the technical path selection for Rollups, ZK Rollup is considered the ultimate goal for Ethereum scaling.
Navigating Web3 tides with focused insightsEthereum's development roadmap is increasingly leaning toward a modular blockchain architecture, which combines Layer 1 data sharding with Layer 2 rollups to form a modular structure that advances Ethereum’s original vision of becoming a “world computer.”
Regarding the technical direction for rollups, ZK Rollup is widely regarded as Ethereum’s ultimate scaling solution.
ZK Rollup
The core mechanism of ZK Rollup involves compressing user states on-chain into a Merkle tree and moving state transitions off-chain, while using zk-SNARKs or zk-STARKs to ensure the correctness of these off-chain state changes. In simpler terms, ZK Rollup can be understood as using zk-SNARKs or zk-STARKs to achieve sublinear verification for linear numbers of statements. For example, verifying 1,000 statements might require only 10 checks by the verifier, and 10,000 statements might require just 11 checks. As a result, ZK Rollup enables significant scalability for Ethereum.
The general transaction processing workflow in a ZK Rollup is as follows:
-
Users lock their assets in a ZK Rollup smart contract on L1;
-
Users submit transactions involving these assets to L2, where a specific role (the Sequencer—centralized in most early projects, though some are adopting decentralized approaches) collects these transactions according to certain rules into ordered batches, generating validity proofs (zk-SNARKs/zk-STARKs) and aggregated state updates for each batch;
-
This state update and proof are submitted to the ZK Rollup smart contract on L1 and verified, thereby updating the blockchain on L1;
-
Users can use this L1 state (depending on different data availability mechanisms) to retrieve their assets, enabling full self-custody. Thus, ZK Rollup is considered to inherit Ethereum's security.
The Necessity of zkEVM
It is well known that first-generation ZK Rollups did not support the EVM, suffering from poor programmability and composability, limiting them to specific use cases—for instance, Loopring was restricted to payments and swaps; Immutable was limited to NFT minting, trading, and games; and zkSync 1.0 did not support zkEVM either. They lacked generality.
Later, leading ZK Rollup projects began exploring ways to build an EVM bytecode-compatible execution environment within ZK Rollups, allowing Ethereum smart contracts to migrate seamlessly to ZK Rollups without requiring complete rewrites.
The EVM, launched in 2015, was the first Turing-complete blockchain virtual machine. It remains the most battle-tested blockchain VM and a critical smart contract infrastructure for Ethereum. When evaluating other blockchains, EVM compatibility is often used as a benchmark—not only because it indicates compatibility with the smart contract execution environment but also because it implies access to Ethereum’s ecosystem and tooling, along with its powerful network effects. Therefore, ZK Rollup projects could not afford to overlook this aspect.
zkEVM can thus be understood as running the EVM as a smart contract engine inside a ZK Rollup. The goal of zkEVM is to bring the full Ethereum experience to Layer 2 without sacrificing the performance advantages of rollups.
To date, major general-purpose ZK Rollup projects such as zkSync 2.0, Polygon Hermez 2.0, and Scroll have successively launched zkEVM testnets, while StarkNet has already entered its Alpha Mainnet phase.
Classification of zkEVM Compatibility
Current zkEVM implementations in ZK Rollups are not fully compatible with Ethereum itself, let alone achieving the ultimate vision of “Ethereum equivalence.” As such, not only is Ethereum’s own upgrade path adapting to be more rollup-friendly, but various ZK Rollup projects are actively addressing compatibility issues with Ethereum.
Vitalik has categorized general-purpose zkEVM ZK Rollups into four types based on their degree of compatibility with existing EVM infrastructure:
Type-1: Fully Equivalent to Ethereum
Type-1 zkEVM aims for complete and uncompromising equivalence with Ethereum. It requires no changes to any part of the Ethereum system—no alterations to hashes, state trees, transaction trees, precompiles, or any other consensus logic. In short, Type-1 zkEVM is fully equivalent to Ethereum.
A Type-1 zkEVM can verify Ethereum blocks just like Ethereum itself, or at least verify the execution layer (including all transaction execution, smart contracts, and account logic), excluding beacon chain consensus logic.
Type-1 zkEVM is what Ethereum ultimately needs and represents the ideal choice for rollups. On one hand, it allows rollups to reuse extensive existing infrastructure (e.g., Ethereum execution clients, block explorers, block production tools). On the other hand, it enhances Ethereum L1’s own scalability potential, as modifications explored in Type-1 zkEVM systems may eventually be adopted directly into Ethereum itself.
However, Type-1 zkEVM also has drawbacks. Ethereum was not originally designed with ZK-friendliness in mind, so many parts of the protocol require substantial computation to generate ZK proofs. Type-1 inherits this inefficiency and cannot alleviate the slow proof generation times. Industry solutions to this issue currently include large-scale parallelization of proving through clever engineering or using ZK-SNARK ASICs for hardware acceleration.
Currently, two teams are actively pursuing Type-1 zkEVM: the Privacy and Scaling Explorations team and Taiko.
Type-2: Fully Equivalent to EVM
Type-2 zkEVM aims for full equivalence with the EVM but not full equivalence with Ethereum. These systems remain fully compatible with existing applications but require minor modifications to Ethereum to simplify development and speed up proof generation.
Type-2 zkEVM makes slight modifications to data structures such as block formats and state trees. Since these structures are not directly accessible by the EVM, applications running on Ethereum can almost run natively on Type-2 zkEVM rollups. While native Ethereum execution clients cannot be used out-of-the-box, they can be adapted with minor changes, and EVM debugging tools and most other developer tools remain usable.
By removing unnecessary and ZK-unfriendly components of the Ethereum stack, Type-2 zkEVM achieves faster proof generation than Type-1. However, although these improvements significantly boost prover efficiency, they do not fundamentally solve the problem of slow proof generation. Overall, proof times in Type-2 remain relatively slow.
Type-3: Nearly Equivalent to EVM
Type-3 zkEVM is nearly equivalent to the EVM, making some trade-offs in compatibility to improve ease of development.
Type-3 zkEVM removes certain functionalities that are difficult to implement in a zkEVM context—such as precompiles—and adjusts aspects of contract code, memory, or stack handling. These changes sacrifice some level of equivalence to reduce verification time and make development easier.
Due to these compromises, applications relying on precompiles removed by Type-3 zkEVM must be partially rewritten to function.
Currently, Scroll and Polygon fall under Type-3. However, in the long term, no zkEVM team has publicly stated an intention to remain permanently at Type-3. Both Scroll and Polygon Hermez are working toward Type-2 zkEVM, despite the complexity involved in implementing all required precompiles.
Type-4: High-Level Language Equivalent
Type-4 systems are essentially zkVMs. They work by taking smart contract source code written in high-level languages (like Solidity or Vyper) and compiling it into a language explicitly designed to be ZK-SNARK-friendly.
The advantages and disadvantages are clear. Verification times are very fast because Type-4 systems do not perform ZK proofs on every step of EVM execution. Instead, they start from higher-level code, reducing costs and accelerating verification. However, compatibility is weaker—contract addresses in Type-4 systems differ from those on the EVM; hand-written EVM bytecode becomes harder to use; and much of the debugging infrastructure cannot be reused since it operates at the EVM bytecode level.
In summary, Type-4 offers equivalence at the language level, falling significantly short of bytecode-level compatibility. According to Vitalik, current examples include zkSync, although it may gradually add EVM bytecode compatibility over time; and StarkNet, via the Nethermind-built Warp project that compiles Solidity to StarkWare’s Cairo language, effectively turning StarkNet into a Type-4 system.
Comparison of Various zkEVM Types
There is no absolute hierarchy among these zkEVM types. They represent different trade-offs between compatibility and speed. Type-1 offers the highest compatibility with Ethereum but slower proof generation; Type-4 provides lower compatibility but faster verification. Notably, today’s leading ZK Rollup projects—including zkSync, StarkNet, Polygon, and Scroll—are mostly Type-4 or Type-3, meaning they prioritize performance over perfect EVM compatibility.
Vitalik hopes that over time, through combined improvements in zkEVM and Ethereum itself, all zkEVMs will eventually evolve into Type-1. This would allow multiple zkEVMs to serve both as ZK Rollups and as verifiers for Ethereum itself (as Ethereum becomes more ZK-SNARK-friendly in the future).
Vitalik’s perspective generally aligns with industry consensus, and I strongly agree. Type-1 zkEVM projects are naturally the most welcome within the Ethereum ecosystem and best aligned with Ethereum L1. However, Type-4 zkVMs are still a viable technical choice for execution-layer projects.
Two main considerations:
-
Within the modular blockchain narrative, zkVMs are more adaptable to integration with other L1s. If we move beyond the mindset of building solely for the Ethereum L2 ecosystem, choosing a zkVM without strict EVM bytecode compatibility could actually facilitate future interoperability with other L1 consensus layers;
-
Currently, the performance ceiling of ZK Rollups is constrained by proof generation speed, where Type-4 zkVMs hold an advantage. Fast proof generation at the execution layer remains crucial. Pushing L2 execution performance to its limits is a valid strategy. Although ASIC-based hardware acceleration may improve proof efficiency in the future, its impact remains uncertain. Hence, the faster proof generation speed of Type-4 zkVMs is a significant advantage.
Of course, zkEVM compatibility and speed are not the only factors developers consider when choosing a ZK Rollup platform. Many other aspects influence their decision, including:
-
Fees: Which tokens are used for payment, and how much fee reduction L2 offers—though most general-purpose ZK Rollup projects are still in testnet phases, making direct comparisons difficult;
-
Proof Generation Rules: Who is allowed to act as a Prover, and what kind of hardware is supported for accelerating proof generation;
-
L2 Transaction Ordering Rules: Whether a single Sequencer is used or a decentralized approach;
-
Self-Custody: Whether there are clear mechanisms ensuring users can recover assets on L1 in case of L2 failures;
-
Data Availability: Full data availability comes at a higher cost—whether one can accept lower-cost data availability models used by some ZK Rollups.
In conclusion, each type of zkEVM in ZK Rollups involves trade-offs across multiple dimensions, and none can be absolutely deemed superior or inferior.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
