Listen to Vitalik explain the future of different types of ZK-EVM
Original title: 《The different types of ZK-EVMs》
Original source: Vitalik Buterin personal homepage
Original author: Vitalik Buterin
Original translation: Block unicorn
There have been a number of high-profile announcements from "ZK-EVM" projects recently. Polygon opened up their ZK-EVM project, ZKSync released their ZKSync 2.0 plan, and the relatively new Scroll recently released their ZK-EVM. There are also continued efforts from teams in privacy and expansion exploration, teams such as Nicolas Liochon, from EVM to the alpha compiler of Starkware's zk-friendly language Cairo, and of course there are some projects I will miss.
The core goal of all of these projects is the same: Use ZK-SNARK technology to cryptographically prove Ethereum-like transaction executions, either to make it easier to verify the Ethereum chain itself, or to build zk rollups that are (close to) the same as what Ethereum offers but more scalable. But there are subtle differences between these projects, and the trade-offs they make between practicality and speed. This post will attempt to describe a classification of different "types" of EVM equivalence, and the benefits and costs of trying to achieve each type.
Overview (diagram form)
Type 1 (Fully Equivalent to Ethereum)
Type 1 ZK-EVMs strive 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, precompiles, or any other consensus logic, no matter how peripheral it is.
Advantages: Perfect compatibility
The goal is to be able to validate Ethereum blocks as they are today, or at least the execution layer (so 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 term, modifications to Ethereum that are tested in type 2 or type 3 ZK-EVMs may be introduced to Ethereum 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, the Ethereum Execution client can be used as-is to produce and process ROLLUP blocks (or at least, they can be reused once extraction is implemented and that functionality can be reused to support ETH deposited into ROLLUPs), so tools such as block explorers, block production, etc. are very easy to reuse.
Disadvantages: 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 for Ethereum blocks take many hours to produce. This could be mitigated through clever engineering to massively parallelize validators, or in the long run, with ZK-SNARK ASICs.
Who are the builders?
The Privacy and Scaling Exploration Team ZK-EVM is building a Type 1 ZK-EVM.
Type 2 (Fully Equivalent EVM)
Type 2 ZK-EVM strives to be completely equivalent to EVM, but not completely 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 structure and state tree.
The goal is to be fully compatible with existing applications, but make some minor modifications to Ethereum to make development easier and generate proofs faster.
Benefits: Full Peer-to-Peer at the VM Level
Type-2 ZK-EVM makes changes to the data structures that hold things like the Ethereum state. Fortunately, these structures are not directly accessible to the EVM itself, so applications that work on Ethereum almost always work on Type-2 ZK-EVM rollups. You won't be able to use Ethereum Execution clients as-is, but you can use them with some modifications, and you can still use EVM debugging tools and most other developer infrastructure.
There are a few exceptions, though. One incompatibility arises for applications that verify Merkle proofs of historical Ethereum blocks to validate claims about historical transactions, receipts, or state (bridges sometimes do this, for example). A ZK-EVM that replaces Keccak with a different hash function will break these proofs. However, I would generally advise against building applications this way, as future Ethereum changes (e.g. Verkle Trees) could break such applications even on Ethereum itself. A better alternative for Ethereum itself would be to add future reliable history access precompiles.
Disadvantages: Improved verification times, 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 might change Ethereum's Keccak and RLP-based Merkle Patricia trees, and possibly the block and receipt structures. Type 2 ZK-EVM might use a different hash function, e.g., Poseidon. Another natural modification would be to modify the state tree to store the code hash along with keccak, removing the need to verify the hash to handle the EXTCODEHASH and EXTCODECOPY opcodes.
These modifications significantly improve verification time, but they don’t solve all problems. The process of proving the EVM as is is still slow due to the EVM’s inherent inefficiencies and zk-unfriendliness. A simple example is memory: because MLOAD can read any 32-byte chunk, including “unaligned” chunks (where the start and end are not multiples of 32), MLOAD cannot be simply interpreted as reading a chunk; instead, it may need to read two consecutive chunks, and perform bitwise operations to merge the results.
Who are the builders?
Scroll's ZK-EVM project is moving toward a Type 2 ZK-EVM, as is Polygon Hermez. That said, neither project is finished (no ZKEVM work is done); in particular, many of the more complex precompiles are not implemented yet. As such, both projects are best thinking about Type 3 at this time.
Type 2.5 (EVM-Comparable, Excluding Gas Fees)
One way to significantly improve worst-case verification times is to drastically increase the cost of specific operations in the EVM that are difficult to prove. This could involve precompiles, KECCAK opcodes, and possibly calling conventions or specific patterns for accessing memory, storage, or restore.
Changing gas costs may reduce compatibility of developer tools and break some applications, but this is generally considered less risky than "deeper" EVM changes. Developers should be careful not to require more gas in transactions than the block capacity, and not to make calls with hard-coded gas fee amounts (this has been standard advice for developers for a long time).
Type 3 (Almost EVM-Identical)
The Type 3 zk-EVM is almost identical to the EVM, but some sacrifices are made to achieve exact sameness, further improving verification times and making the EVM easier to develop with.
Pros: Easier to build, faster verification times
Type-3 ZK-EVM may remove some features that are particularly difficult to implement in a ZK-EVM implementation. Here, precompiles are usually at the top of the list; in addition, Type-3 ZK-EVM also has sometimes subtle differences in how it handles contract code, memory, or the stack.
Cons: More incompatibilities
Type-3 ZK-EVM aims to be compatible with most applications, with minimal rewrites required for the rest. That said, some applications will need to be rewritten, either because they use precompiles that the Type-3 ZK-EVM removes, or because of subtle dependencies on edge cases that are handled differently by the EVM.
Who are the builders?
Both Scroll and Polygon are currently Type 3, though they are expected to improve compatibility over time. Polygon has a unique design where they verify their own internal language zkASM with ZK, and use the zkASM implementation to interpret ZK-EVM code. Despite this implementation detail, I would 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 become Type 3; Type 3 is just a transitional phase until the complex work of adding precompilations 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 new ZK-SNARK-friendly precompilers that provide developers with features with low verification time and gas fee costs.
Type 4 (High-Level Language Equivalent)
The way a Type 4 system works is by taking smart contract source code written in a high-level language (e.g., SOLIDITY, VYPER, or some intermediate language that both compile to), and compiling it into some language explicitly designed to be ZK-SNARK friendly.
Advantage: Very fast verification time
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 is avoided.
I describe this advantage in just one sentence in this post (compared to the large bulleted list of compatibility-related disadvantages below), but that should not be construed as a value judgment! Compiling directly from a high-level language does indeed greatly reduce costs and help decentralization by making it easier to become a prover.
Disadvantages: More incompatibilities
A "normal" application written in Vyper or Solidity can be compiled down and it will "just work", but there are some important aspects where many applications do not "just work":
1. Contracts’ addresses in a Type 4 system may be different from their addresses in the EVM, because CREATE2 contract 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.
2. Handwritten EVM bytecode is harder to use. Many applications use handwritten EVM bytecode in some parts for efficiency. 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 Type3ZK-EVM.
3. Much debugging infrastructure cannot continue because that infrastructure runs on EVM bytecode. That said, this shortcoming is mitigated by making debugging infrastructure more accessible 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 Cairo compiler from Solidity to Starkware, which will turn StarkNet into a de facto type 4 system.
The Future of ZK-EVM Types
These types are not unambiguously "better" or "worse" than the others. Rather, they are different points in the trade-off space: types that are less difficult to encode are more compatible with existing infrastructure, but slower; types that are more difficult to encode are less compatible with existing infrastructure, but faster. Overall, it’s healthy for the space that all of these types of people are exploring.
1. A ZK-EVM could start as a Type 3 and decide not to include some features that are particularly hard to ZK-prove. Later, they could add those features over time and move to a Type 2.
2. A ZK-EVM could start as a Type 2 and then become a hybrid Type 2/Type 1 ZK-EVM by offering the possibility to run in full Ethereum compatible mode or use a modified state tree that can be proven faster. Sroll is considering moving in this direction.
3. A system that starts out as type 4 could become type 3 over time as the ability to handle EVM code is later added (although developers are still encouraged to compile directly from a high-level language to reduce fees and verification time). 4. A type 2 or type 3 ZK-EVM could become a type 1 ZK-EVM if Ethereum itself adopts its modifications in an effort to become more ZK-friendly. 5. A type 1 or type 2 ZK-EVM could become a type 3 ZK-EVM by adding a precompiler to verify code in a ZK-SNARK-friendly language. This would let developers choose between Ethereum compatibility and speed, which would be type 3 as it breaks parity with a perfect EVM, but for all practical purposes it would have many of the benefits of both type 1 and type 2. The main drawback is probably that some developer tools don't understand custom precompiles for ZK-EVM, though this is fixable: developer tools could add generic precompile support by supporting a configuration format that includes precompiled EVM code equivalent implementations.Personally, I hope that everything will become Type 1 over time, with improvements to ZK-EVM and improvements to Ethereum itself to make it more suitable for ZK-Snark. In such a future, we would have multiple ZK-EVM implementations, both for ZK-Rollups and for validating the Ethereum chain itself. In theory, there would be no need for Ethereum to standardize on a single ZK-EVM implementation for L1 use; different clients could use different proofs, so we continue to benefit from code redundancy.
However, it will take quite some time before we get to such a future. In the meantime, we will see a lot of innovation on different avenues for scaling Ethereum and ZK-Rollups on top of Ethereum.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
