Vitalik: The future of different types of ZK-EVM
Original title: "The different types of ZK-EVMs》
Original Author: Vitalik
Original compilation: Block unicorn
Original title: "
Original Author: Vitalik
Original compilation: Block unicorn
Recently, there have been many high-profile announcements made by "ZK-EVM" projects. Polygon open-sourced their ZK-EVM project, ZKSync released their ZKSync 2.0 plans, and relatively new Scroll recently released their ZK-EVM. There are also ongoing efforts from the Privacy and Extended Exploration teams, the teams of Nicolas Liochon et al., from the EVM to an alpha compiler for Starkware's zk-friendly language Cairo, and of course there are some projects I'll miss.
The core goal of all these projects is the same: use ZK-SNARK technology to cryptographically prove Ethereum-like transaction execution, either make it easier to verify the Ethereum chain itself, or build content similar to what Ethereum provides (closer ) same but more scalable zk rollup. But there are subtle differences between these projects, and their trade-offs between utility and speed. This post will attempt to describe a taxonomy of the different "types" of EVM equivalence, and the benefits and costs of trying to implement each.
Overview (diagram format)
Type 1 (fully equivalent to Ethereum)
The first type of ZK-EVM strives to be completely and uncompromisingly equivalent to Ethereum. They do not change any part of the Ethereum system to make generating proofs easier. They do not replace hashes, state trees, transaction trees, precompilations, or any other consensus logic, no matter how peripheral it is.
Advantage: perfect compatibility
Our goal is to be able to validate Ethereum blocks like we do now, or at least the execution layer (so beacon chain consensus logic is not included, but all transaction execution and smart contract and account logic are included).
Type 1: ZK-EVM is what we ultimately need to make Ethernet layer 1 itself more scalable. In the long run, modifications to ether that were tested in a type 2 or type 3 ZK-EVM may be introduced into ether itself, but such a redesign comes with its own complexities.
Type 1: ZK-EVMs are also ideal for rollups, as they allow rollups to reuse a lot of infrastructure. For example, an Etherum Execution client can be used as-is to generate and process ROLLUP blocks (or at least, they can be reused once fetching is implemented, and that functionality can be reused to support ETH deposits into ROLLUPs), so block resources Tools like managers, block production, etc. are very easy to reuse.
Disadvantage: verification time
Ethereum was not originally designed around zk-friendliness, so many parts of the ethereum protocol require a lot of computation to verify zk. Type 1 aims to replicate Ethereum exactly, so it has no way to mitigate these inefficiencies. Currently, proofs of Ethereum blocks take many hours to generate. This situation can be mitigated by clever engineering to massively parallelize the verifier, or in the long run, by ZK-SNARK ASICs.
Who is the builder?
The Privacy and Scaling Exploration Team ZK-EVM is building a Type 1 ZK-EVM.
Type 2 (fully equivalent EVM)
The second type of ZK - EVM strives to be fully equivalent to EVM, but not fully equivalent to Ethereum. That is, they look exactly like Ethereum "from the inside", but they have some differences on the outside, especially in data structures such as block structures and state trees.
The goal is to be fully compatible with existing applications, but with minor modifications to Ethereum to make development easier and generate proofs faster.
Advantage: Full peer-to-peer at the virtual machine level
Type 2 ZK-EVM makes changes to the data structures that hold things like the state of the ether. Fortunately, these structures are not directly accessible by the EVM itself, so applications that work on Ethereum will almost always work on Type 2 ZK-EVM rollups. You won't be able to use the Etherum Execution clients as-is, but you can use them with some modifications, and you'll still have access to EVM debugging tools and most other developer infrastructure.
But there are a few exceptions. An incompatibility arises for applications that verify Merkle proofs of historical ether blocks to verify claims about historical transactions, receipts, or state (for example, bridges sometimes do this). Replacing Keccak's ZK-EVM with a different hash function would break these proofs. However, I generally advise against building applications this way, as future ether changes (such as Verkle Trees) could break such applications even on ether itself. A better alternative to Ethereum itself would be to add future reliable history access precompilation.
Cons: Improved validation time, but still slow
Type 2 ZK-EVM provides faster verification times than Type 1, mainly by removing parts of the Ethereum stack that rely on unnecessarily complex and unfriendly ZK encryption. In particular, they may change Ethereum's Keccak and RLP-based Merkle Patricia trees, and possibly block and receive structures. Type 2 ZK-EVMs may use a different hash function, for example, Poseidon. Another natural modification is to modify the state tree to store code hashes and keccak, so that verification hashes are no longer required to handle EXTCODEHASH and EXTCODECOPY opcodes.
These modifications improve verification times significantly, but they do not solve all problems. Due to the inherent inefficiency and zk-unfriendliness of the EVM, the process of proving the EVM as-is is still slow. A simple example is memory: because MLOAD can read any 32-byte block, 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 is the builder?
Scroll's ZK-EVM project is moving towards a Type 2 ZK-EVM, as is Polygon Hermez. That said, neither project is finished yet (the ZKEVM work isn't done); in particular, many of the more complex precompilations haven't been implemented yet. Therefore, type 3 is best considered for both projects at this time.
Type 2.5 (comparable to EVM, excluding gas costs)
One way to significantly improve worst-case verification time is to substantially increase the overhead cost of certain operations in the EVM that are difficult to prove. This may involve precompilation, KECCAK opcodes, but also calling conventions or specific modes of accessing memory, storage, or restoration.
Changing gas costs may reduce developer tool compatibility and break some applications, but is generally considered less risky than "deeper" EVM changes. Developers should take care not to require more gas in transactions than the block's capacity, and not to make calls with hardcoded gas fee amounts (this has been standard advice to developers for a long time).
Type 3 (almost equivalent to EVM)
Type 3 ZK-EVM is almost equivalent to EVM, but to achieve the same, some sacrifices need to be made to further improve verification time and make EVM easier to develop.
Pros: 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, precompilation is usually at the top of the list; moreover, Type 3 ZK-EVMs sometimes have subtle differences in how they handle contract code, memory, or the stack.
Cons: more incompatibilities
The Type 3 ZK-EVM aims to be compatible with most applications and require minimal rewriting of the rest. That said, some applications need to be rewritten, either because they use precompilations that the Type 3 ZK-EVM removes, or because of subtle dependencies on edge cases that are handled differently by the EVM .
Who is the builder?
Scroll and Polygon are both type 3 in their current form, although they are expected to improve compatibility over time. Polygon has a unique design, they use ZK to verify their own internal language zkASM, and use zkASM implementation to interpret ZK-EVM code. Despite this implementation detail, I'd still call it a true Type3ZK-EVM; it can still verify EVM code, it just uses some different internal logic to do so.
Today, no ZK-EVM team wants to be Type 3; Type 3 is just a transitional phase until the complex work of adding precompilation is complete and projects can move to Type 2.5. However, in the future, a Type 1 or Type 2 ZK-EVM may voluntarily become a Type 3 ZK-EVM by adding a new ZK-SNARK friendly precompiler that provides developers with low verification time and gas cost features.
Type 4 (equivalent to high-level language)
Type 4 systems work by taking smart contract source code written in a high-level language (e.g. SOLIDITY, VYPER, or some intermediate language that both compiles to) and compiling it into some kind of language explicitly designed to be ZK-snark friendly language.
Pros: Verification time is very fast
By not using ZK to prove all the different parts of each EVM execution step, and starting directly from the higher level code, a lot of overhead can be avoided.
I describe this advantage in one sentence in this post (compared to the large bulleted list of compatibility-related disadvantages below), but this should not be interpreted as a value judgment! Compiling directly from a high-level language can indeed greatly reduce costs and help decentralization by making it easier to be a prover.
Cons: more incompatibilities
A "normal" application written in Vyper or Solidity can be compiled and it will "just work", but there are some important aspects that many applications do not "just work":
The addresses of contracts in a type 4 system may differ from their addresses in the EVM, since CREATE2 contract addresses depend on the exact bytecode. This breaks applications that depend on "counterfactual contracts", ERC-4337 wallets, EIP-2470 singletons, and many other applications that have not yet been deployed.
Handwritten EVM bytecode is harder to work with. For efficiency, many applications use hand-written EVM bytecode for some parts. Type 4 systems may not support it, although there are ways to implement limited EVM bytecode support to satisfy these use cases without striving to be a full Type3 ZK-EVM.
Much of the debugging infrastructure cannot continue because it runs on EVM bytecode. That said, this shortcoming is mitigated by accessing debugging infrastructure more from "traditional" high-level or intermediate languages (e.g., LLVM).
Developers should be aware of these issues.
Who is the builder?
ZKSync is a type 4 system, although over time it may increase compatibility with EVM bytecode. NetherMind's Warp project is building a Cairo compiler from Solidity to Starkware, which will turn StarkNet into a de facto Type 4 system.
The future of several types of ZK-EVM
These types are not explicitly "better" or "worse" than others. Rather, they are points of difference in the trade-off space: types that are less difficult to code are more compatible with existing infrastructure, but slower; types that are more difficult to code are less compatible with existing infrastructure, but faster . Overall, all these types of people are exploring, which is healthy for the field.
ZK-EVM can start with type 3, deciding not to include some features that are particularly difficult to ZK-prove. Later, they can add these features over time and move to Type 2.
A ZK-EVM can start out as a Type 2 and then become a hybrid Type 2/Type 1 ZK-EVM by offering the possibility to run in full Ethernet compatibility mode or use a modified state tree that can be proven faster. Sroll is considering moving in this direction.
Systems starting with Type 4 may become Type 3 over time as the ability to handle EVM code is added later (though developers are still encouraged to compile directly from high-level languages to reduce expense and verification time).
Personally, I hope that over time, everything will become Type 1, by improving ZK-EVM and improving Ethereum itself to make it more suitable for ZK-Snark. In such a future, we will have multiple ZK-EVM implementations, both for ZK rollups and for validating Ethereum itself. In theory, there is no need for Ethereum to standardize on a single ZK-EVM implementation used by L1; different clients could use different proofs, so we continue to benefit from code redundancy.
