Five common types of zkEVM and their project progress

Five types of zkEVM and their progress status.

As a scaling solution for Ethereum, ZK Rollup allows transactions to be processed off-chain and merged on-chain in the form of a single compressed transaction. This increases transaction throughput, reduces transaction costs, and ensures the validity of the state through zero-knowledge proofs, improving the privacy and security of the main chain. Therefore, ZK Rollup is considered the ultimate solution for Ethereum scalability.

However, currently the generation of zero-knowledge proofs requires significant computing power and higher technical difficulty. Additionally, since the Ethereum Virtual Machine (EVM) is not designed to support ZK circuits, smart contracts cannot be executed directly. To address this issue, many developers have attempted to develop zkEVM, which can run smart contracts in a way that is compatible with zero-knowledge proof calculations. For many ZK Rollups, achieving EVM equivalence means achieving full bytecode-level compatibility, and currently zkEVM is key to Ethereum scalability.

This article will explore the progress of five common types of zkEVM and point out the design challenges of each type of zkEVM.

What is zkEVM

zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof calculations. It is an application development platform based on Ethereum blockchain technology. EVM contracts can be directly deployed and run without modification, and the validity of the program’s execution can be proven through zero-knowledge proofs.

Advantages of zkEVM

1. zkEVM improves compatibility. zkEVM is highly compatible with smart contracts written to run in the EVM and can seamlessly integrate with EVM infrastructure. Developers can migrate existing Ethereum applications to L2 without having to redevelop them, while zk proof inherits Ethereum network security.

2. zkEVM enhances scalability. zkEVM uses non-interactive proofs, increasing throughput and reducing latency, as verifying the proof of an L2 block is faster than re-executing every transaction in a newly proposed block.

3. zkEVM reduces storage costs. zkEVM Rollups can choose to only publish commitments to their final state on Ethereum L1, reducing on-chain storage costs. The validity proof ensures the correctness of the new state of zkEVM, so the sequencer does not need to publish all the data required to re-execute the state transition changes.

With the continuous improvement of zkEVM, the limitations of ZK Rollup have been solved. Utilizing the security and efficiency of ZK Rollup, coupled with EVM compatibility, applications can interact with smart contracts to improve the application experience.

Five different types of zkEVM and related projects

When EVM was designed, it did not consider supporting zero-knowledge proofs, which made it difficult to build EVM-compatible zk virtual machines. However, as research progresses, EVM computations can be wrapped in zero-knowledge proofs. Different zkEVM projects use different methods to combine EVM execution with zero-knowledge proof computation.

Ethereum founder Vitalik Buterin has also explained the trade-offs between different types of zkEVMs. V God believes that the core goals of these projects are the same: to use ZK-SNARK technology to provide encrypted proofs for the execution of Ethereum-like transactions, making it easier to verify the Ethereum chain itself or build ZK Rollups equivalent to Ethereum, but more scalable than Ethereum.

Type 1 (consensus-level equivalence — identical to Ethereum)

Type 1 zkEVM strives to be fully equivalent to Ethereum. It will not modify any part of the Ethereum system to make it easier to generate proofs, nor will it replace hashes, state trees, transaction trees, precompiles, or any other consensus logic.

The advantage of Type 1 zkEVM is that it is fully compatible with Ethereum. In the long run, modifications to Ethereum tested in Type 2 or Type 3 ZK-EVMs may be introduced into Ethereum itself, but this kind of restructuring has its own complexity, so Type 1 is ultimately what is needed to make Ethereum L1 itself more scalable. At the same time, Type 1 zkEVM is also an ideal choice for rollups because they allow rollups to reuse a lot of infrastructure.

The disadvantage of Type 1 zkEVM is the issue of verification time. Ethereum was not originally designed around ZK-friendliness, so many parts of the Ethereum protocol require a lot of computation to execute ZK proofs. Type 1 zkEVM aims to precisely replicate Ethereum, so it cannot mitigate these inefficiency issues. Type 1 zkEVM is the most ideal zkEVM, and many projects are building or exploring this type.

Currently, there are two Type 1 zkEVM projects, Taiko and Kakarot.

