Vitalik: The Future of Different Types of ZK-EVM

Original Title: 《The different types of ZK-EVMs》

Author: Vitalik

Compilation: Block unicorn, Foresight News

Recently, many "ZK-EVM" projects have made high-profile announcements. Polygon has opened their ZK-EVM project, ZKSync has released their ZKSync 2.0 plan, and the relatively newer Scroll has also announced their ZK-EVM. There are also ongoing efforts from teams exploring privacy and scalability, such as Nicolas Liochon’s team, from the alpha compiler of the zk-friendly language Cairo from EVM to Starkware, and of course, there are some projects I might miss.

The core goal of all these projects is the same: to use ZK-SNARK technology to create cryptographic proofs for Ethereum-like transaction executions, either to make verifying the Ethereum chain itself easier or to build zk rollups that provide (almost) the same content as Ethereum but with greater scalability. However, there are subtle differences between these projects, as well as trade-offs between their practicality and speed. This article will attempt to describe the different "types" of EVM equivalence and the benefits and costs of attempting to implement each type.

Overview (in chart form)

Type 1 (Fully Equivalent to Ethereum)

The first type of ZK-EVM strives for complete and uncompromising equivalence to Ethereum. They do not change any part of the Ethereum system to make proof generation easier. They will not replace hashes, state trees, transaction trees, precompiles, or any other consensus logic, no matter how peripheral.

Advantages: Perfect Compatibility

Our goal is to be able to verify Ethereum blocks as we do now, or at least verify the execution layer (thus, the beacon chain consensus logic is not included, but all transaction execution and smart contract and account logic is included).

Type 1: ZK-EVM is what we ultimately need to make Ethereum Layer 1 itself more scalable. In the long run, modifications to Ethereum tested in Type 2 or Type 3 ZK-EVMs may be introduced into Ethereum itself, but such redesigns come with their own complexities.

Type 1: ZK-EVM is also an ideal choice for rollups, as they allow rollups to reuse a significant amount of underlying infrastructure. For example, the Ethereum Execution client can be used as-is to generate and process ROLLUP blocks (or at least, once extraction is implemented, they can be reused, and that functionality can be reused to support ETH stored in the ROLLUP), making block explorers, block production, and other tools very easy to reuse.

Disadvantages: Verification Time

Ethereum was not originally designed with zk-friendliness in mind, so many parts of the Ethereum protocol require significant computation to verify zk. Type 1 aims to fully replicate Ethereum, so it has no way to mitigate these inefficiencies. Currently, proving Ethereum blocks takes many hours to produce. This situation can be alleviated through clever engineering to massively parallelize verifiers, or in the long term, through ZK-SNARK dedicated integrated circuits.

Who are the builders?

The privacy and scalability exploration team ZK-EVM is building Type 1 ZK-EVM.

Type 2 (Fully Equivalent EVM)

The second type of ZK-EVM aims for complete equivalence to the EVM but not fully equivalent to Ethereum. That is to say, they "look" completely like Ethereum from the inside, but they have some differences on the outside, particularly in data structures, such as block structure and state trees.

The goal is to be fully compatible with existing applications while making some minor modifications to Ethereum to facilitate development and generate proofs more quickly.

Advantages: Full Equivalence at the Virtual Machine Level

Type 2 ZK-EVM makes changes to the data structures that store Ethereum state and similar content. Fortunately, these structures are not directly accessible by the EVM itself, so applications that work on Ethereum almost always work on Type 2 ZK-EVM rollups. You will not be able to use the Ethereum Execution client as-is, but you can use it with some modifications, and you can still use EVM debugging tools and most other developer infrastructure.

However, there are a few exceptions. For applications that verify historical Ethereum blocks using Merkle proofs to validate claims about historical transactions, receipts, or states, there is an incompatibility (for example, bridges sometimes do this). Replacing Keccak with a different hash function in ZK-EVM will break these proofs. However, I generally advise against building applications this way, as future changes to Ethereum (such as Verkle Trees) could also break such applications on Ethereum itself. A better alternative for Ethereum would be to add future-proof historical access precompiles.

