Note: The original article was written by Vitalik Buterin, co-founder of Ether.

Special thanks to PSE, Polygon Hermez, Zksync, Scroll, Matter Labs, and the Starkware team for discussion and review.

A number of "ZK-EVM" projects have made flashy announcements recently, such as Polygon opening their ZK-EVM project, ZKSync releasing their ZKSync 2.0 initiative, and the relatively new Scroll recently announcing their ZK-EVM. privacy and scaling The Privacy and Scaling Explorations team, Nicolas Liochon et al, the alpha compiler for the Cairo language from EVM to Starkware are also working on it, and of course, there are a few that I missed.

All of these projects have the same core goal: to use ZK-SNARK technology to produce cryptographic proofs similar to the execution of Ethernet transactions, or to more easily verify the Ethernet blockchain itself, or to build ZK-rollups that are comparable (close) to the functionality offered by Ethernet but more scalable. but there are subtle differences between these projects, and the practicality and speed they trade-offs are made. This article will attempt to describe the taxonomy of different "types" of EVM equivalents, and the benefits and costs of trying to implement each type of system.

ZK-EVM Overview Diagram

Type 1 (Full Ether Equivalence)

Type 1 ZK-EVMs strive for full and uncompromising equivalence to Ether, they do not change any part of the Ether system to make it easier to generate proofs. They do not replace hashing, state trees, tx trees, precompilation, or any other consensus logic, no matter how minor.

Benefits: perfect compatibility

The goal is to be able to validate Ethernet blocks as they are today, or at least validate the execution layer side (thus, excluding beacon chain consensus logic, but including all transaction execution and smart contract and account logic).

Type 1 ZK-EVM is what we eventually need to make the Ethernet L1 layer itself more scalable. In the long run, the Ether modifications tested in the Type 2 or Type 3 ZK-EVM may be introduced into Ether itself, but this re-architecture comes with its own set of complexities.

Type 1 ZK-EVMs are also ideal for rollups because they allow rollups to reuse large amounts of infrastructure. For example, Ethernet execution clients can be used as-is to generate and process rollup blocks (or at least, they can be used once withdrawals are implemented and the functionality can be reused to support depositing ETH into rollup), so tools such as block browsers, block production, etc. are very easy to reuse.

Disadvantage: prover time

Ethernet was not originally designed around ZK-friendliness, so many parts of the Ethernet protocol require extensive computation to perform ZK proofs. Type 1 ZK-EVM is intended to be an exact replica of Ether, so it does not alleviate these inefficiencies. Currently, proofs of Ether blocks take many hours to produce. This can be mitigated by cleverly engineering massively parallelized provers (prover), and in the long term by the ZK-SNARK ASIC.

So who is building the Type 1 ZK-EVM?

The Privacy and Scaling Explorations team is building a type 1 ZK-EVM.

Type 2 (full EVM equivalence)

Type 2 ZK-EVMs are intended to be fully EVM equivalent, but not fully Ether equivalent. That is, they look identical to Ether "from the inside", but they have some differences on the outside, especially in terms of data structures such as block structure and state trees.

The goal is to be fully compatible with existing applications, but with some minor modifications to Ether to make development easier and generate proofs faster.

Benefits: Perfect equivalence at VM level

Type 2 ZK-EVM makes changes to data structures that hold things like Ether state, which fortunately are not directly accessible by the EVM itself, so applications that work on Ether will almost always work on a Type 2 ZK-EVM rollup. You will not be able to use the Ethernet execution client as is, but you can use them with some modifications, and you will still have access to the EVM debugging tools and most other developer infrastructure.

Of course, there are a few exceptions. For applications that verify Merkle proofs of historical Ether blocks to validate historical transactions, receipts, or status statements, an incompatibility arises (for example, bridges sometimes do this). Replacing Keccak's ZK-EVM with a different hash function would break these proofs. However, I usually recommend against building applications in this way, as future Ether changes (e.g. Verkle trees) could break even such applications in Ether itself. A better option would be to have Ether itself add future-proofed historical access precompilation.