Taiko’s Type 1 zkEVM allows developers and users to experience Ethereum safely with lower transaction fees and without having to consider any changes. Taiko raised $22 million in two seed rounds, with $10 million led by Sequoia China in the first round and $12 million led by Generative Ventures in the second. On June 7th, Taiko launched the Alpha-3 incentive testnet. According to Taiko, this testnet focuses on the decentralized, Ethereum-equivalent ZK-EVM part.

Kakarot zkEVM is an EVM deployed using Cario language, which enhances EVM compatibility to extend the reliability of the Starknet ecosystem. Kakarot zkEVM can exist in different forms. In the first phase, it brings EVM to Starknet. In the second phase, Kakarot and Madara will merge into a unified stack to support L3 zkEVM. In the third phase, Kakarot and Madara can also be combined to enable Type 1 zkEVM. On June 2nd, Kakarot zkEVM completed pre-seed financing, with participation from institutions such as StarkWare and LambdaClass, as well as angel investors including Vitalik Buterin, Nicolas Bacca, and Rand Hindi.

Type 2 (bytecode-level equivalence – completely equivalent to EVM)

Type 2 zkEVM strives to be fully equivalent to EVM, but not completely equivalent to Ethereum. In other words, they look exactly like Ethereum internally, but they have some differences externally, especially in data structures such as block structures and state trees. The goal is to be fully compatible with existing applications but make some minor modifications to Ethereum to make development easier and proof generation faster.

The advantage of Type 2 zkEVM is the perfect equivalence at the VM level. Type 2 zkEVM changes the data structures that store Ethereum state and other data that EVM cannot directly access, so applications running on Ethereum can almost always run on Type 2 zkEVM rollup. This type cannot be used as is to execute Ethereum clients, but can be used with some modifications and can still use EVM debugging tools and other infrastructure.

The disadvantage of Type 2 zkEVM is that verification time is still slow. Type 2 zkEVM provides faster verification time than Type 1 zkEVM, mainly by removing unnecessary complexity and ZK-unfriendly cryptographic parts in the Ethereum stack. For example, they may change Ethereum’s Keccak and RLP-based Merkle-Blockingtricia tree and may also change block and receipt structures. These modifications significantly improve the prover time but do not solve all problems. Due to all the inherent inefficiencies and ZK-unfriendliness of EVM, proving the EVM is still slow.

Currently, there are two Type 2 zkEVM projects: Linea and Polygon.

Linea is a Type-2 zkEVM that is supported by Consensys. By integrating ZKP with full EVM compatibility, developers can create scalable DApps or migrate existing DApps to new platforms without changing code or rewriting smart contracts. The public testnet was released on March 28th of this year and has been added to the default network options of the Metamask extension. Linea released Alpha v0.2 on June 13th at 12:00, which focuses on testing substantial architectural upgrades and preparing for the mainnet launch.

Polygon zkEVM is open source and adopts Type 2 zkEVM. It uses ZK proofs to reduce transaction costs and increase throughput while maintaining the security of Ethereum L1. On February 14th of this year, Polygon announced that Polygon zkEVM had passed 100% of the Ethereum test vectors applicable to zkEVM, and developers do not need to modify or rewrite any code, and all Ethereum tools can work seamlessly with Polygon zkEVM, which means that EVM compatibility in ZK Rollup has taken a big step forward, reaching the level of Type 2, and is fully equivalent to EVM. The mainnet test version of Polygon zkEVM was officially launched on March 27th, 2023.

Type 2.5 (EVM-equivalent, except for gas costs)

One way to improve verification time is to significantly increase the gas cost of specific operations in the EVM that are difficult to ZK proof. This may involve precompilation, keccak opcodes, and possible specific patterns for calling contracts or accessing memory, storage, or recovery.

Changing gas costs may reduce the compatibility of developer tools and break some applications, but it is generally considered less risky than “deeper” EVM changes. Developers should be careful not to require gas that exceeds one block in a transaction, and not to use hard-coded gas amounts for calls.

Currently, there is no specific project for Type 2.5 EVM, it is just a stage in the Type 2.

Type 3 (Bytecode-level equivalence – almost equivalent to EVM)