Disadvantages: Improved Verification Time, But Still Slow

Type 2 ZK-EVM offers faster verification times than Type 1, primarily by removing parts of the Ethereum stack that rely on unnecessarily complex and unfriendly zk cryptography. In particular, they may change Ethereum's Keccak and RLP-based Merkle Patricia trees, and may also change block and receipt structures. Type 2 ZK-EVM may use different hash functions, such as Poseidon. Another natural modification is to alter the state tree to store code hashes and keccak, thus eliminating the need to verify hashes for handling EXTCODEHASH and EXTCODECOPY opcodes.

These modifications significantly improve verification times, but they do not solve all problems. Due to the inherent inefficiencies of the EVM and its unfriendly nature towards zk, the process of proving the EVM as-is is still quite slow. A simple example is memory: because MLOAD can read any 32 bytes, including "unaligned" blocks (where the start and end are not multiples of 32), MLOAD cannot simply be interpreted as reading a block; instead, it may need to read two consecutive blocks and perform bit operations to combine the results.

Who are the builders?

Scroll's ZK-EVM project is developing towards Type 2 ZK-EVM, as is Polygon Hermez. That is to say, neither of these projects is complete (they have not finished ZK-EVM work); in particular, many more complex precompiles have not yet been implemented. Therefore, both projects are currently best considered as Type 3.

Type 2.5 (Equivalent to EVM, Excluding Gas Costs)

One way to significantly improve the worst-case verification time is to greatly increase the gas cost of specific operations in the EVM that are difficult to prove. This may involve precompiles, KECCAK opcodes, and may also involve specific patterns for calling conventions or accessing memory, storage, or recovery.

Changing gas cost may reduce the compatibility of developer tools and disrupt some applications, but it is generally considered to carry less risk than "deeper" EVM changes. Developers should be mindful that the gas costs required in transactions do not exceed the capacity of the block and should not use hardcoded gas amounts for calls (this has been standard advice for developers for a long time).

Type 3 (Almost Equivalent to EVM)

Type 3 ZK-EVM is almost equivalent to the EVM, but some sacrifices must be made to achieve complete equivalence in order to further improve verification time and make the EVM easier to develop.

Advantages: Easier to Build, Faster Verification Time

Type 3 ZK-EVM may remove some features that are particularly difficult to implement in ZK-EVM implementations. Here, precompiles are usually at the top of the list; additionally, Type 3 ZK-EVM may have subtle differences in how it handles contract code, memory, or the stack.

Disadvantages: More Incompatibility

Type 3 ZK-EVM aims to be compatible with most applications, with the remainder requiring minimal rewriting. That is to say, some applications will need to be rewritten, either because they use precompiles that Type 3 ZK-EVM has removed or because of subtle dependencies on edge cases that are handled differently by the EVM.

Who are the builders?

Scroll and Polygon are currently both in the form of Type 3, although over time, they are expected to improve compatibility. Polygon has a unique design where they use their internal language zkASM to verify using ZK, and implement ZK-EVM code using zkASM. Despite such implementation details, I still refer to it as a true Type 3 ZK-EVM; it can still verify EVM code, just using some different internal logic to accomplish it.

Today, no ZK-EVM team wants to be Type 3; Type 3 is merely a transitional phase until the complex work of adding precompiles is completed, and projects can transition to Type 2. However, in the future, Type 1 or Type 2 ZK-EVMs may voluntarily become Type 3 ZK-EVMs by adding new ZK-SNARK friendly precompilers, providing developers with low verification time and gas cost capabilities.

Type 4 (Equivalent to High-Level Languages)

Type 4 systems operate by taking smart contract source code written in high-level languages (such as SOLIDITY, VYPER, or some intermediate language compiled from both) and compiling it into a language explicitly designed to be ZK-SNARK friendly.