Cons: Despite improvements, prover (prover) times are still slow

Type 2 ZK-EVMs offer faster prover times than Type 1 ZK-EVMs, mainly by removing the reliance on unnecessarily complex and ZK-unfriendly cryptographic parts of the Ether stack. In particular, they may change the Ethernet pair Keccak and the RLP-based Merkle-Patricia tree, and possibly the block and receipt structure. Type 2 pairs of ZK-EVM may use a different hash function, such as Poseidon. Another natural modification is to modify the state tree to store the code hash and keccak, thus eliminating the need to verify the hash to process the EXTCODEHASH and EXTCODECOPY opcodes.

These modifications significantly improve the prover time, but do not solve all the problems. Proving EVM is still slow due to all the inefficiencies and ZK unfriendliness inherent in EVM. A simple example is memory: since an MLOAD can read any 32 bytes, including "unaligned" chunks (starting and ending not in multiples of 32), an MLOAD cannot simply be interpreted as reading one chunk; instead, it may need to read two consecutive chunks and perform bitwise operations to combine the results.

So who is building the type 2 ZK-EVM?

Scroll's ZK-EVM project is moving towards a type 2 ZK-EVM, as is Polygon Hermez. Of course, neither of these projects is complete yet. In particular, many of the more complex precompilations have not yet been implemented. Therefore, both projects are currently better classified as type 3 ZK-EVMs.

Type 2.5 (EVM equivalent, except for gas cost)

One way to significantly improve the worst-case provers' time is to significantly increase the gas cost for specific operations in EVMs where it is difficult to perform ZK proofs. This may involve pre-compilation, KECCAK opcodes, and possibly specific modes of calling contracts or accessing memory or storage or recovery.

Changing the gas cost may reduce the compatibility of developer tools and break some applications, but we generally consider it less risky than "deeper" EVM changes. Developers should be careful not to request more than one block of gas in a transaction, and never use hard-coded gas volumes for calls (this has been a standard recommendation for a long time).

Another way to manage resource constraints is to simply set hard limits on the number of times each operation can be invoked. This is much easier to implement in the circuit, but performs much worse under the EVM security assumption. I will refer to this approach as Type 3 rather than Type 2.5.

Type 3 (almost equivalent to EVM)

Type 3 ZK-EVM is almost equivalent to EVM, but some sacrifices in exact equivalence are needed to further improve the prover (prover) time and make EVM easier to develop.

Advantages: easy to build, faster prover time

Type 3 ZK-EVMs may remove some features that are very difficult to implement in a ZK-EVM implementation, and pre-compilation is usually at the top of that list. In addition, Type 3 ZK-EVMs sometimes have subtle differences in how they handle contract code, memory, or stack.

Cons: There are relatively more incompatibilities

Type 3 ZK-EVMs aim to be compatible with most applications, while the rest require minimal rewrite work. That said, some applications will need to be rewritten because they use the pre-compilation removed by Type 3 ZK-EVM, or because of subtle dependencies on edge cases handled differently by the VM.

So who is building the type 3 ZK-EVM?

Scroll and Polygon are both type 3 ZK-EVMs in their current builds, although they are expected to improve compatibility over time. polygon has a unique design in that they perform ZK validation on their own internal language, zkASM, and use the zkASM implementation to interpret the ZK-EVM code. Despite this implementation detail, I still refer to this as true type 3 ZK-EVM, which still validates EVM code, it just uses some different internal logic to do it.

Today, no ZK-EVM team aims to become a type 3 ZK-EVM, and type 3 is just a transitional phase until the complex work of adding pre-compilation is done, and then the project can move to a type 2.5 ZK-EVM. however, in the future, a type 1 or type 2 ZK-EVM may automatically become a type 3 ZK-EVM by adding the new ZK- SNARK-friendly pre-compilation, providing developers with low prover time and gas cost capabilities.

Type 4 (High-Level Language Equivalent)

Type 4 systems work by compiling smart contract source code written in a high-level language (e.g. Solidity, Vyper or intermediate languages) into some language explicitly designed to be ZK-SNARK friendly.