Type 3 zkEVM is almost equivalent to EVM, but in order to further shorten the proof time and make EVM easier to develop, some sacrifices have been made for precise equivalence.

The advantage of Type 3 zkEVM is that it is easier to build and has faster verification times. Type 3 zkEVM may remove some features that are particularly difficult to implement in zkEVM implementations. In addition, Type 3 zkEVM sometimes has subtle differences in how it handles contract code, memory, or stacks.

Type 3 zkEVM’s disadvantage is worse compatibility. Type 3 zkEVM aims to be compatible with most applications, with only minimal rewriting required for the rest. This means that some applications will need to be rewritten because they use precompiles that have been removed by Type 3 zkEVM, or because of subtle dependencies on how the VM handles edge cases differently.

Currently, the only Type 3 zkEVM-related project is Scroll.

Scroll is an EVM-equivalent zk-rollup developed in collaboration between the Scroll team and the Ethereum Foundation’s PSE (Privacy and Scaling Explorations) group. It is currently in the Pre-Alpha testnet stage and aims to be fully compatible with the EVM at the bytecode level. This means that developers can create smart contracts using any EVM-compatible language and deploy them to Scroll. Although Scroll is currently building a Type 2 EVM, many more complex precompiles have yet to be implemented, making it a Type 3 EVM. According to Scroll, it is expected to launch on the mainnet in July and August of this year. Scroll also mentioned a possible partner program to incentivize ecosystem development.

Currently, Type 3 EVM is just a transitional phase until the complex work of adding precompiles is completed, and the project can move to a Type 2.5 zkEVM. However, in the future, Type 1 and Type 3 EVMs may add new ZK-SNARK-friendly precompiles to provide developers with low verification time and low gas cost functionality.

Type 4 (programming language-level equivalent – high-level language equivalent to EVM)

The way Type 4 EVM works is by compiling smart contract source code written in a high-level language (such as Solidity, Vyper, or intermediate languages) into a language that is explicitly designed to be ZK-SNARK friendly.

The advantage of Type 4 zkEVM is faster proof speed. Because this type does not zk-proof all the different parts of each EVM execution step, it can avoid many costs by starting directly from the high-level code.

The disadvantage of Type 4 zkEVM is that it has worse compatibility. One is that the address of the contract in the Type 4 system may be different from its address in the EVM; the other is that many applications use handwritten EVM bytecode in some parts to improve efficiency, which may not be supported by the Type 4 system, and many debugging infrastructures cannot inherit.

Currently, Type 4 zkEVM-related projects include zkSync Era and StarkNet.

zkSync Era was created by Matters Lab. zkSync Era is the first EVM to launch on the mainnet, and the public can fully access it to bridge their funds to the system or deploy their code on the network. zkSync Era uses a different bytecode format and supports Solidity by providing a compiler. It supports Solidity, but not EVM bytecode itself. For example, tools like Hardhat cannot be used directly, although a plugin for zkSync can be used.

StarkNet, created by StarkWare, is a zk-rollup L2 that uses zero-knowledge proofs to create an off-chain execution layer for Ethereum. In fact, the EVM is not a native feature of Starknet. Starknet uses the Warp converter (provided by Nethermind) to transform Solidity code into Cairo in order to support smart contract deployment.

The Challenges and Future of zkEVM

As the EVM was not designed with zk-proof computation in mind, it has properties that are not friendly to proof circuits, particularly in terms of special opcodes, stack-based architecture, storage overhead, and proof costs. However, several breakthroughs in zero-knowledge technology make it possible to mitigate these issues.

There are five types of zkEVM, and there is no clear winner among them. Lower-numbered types are more compatible with existing infrastructure but slower, while higher-numbered types are less compatible but faster. Overall, exploring different types is beneficial for the development of zkEVM and Ethereum in different projects.

In the future, there will be multiple implementations of zkEVM, which can be used for both ZK Rollup and verifying the Ethereum chain itself. In theory, Ethereum does not need to use a single standard zkEVM for L1, and different clients can use different proofs. However, it will take a considerable amount of time to realize such a future. In the meantime, we will see more innovation on different paths for scaling Ethereum and Ethereum-based ZK-rollup.