Advantages: Very Fast Verification Time

By not using ZK to prove every different part of the EVM execution step and starting directly from higher-level code, a lot of overhead can be avoided.

I have described this advantage in just one sentence in this article (compared to the large bullet list of disadvantages related to compatibility below), but this should not be interpreted as a value judgment! Directly compiling from high-level languages can indeed significantly reduce costs and help decentralize by making it easier to become a prover.

Disadvantages: More Incompatibility

A "normal" application written in Vyper or Solidity can be compiled down, and it will "work normally," but there are some important aspects where many applications do not "work normally":

• Contracts in Type 4 systems may have different addresses than their addresses in the EVM, as CREATE2 protocol addresses depend on the exact bytecode. This breaks applications that rely on "counterfactual contracts" that have not yet been deployed, ERC-4337 wallets, EIP-2470 singletons, and many other applications.
• Handwritten EVM bytecode is harder to use. To improve efficiency, many applications use handwritten EVM bytecode in certain parts. Type 4 systems may not support it, although there are some ways to implement limited EVM bytecode support to meet these use cases without the effort of becoming a complete Type 3 ZK-EVM.
• Many debugging infrastructures cannot continue because these infrastructures run on EVM bytecode. That said, this disadvantage is mitigated by accessing debugging infrastructures more from "traditional" high-level or intermediate languages (e.g., LLVM).

Developers should be aware of these issues.

Who are the builders?

ZKSync is a Type 4 system, although it may increase compatibility with EVM bytecode over time. NetherMind's Warp project is building a compiler from Solidity to Cairo for Starkware, which will effectively turn StarkNet into a Type 4 system.

The Future of Various Types of ZK-EVM

These types are not explicitly "better" or "worse" than others. Instead, they are different points in the trade-off space: types with lower coding difficulty are more compatible with existing infrastructure but slower; types with higher coding difficulty are less compatible with existing infrastructure but faster. Overall, all these types are exploring, which is healthy for the field.

• ZK-EVM can start from Type 3 and decide not to include some particularly difficult ZK-proof features. Later, they can add these features over time and transition to Type 2.
• ZK-EVM can start from Type 2 and then become a hybrid Type 2/Type 1 ZK-EVM by providing the possibility to run in fully Ethereum-compatible mode or using modified state trees that can prove faster. Scroll is considering moving in this direction.
• Systems starting from Type 4 may transition to Type 3 over time as capabilities to handle EVM code are added later (although developers are still encouraged to compile directly from high-level languages to reduce costs and verification times).
• If Ethereum itself adopts its modifications to become more zk-friendly, then Type 2 or Type 3 ZK-EVMs can become Type 1 ZK-EVMs.
• Type 1 or Type 2 ZK-EVMs can become Type 3 ZK-EVMs by adding precompilers to verify code in ZK-SNARK friendly languages. This would allow developers to choose between Ethereum compatibility and speed, which would be Type 3, as it breaks the perfect EVM equivalence, but from a practical purpose and intent, it would have many benefits of Type 1 and Type 2. The main drawback might be that some developer tools do not understand the custom precompiles of ZK-EVM, although this can be fixed: developer tools can add general precompile support by supporting configuration formats that include implementations of EVM code equivalence.

Personally, I hope that over time, everything will evolve into Type 1, making it more suitable for ZK-SNARK through improved ZK-EVM and improved Ethereum itself. In such a future, we will have multiple ZK-EVM implementations that can be used for both ZK rollups and verifying Ethereum itself. Theoretically, there is no need for a single ZK-EVM implementation to be standardized for L1 usage; different clients can use different proofs, allowing us to continue benefiting from code redundancy.

However, it will take quite a long time to reach such a future. In the meantime, we will see many innovations on different paths to scaling Ethereum and Ethereum-based ZK rollups.