Benefits: Very fast prover time

By not doing ZK proofs for all the different parts of each EVM execution step and starting directly with higher level code, you can avoid a lot of overhead.

I have described this advantage of type 4 systems in this article in just one sentence (compared to the compatibility-related disadvantages listed below), but this should not be interpreted as a value judgment! Compiling directly from a high-level language does reduce the cost significantly and helps decentralize by making it easier to be a prover (prover).

Disadvantage: compatibility would be worse

"Normal" applications written in Vyper or Solidity can be compiled to "work", but there are some important ways in which many applications will not "work ".

The address of a contract in a Type 4 system may be different from the address in the EVM, because the CREATE2 contract address depends on the exact bytecode. This breaks applications that rely on "counterfactual contracts" that have not yet been deployed, ERC-4337 wallets, EIP-2470 individual pieces, and many other applications.
Handwritten EVM bytecodes are more difficult to use, and many applications use handwritten EVM bytecodes in some parts for efficiency. And Type 4 systems may not support it, although there are ways to implement limited EVM bytecode support to meet these use cases without trying to be a full Type 3 ZK-EVM.
Many debugging infrastructures are not compatible because such infrastructures run on EVM bytecode. That said, this drawback can be mitigated by having more access to debugging infrastructure from "traditional" high-level or intermediate languages such as LLVM.
Developers should be aware of these issues.

So who is building a type 4 system?

ZKSync is a type 4 system, although it may add compatibility with EVM bytecode over time, and Nethermind's Warp project is building a compiler for the Cairo language from Solidity to Starkware, which will turn StarkNet into a de facto type 4 system.

The Future of ZK-EVM Types

This paper does not explicitly judge which of the above types of ZK-EVM is "better" or "worse"; rather, they are simply trade-offs at different points: the lower-numbered types are more compatible with existing infrastructure but will be slower, while the higher-numbered types are less compatible with existing infrastructure but will be faster. Higher numbered types are less compatible with existing infrastructure, but they are faster. Overall, the exploration of all types of ZK-EVM has been beneficial.

In addition, ZK-EVM projects can easily start with a higher numbered type and jump to a lower numbered type over time (and vice versa). For example.

A ZK-EVM can start with type 3, which decides not to include some features that are particularly difficult to ZK-prove. Later, they can add these features over time and move to a ZK-EVM of type 2.
ZK-EVMs can also start with type 2 and then become hybrid type 2/type 1 ZK-EVMs, by offering the possibility to run in a fully Ether-compatible mode, or by offering modified state trees that can be proven faster, such as Scroll is considering moving in this direction.
By adding the ability to handle EVM code, systems that start with type 4 may become type 3 over time (although developers are still encouraged to compile directly from a high-level language to reduce costs and prover time).
A Type 2 or Type 3 ZK-EVM can become a Type 1 ZK-EVM if EtherChannel itself adopts modifications to become more ZK-friendly.
A type 1 or type 2 ZK-EVM can become a type 3 ZK-EVM by adding pre-compilation to validate the code in the ZK-SNARK friendly language. this will give developers a choice between Ether compatibility and speed, and type 3 is that choice because it breaks the perfect EVM equivalence, but for practical purposes it will have the type 1 and type 2 ZK-EVM has many benefits. The main drawback may be the inability of some developer tools to understand the custom precompilation of ZK-EVM, although this can be fixed: developer tools can add generic precompilation support by supporting a configuration format that includes a precompiled EVM code equivalent implementation.
Personally, I hope that over time, with improvements to ZK-EVM and improvements to Ether itself (to make it more ZK-SNARK friendly), everything will become type 1 ZK-EVM. in such a future, we will have multiple ZK-EVM implementations that can be used both for ZK rollups and for verifying the Ether blockchain itself. Theoretically, Ethernet does not need to standardize on a single ZK-EVM implementation for L1 usage. Different clients can use different proofs, so we continue to benefit from code redundancy.

However, it will take quite a long time to realize such a future. In the meantime, we will see a lot of innovation in extending the different paths of Ethernet and Ethernet-based ZK-rollup.