Vitalik explains 5 types of ZK-EVM in detail

Thanks to the PSE, Polygon Hermez, Zksync, Scroll, Matter Labs and Starkware teams for discussion and review.

There have been a number of announcements made recently by the “ZK-EVM” project. Polygon open sourced their ZK-EVM project, ZKSync released their ZKSync 2.0 plans, and relatively new Scroll recently announced their ZK-EVM as well. The Privacy and Scaling Explorations team, Nicolas Liochon, and others are also working on everything from EVM to an alpha compiler for Starkware’s ZK-friendly language Cairo, and of course a few more I don’t know about.

The core goal of all these projects is the same: to use ZK-SNARK technology to make cryptographic proofs of Ethereum-like transaction execution, or to make it easier to verify the Ethereum chain itself, or to build a (closer to) equivalent of what Ethereum provides, but more Extensible ZK-rollup. But there are subtle differences between these projects, and the trade-offs they make between practicality and speed.

This post will attempt to categorize the EVM equivalence of different “types” of ZK-EVMs , as well as the benefits and costs of trying to implement each.

Overview (Graphical)


Type 1 (exactly Ethereum equivalent)

Type 1 ZK-EVM seeks to be fully and uncompromisingly equivalent to Ethereum. They do not change any part of the Ethereum system to make it easier to generate proofs. They do not replace hashes, state trees, transaction trees, precompiles, or any other consensus logic, no matter how peripheral.

Advantages: perfect compatibility

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

A 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 3 ZK-EVMs may be introduced into Ethereum itself, but this re-architecture also has its own complexities.

Type 1 ZK-EVMs are also ideal for Rollups as they allow Rollups to reuse a lot of infrastructure. For example, Ethereum execution clients can be used as-is to generate and process rollup blocks (or at least, they can be used after a withdrawal is implemented, and the functionality can be reused to support ETH deposits in rollups), so tools such as Block explorers, block production, etc. are very easy to reuse.

Cons: Proof time

Ethereum was not originally designed around ZK friendliness, so many parts of the Ethereum protocol require a lot of computation to be ZK proofs. Type 1 ZK-EVM is designed to replicate Ethereum exactly, so it cannot mitigate these inefficiencies. Currently, proofs of Ethereum blocks take many hours to generate. This can be mitigated by clever massively parallelizing prover engineering or in the long run by ZK-SNARK ASICs.

Who is building it?

The Privacy and Scaling Explorations team ZK-EVM is building the Type 1 ZK-EVM.

Type 2 (exactly equivalent to EVM)

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 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 Ethereum to make development easier and generate proofs faster.

Pros: Perfect equivalent at VM level

Type 2 ZK-EVMs make changes to data structures that hold things like Ethereum state. Fortunately, these are structures that are not directly accessible by the EVM itself, so applications running on Ethereum can almost always run on a Type 2 ZK-EVM Rollup. You won’t be able to execute clients using Ethereum as-is, but you can use them with some modifications and still have access to EVM debugging tools and most other developer infrastructure.

