There have been many high-profile announcements of “ZK-EVM” projects recently, but not every project is “equivalent” the same. This post will attempt to describe a taxonomy of the different “types” of EVM equivalence, as well as the benefits and costs of trying to achieve each type.
Author: Vitalik Buterin (V God)
From: “V God: The Future of Different Types of ZK-EVM” by Block unicorn (compiler)
There have been many high-profile announcements of the “ZK-EVM” project recently. Polygon opened up their ZK-EVM project, ZKSync released their ZKSync 2.0 plans, and relatively new Scroll recently released their ZK-EVM as well. There are also ongoing efforts from the teams on Privacy and Outreach Exploration, Nicolas Liochon et al, from 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 of these projects is the same: to use ZK-SNARK technology to cryptographically prove Ethereum-like transaction execution, either to make it easier to verify the Ethereum chain itself, or to build something close to what Ethereum provides (closer ) the same but more scalable zk rollup. But there are subtle differences between these projects, and their trade-offs between practicality and speed. This post will attempt to describe a taxonomy of the different “types” of EVM equivalence, as well as the benefits and costs of trying to achieve each type.
Overview (Graphical Form)
Type 1 (exactly Ethereum equivalent)
Type 1 ZK – EVM seeks to be a complete and uncompromising 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.
Advantage: perfect compatibility
The goal is to be able to validate Ethereum blocks as 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 is included).
Type 1: ZK-EVM is what we ultimately need to make Ethernet Layer 1 itself more scalable. In the long run, modifications to the ether tested in Type 2 or Type 3 ZK-EVMs may be introduced into the 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 large amounts of infrastructure. For example, Ethereum Execution clients can be used as-is to generate and process ROLLUP blocks (or at least, once a withdrawal is implemented, they can be reused, and the functionality can be reused to back ETH deposited into ROLLUP), so the block resource Tools like manager, 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 extensive computation to validate zk. The goal of Type 1 is to fully replicate Ethereum, so it has no way of mitigating these inefficiencies. Currently, proofs of Ethereum blocks take many hours to generate. This situation can be mitigated by clever engineering to massively parallelize validators, or in the long run, ZK-SNARK ASICs.
Who is the builder?
The privacy and extension exploration team ZK-EVM is building a Type 1 ZK-EVM.
Type 2 (full EVM equivalent)
Type 2 ZK – EVM seeks 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 some minor modifications to Ethereum to make development easier and generate proofs faster.
Advantage: Full peering at the virtual machine level
Type 2 ZK-EVM makes changes to data structures that hold things like ether state. Fortunately, these structures are not directly accessible by the EVM itself, so applications working on Ethereum will almost always work on type 2 ZK-EVM rollups. You won’t be able to use the Ethereum Execution clients as-is, but you can use them with some modifications, and you’ll still be able to use the EVM debugging tools and most other developer infrastructure.
But there are a few exceptions. An incompatibility has arisen for applications that validate Merkle proofs of historical ether blocks to verify claims about historical transactions, receipts, or states (eg bridges sometimes do). 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 (eg. Verkle Trees) could break such applications even on ether itself. A better alternative for Ethereum itself is to add future reliable historical access precompiles.
Cons: Improved verification time, but still slow
Type 2 ZK-EVM provides faster verification times than Type 1, primarily by removing parts of the ether stack that rely on the needlessly 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, eg, Poseidon. Another natural modification would be to modify the state tree to store code hashes and keccak so that verification hashes are no longer required to process EXTCODEHASH and EXTCODECOPY opcodes.
These modifications significantly improve verification time, but they do not solve all problems. The process of proving EVM as-is is still slow due to its inherent inefficiency and zk-unfriendliness. A simple example is memory: because MLOAD can read any 32-byte block, including “unaligned” blocks (where start and end are not multiples of 32), MLOAD cannot simply be interpreted as reading a block; instead, it may Two consecutive blocks need to be read, and bit operations performed to combine the results.
Who is the builder?
Scroll’s ZK-EVM project is moving in the direction of the Type 2 ZK-EVM, as is the case with Polygon Hermez. That said, neither project is done yet (no ZKEVM work done); in particular, many of the more complex precompiles are not yet implemented. Therefore, it is best to consider Type 3 for both projects at the moment.
2.5 type (equivalent to evm, excluding gas cost)
One way to significantly improve worst-case verification time is to drastically increase the overhead cost of certain operations that are difficult to prove in EVM. This might involve precompiling, KECCAK opcodes, and possibly calling conventions or specific modes of accessing memory, storing, or restoring.
Changing gas cost costs may reduce developer tool compatibility and break some applications, but are generally considered less risky than “deeper” EVM changes. Developers should be careful not to require gas fees in transactions to exceed the capacity of the block, and not to call with a hardcoded gas fee amount (this has been the standard recommendation for developers for a long time).
Type 3 (almost equivalent to EVM)
Type 3 zk-EVM is almost equivalent to EVM, but in order to achieve the exact 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-EVMs may remove some features that are particularly difficult to implement in ZK-EVM implementations. Here, precompilation is usually at the top of the list; in addition, Type 3 ZK-EVMs also sometimes have subtle differences in how they handle contract code, memory, or the stack.
Cons: more incompatibilities
Type 3 ZK-EVMs aim to be compatible with most applications, with the remainder requiring minimal rewriting. That said, some applications need to be rewritten, either because they use type 3 ZK-EVM-removed precompiles, 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 where they validate their own internal language zkASM with ZK and use the zkASM implementation to interpret the ZK-EVM code. Despite such implementation details, I still call it a true Type3ZK-EVM; it can still verify EVM code, it’s just done with some different internal logic.
Today, no ZK-EVM team wants to be Type 3; Type 3 is just a transitional phase until the complex work of adding precompiles is done and the project 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 offers developers features with low verification time and gas cost costs.
Type 4 (equivalent to a 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 something explicitly designed to be ZK-snark friendly language.
Pros: Verification time is very fast
A lot of overhead can be avoided by not using ZK to prove all the different parts of each EVM execution step, and starting directly from higher level code.
I describe this advantage in just one sentence in this post (compared to the large bulleted list of compatibility-related disadvantages below), but this should not be construed as a value judgment! Compiling directly from a high-level language does greatly reduce costs and helps decentralization by making it easier to be a prover.
Cons: 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 that many applications don’t “just work”:
– The addresses of contracts in type 4 systems may differ from their addresses in the EVM, because CREATE2 contract addresses depend on the exact bytecode. This breaks applications that rely on yet-to-be-deployed “counterfactual contracts”, ERC-4337 wallets, EIP-2470 singletons, and many others.
– Handwritten EVM bytecode is harder to work with. For efficiency, many applications use handwritten EVM bytecode for some parts. Type 4 systems may not support it, although there are ways to implement limited EVM bytecode support to meet these use cases without striving to be a full Type3ZK-EVM.
– A lot of debugging infrastructure cannot continue because these infrastructures run on EVM bytecode. That said, this shortcoming is mitigated by having more access to debugging infrastructure from “traditional” high-level or intermediate languages (eg, 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 that will turn StarkNet into a de facto Type 4 system.
The future of ZK-EVM types
These types are not explicitly “better” or “worse” than others. Instead, they are different points in the trade-off space: types with less 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 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-proof. Later, they can add these features over time and move to Type 2.
– ZK-EVM can start with type 2 and then become a hybrid type 2/type 1 ZK-EVM by providing the possibility to run in full ether compatibility mode or use a modified state tree that can be proved faster. Sroll is considering going in that direction.
– Systems that start with type 4 may become type 3 over time as the ability to process EVM code is added later (though developers are still encouraged to compile directly from high-level languages to reduce overhead and verification time).
– A Type 2 or Type 3 ZK-EVM can become a Type 1 ZK-EVM if Etherum itself adopts its modifications in an effort to be more ZK friendly.
– A type 1 or type 2 ZK-EVM can become a type 3 ZK-EVM by adding a precompiler to verify code in a ZK-SNARK friendly language. This will let the developer choose between ether compatibility and speed, it will be type 3 as it breaks the equality of perfect EVM, but from practical purpose and purpose it will have type 1 and type 2 many benefits. The main drawback may be that some developer tools do not understand ZK-EVM’s custom precompilation, although this can be fixed: developer tools can add generic precompilation support by supporting a configuration format that includes an equivalent implementation of precompiled EVM code.
Personally, I hope that over time everything will become type 1, by improving ZK-EVM and improving the ether itself to make it more suitable for ZK-Snark. In such a future, we will have multiple ZK-EVM implementations, both for ZK aggregation and for validating the Ethereum chain itself. In theory, it is not necessary for Ethereum to standardize on the single ZK-EVM implementation used by L1; different clients can use different proofs, so we continue to benefit from code redundancy.
However, it will take us quite some time to reach such a future. At the same time, we will see many innovations in different paths to scaling Ethereum and Ethereum-based ZK-Rollers.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/v-god-analysis-of-the-advantages-and-disadvantages-of-the-current-4-different-types-of-zk-evm-and-future-prospects/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.