There are a few exceptions. An incompatibility has arisen for applications that validate Merkle proofs of Ethereum historical blocks to verify claims about historical transactions, receipts, or state (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 Ethereum changes (such as Verkle trees) could break such applications even on Ethereum itself. A better option would be to have Ethereum itself add future-proof historical access precompiles.

Cons: Improved but still slow proof time

Type 2 ZK-EVM provides faster proof times than Type 1, mainly by removing the Ethereum stack that relies on unnecessarily complex and ZK-unfriendly cryptographic parts. In particular, they might change Ethereum’s Keccak and RLP-based Merkle Patricia trees, and possibly block and receipt structures. Type 2 ZK-EVMs may use a different hash function such as Poseidon. Another natural modification would be to modify the state tree to store code hashes and keccak to handle EXTCODEHASH and EXTCODECOPY opcodes without verifying the hash.

These modifications significantly improve the prover’s time, but they do not solve all problems. The slowness of the EVM and all the inefficiencies and ZK unfriendliness inherent to the EVM must still be demonstrated as-is. A simple example is memory: since anMLOAD can read any 32-byte block, including “unaligned” blocks (beginning and ending are not multiples of 32), MLOAD cannot simply be interpreted as reading a block; Instead, it may require reading two consecutive blocks and performing bit operations to combine the results.

Who is building it?

Scroll’s ZK-EVM project is heading towards the Type 2 ZK-EVM, as is Polygon Hermez. That said, neither project is complete yet. In particular, many of the more complex precompiles are not implemented yet. So both projects are better considered Type 3 at the moment.

Type 2.5 (EVM equivalent, except gas cost)

One way to significantly improve worst-case prover time is to greatly increase the gas cost of certain operations in the EVM that are difficult to ZK proofs. This may involve precompilation, KECCAK opcodes, and possibly specific modes of calling contracts or accessing memory or storing or restoring.

Changing the gas cost may reduce developer tool compatibility and break some applications, but is generally considered less risky than a “deeper” EVM change. Developers should be careful not to exceed the gas size of a block in a transaction, and never call with a hardcoded gas amount (this has been standard developer advice for a long time).

Another way to manage resource constraints is to simply put a hard limit on the number of times each operation can be called. This is easier to implement in circuit, but performs much worse under EVM safety assumptions. I call this method Type 3 instead of Type 2.5.

Type 3 (almost equivalent to EVM)

Type 3 ZK-EVMs are nearly equivalent to EVMs, but with some sacrifices in exact equivalence to further reduce validator time and make EVMs easier to develop.

Advantages: Easier to build, faster verification time

Type 3 ZK-EVMs may remove some features that are extremely difficult to implement in ZK-EVM implementations. Precompiles are usually at the top of the list here. Additionally, Type 3 ZK-EVMs sometimes have subtle differences in how they handle contract code, memory, or stacks.

Disadvantage: more incompatibility

The Type 3 ZK-EVM aims to be compatible with most applications and requires minimal rewriting of the rest. That said, there will be some applications that will need to be rewritten because they use precompilation removed by the Type 3 ZK-EVM, or because of subtle dependencies on edge cases that the VM handles differently.

Who is building it?

Both Scroll and Polygon are Type 3 ZK-EVMs in their current form, although they are expected to improve compatibility over time. Polygon has a unique design, they are validating their own internal language called zkASM in ZK, and they use the zkASM implementation to interpret the ZK-EVM code. Despite this implementation detail, I call it a true Type 3 ZK-EVM; it can still verify EVM code, it just uses some different internal logic to do it.

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, Type 1 or Type 2 ZK-EVMs may voluntarily become Type 3 ZK-EVMs by adding new ZK-SNARK-friendly precompiles that provide developers with features for low verification time and gas cost.

Type 4 (high-level language equivalent)

Type 4 ZK-EVM systems work by taking smart contract source code written in a high-level language (such as Solidity, Vyper, or an intermediate to which both compiles) and compiling it into some language explicitly designed to be ZK-SNARK friendly .

Advantage: very fast verification time

A lot of overhead can be avoided by not doing ZK proofs for all the different parts of each EVM execution step, and starting directly from higher level code.

I just described this advantage (compatibility-related disadvantage compared to a big bulleted list below) in one sentence in this post, but this should not be interpreted as a value judgment! Compiling directly from a high-level language does greatly reduce costs and help decentralization by making it easier to become a prover.

Disadvantage: more incompatibility

A “normal” application written in Vyper or Solidity can be compiled down and it “just works”, but there are important ways that many applications don’t “just work”:

  • The addresses of contracts in the Type 4 ZK-EVM 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 others.
  • Handwritten EVM bytecode is harder to use. Many applications use handwritten EVM bytecode for some parts to improve efficiency. Type 4 ZK-EVM 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 type 3 ZK-EVM.
  • Much of the debugging infrastructure cannot be inherited because such infrastructure runs on EVM bytecode. That said, this shortcoming can be mitigated by having more access to the debugging infrastructure from “traditional” high- or mid-level languages ​​such as LLVM.

Developers should be aware of these issues.

Who is building it?

ZKSync is a type 4 ZK-EVM system, although it may increase compatibility with EVM bytecode over time. Nethermind’s Warp project is building a compiler from Solidity to Starkware’s Cairo that will turn StarkNet into a de facto Type 4 ZK-EVM system.

The future of ZK-EVM types

Some types are not explicitly “better” or “worse” than others. Instead, they weigh differences in space: lower-numbered types are more compatible with existing infrastructure but slower, and higher-numbered types are less compatible with existing infrastructure but faster quick. In general, it’s healthy to explore all these types of spaces.

Additionally, ZK-EVM projects can easily start with higher-numbered types and jump to lower-numbered types over time (and vice versa). E.g:

ZK-EVM can start with type 3, deciding not to include some features that are particularly difficult to ZK proof. After that, they can add these features over time and move to Type 2.

ZK-EVM can start with type 2 and later become a hybrid type 2/type 1 ZK-EVM, by providing the possibility to operate in a full Ethereum compatible mode or to use the possibility to modify the state tree which can be proved faster. Scroll is considering going in this direction

By adding the ability to process EVM code, a system that starts with Type 4 may become Type 3 over time (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 could become a Type 1 ZK-EVM if Ethereum itself adopted its modifications to become more ZK friendly.

A Type 1 or Type 2 ZK-EVM can become a Type 3 ZK-EVM by adding precompiles to verify code in a ZK-SNARK friendly language. This will allow developers to choose between Ethereum compatibility and speed. This would be type 3 because it breaks perfect EVM equivalence, but for practical purposes and purposes it would have a lot of the benefits of type 1 and 2. The main disadvantage 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 contains an equivalent implementation of the precompiled EVM code.

Personally, I hope that over time, through a combination of improvements to ZK-EVM and improvements to Ethereum itself, to make it more ZK-SNARK friendly, everything will become type 1. In such a future, we will have multiple ZK-EVM implementations that can be used both for ZK Rollup and for validating the Ethereum chain itself. In theory, Ethereum does not need to standardize on a single ZK-EVM implementation for L1; different clients can use different proofs, so we continue to benefit from code redundancy.

However, it will take quite a while to realize such a future. At the same time, we will see many innovations in the different paths of scaling Ethereum and Ethereum-based ZK-rollups.

Posted by:CoinYuppie,Reprinted with attribution to:
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.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-08-04 10:44
Next 2022-08-04 10:45

Related articles