ZK-EVM types: Ethereum-equivalent, EVM-equivalent, Type 1, Type 4, and other cryptic buzzwords

September 28th, 2023

TL;DR

A year ago, quite a few ZK-EVMs announced the upcoming launch of testnets. The community wondered what the difference between all these projects was and what Ethereum-equivalence, EVM-equivalence, and other popped-up buzzwords meant. To bring clarity, Vitalik wrote an article, “The different types of ZK-EVMs,” providing a taxonomy for different types of ZK-EVMs and explaining the difference.

The core idea is: Type 1 (e.g., Taiko) is perfectly Ethereum-equivalent, and Type 4 (e.g., zkSync) generates proofs most efficiently. All other types (Type 2, Type 2.5, Type 3) are somewhere in between these two edge cases.

Most ZK-EVMs started as Type 3 or Type 2.5, broadcasting some intentions of moving towards Type 1 or at least Type 2 without providing any specific timing or commitments.

In this article, we will focus on the details of the difference between Type 1 and Type 2/2.5, explaining the tangible difference and possible consequences of breaking Ethereum-equivalence. We will briefly cover other types as well. However, this is beyond the scope of this article.

Disclaimer: in this article, we provide quite a few definitions to ensure that the explanation is available to everyone. Feel free to skip the definitions if you are a pro. 😎

However, if you’re unfamiliar with what ZK-EVM is, it’s better to check this detailed series of articles by PSE before reading this article or this short explainer “Proof of Meow: how ZK-VM works.”

The main goal of ZK-EVM is scaling Ethereum. That is, increasing Ethereum throughput while preserving all other properties (security, developer experience, etc.) as is. In a perfect scenario, to emulate Ethereum, ZK-EVM:

Proves the execution of unaltered, native bytecode in accordance with the Ethereum VM specification as specified in the yellow paper (i.e., covers 100% of Ethereum opcodes);
Quickly generates proofs at a low cost;
Allows re-use of 100% of tooling and infrastructure developed for Ethereum;
Allows re-deployment of any Ethereum dapp “as is” on ZK-EVM (”as is” means uncompromisingly and with no changes needed).

How Type 1/2/2.5/3/4 ZK-EVMs differ from each other

TL;DR

Types of ZK-EVMs differ by the Ethereum/EVM-equivalence level and amount of zk-unfriendly elements (that affect proof generation cost and speed), and simplicity of the implementation of the circuits (e.g., VM building or state trees). Below we explore the difference between different types, specifically focusing on distinguishing between Type 1 and Type 2/2.5. We also cover the use cases that are the most relevant for specific types.

Usually, when trying to compare different types in a talk or presentation, a diagram similar to the below is used:

This table might look a bit cryptic for those who don’t work on ZK-EVMs 24/7. To make it clearer, and introduce the difference between different types to the wider community, let’s take a closer look at what this difference means for developers and users in plain English:

It feels better but is still cryptic. Further in this article, we explain each difference in technical characteristics and each consequence of these technical issues.

Let’s connect the dots and fill the gaps in the ZK-EVM plane right now!

Type 1 – Ethereum-equivalent

“Type 1 ZK-EVMs are what we ultimately need make the Ethereum layer 1 itself more scalable” – Vitalik.

Type 1 means no changes to any part of the Ethereum system to make it easier to generate proofs. No changes to Ethereum means uncompromising security, as most cryptographic primitives (e.g., hash functions), developer infrastructure (e.g., debugger), or chain infrastructure (e.g., execution clients) have been battle-tested for over 9 years:

A Type 1 ZK-EVM doesn’t replace anything: hashes, state trees, transaction trees, precompiles, or any other in-consensus logic. Everything is exactly as it is in EVM.

Type 1 is the only type that works to verify the Ethereum chain itself (the whole blocks as they are today or the execution side only (i.e., transaction execution, smart contract, and account logic).
Another approach that has recently be shown to be a viable is to run existing Ethereum implementations (like revm, geth, or even the Ethereum executable spec itself) inside a zkVM. The big benefit of this approach is that no circuits are required accept the very general zkVM circuit itself, though in practice additional circuits are still used to speed up the hard to prove parts (so still more limited in scope). The downside is that running Ethereum inside a zkVM instead of a specialized zkEVM occurs significant overheads, but with provers getting faster and faster this may be a tradeoff that's well worth it.

Type 2 – EVM-equivalent

Type 2 removes some ZK-unfriendly parts to make proof generation faster and circuit development easier. However, as a consequence of the latter, it might make the development of other parts of the ZK-rollup (e.g., node software) more complicated; as this might depend on well-known good practices and testing tools that might be incompatible with the implemented changes (e.g., changed state tree).

Disclaimer: Ethereum-equivalent and EVM-equivalent are not the same. While Ethereum-equivalent means no Ethereum parts were changed, that is, perfect compatibility with all Ethereum dapps, EVM-equivalent allows changing data structures (e.g., block structure or state tree).

Even though these changes might look tiny, they affect Ethereum-compatibility: changing data structures, Ethereum apps will be incompatible with a Type 2 ZK-EVM if the dapp needs to verify Merkle proofs of historical Ethereum blocks to verify claims about historical transactions, receipts, or state (e.g., bridges sometimes do this).

Removing ZK-unfriendly parts

The modifications to Ethereum are done to make development easier and proof generation faster. The goal is to remove parts of the Ethereum stack that rely on ZK-unfriendly cryptography. By ZK-unfriendly, we mean those requiring a lot of gates (addition and multiplication operations) because of the usage of non-native fields (e.g., hash functions), a large amount of multi-scalar multiplications and/or FFTs, or just a large number of required operations.

Let’s look at specific examples of ZK-unfriendly elements that a Type 2 ZK-EVM might change

Hash function: while Ethereum uses the Keccak hash function, many ZK-EVMs use the Poseidon hash function, which requires a significantly smaller number of gates.
To provide an illustration, let’s estimate how many hash functions of each type can be calculated per second (i.e., proof generation speed comparison).

The Poseidon hash function has a significant advantage in proof generation speed.

However, (i) newer cryptography primitives are less preferred than older and (ii) those battle-tested by a wide community in different industries are more preferred than cryptography primitives used by a narrow community. That is why, Keccak, being older and a standard adopted by a wider community (not only in blockchain but also in other industries, for example, for sensors in security systems or smart devices), can be considered more battle-tested and as a consequence, more robust and secure than Poseidon, a new hash function created and used within the ZK community.

State tree for data storage: for example, while Ethereum uses Merkle Patricia Trees (Keccak hash function with lots of complex encoding requirements), Polygon zkEVM uses Sparse Merkle Tree (using Poseidon hash). Changing the state tree might result in some incompatibilities, as described in this section's beginning. For example, the Ethereum Merkle tree has different node types and encodes the data using RLP which is a pretty crazy thing to do in ZK.
Block structure Blocks contain a lot of information. However, exploring L2s, we care only about execution_payload_header (i.e., block hash).

Even changing only one of the components mentioned above breaks Ethereum equivalence.

Type 2.5 ZK-EVM (EVM-equivalent, except for gas costs)

A Type 2.5 ZK-EVM increases the gas cost of specific operations in the EVM that are difficult to ZK-prove.

While Ethereum has a limit for gas per block (30M gas), increasing gas cost per opcode allows fewer opcodes per block. As a result, less complex opcodes can be included in one block. Less complex opcodes make their circuit smaller, and the proof is generated faster.

Gas is a measure of work.
Opcodes are priced in gas.
Opcode is the portion of a machine language instruction that specifies the operation to be performed.
A program is a static list of opcodes. Program execution is execution trace.
Execution trace is a specific ordered list of opcodes executed specifically for a specific program execution.

Parts that are hard to ZK-prove:

Keccak opcode and some other opcodes depending on Keccak.
Precompiles – functions that are exposed to the EVM. Some provide complex or mathematically sophisticated tasks such as cryptographic functions (e.g., blake2f or sha256). They are not executed inside the EVM. Instead, they are functions hard-coded in execution clients and are exposed to the EVM using a CALL to a special address.
Accessing memory: for example, increased memory slot size (e.g., while Ethereum uses byte aligned memory, Polygon zkEVM uses 32 byte mrmoty slots). To make this change possible, the internal logic of some opcodes (e.g., MLOAD) must be changed.
Storage (i.e., changing hash function or state tree as mentioned above).

Changing gas costs may reduce developer tooling compatibility and break some applications. For example, if there is a smart contract that requires executing an opcode with increased gas cost a specific amount of times, that will exceed the block gas limit.

Type 3 (almost EVM-equivalent)

Remove precompiles that are hard to ZK-prove and perhaps some changes in accessing memory, storage, or reverting.

Dapps that use the removed precompiles need to be rewritten. The difference in how Type 3 ZK-EVM and original EVM treat the edge cases (i.e., under uncommon circumstances) might lead to dapps rewriting as well.

Type 4 (high-level-language equivalent)

The smart contract source code written in a high-level language (ex., Solidity, Zinc, etc.) is compiled into Intermediate Representation and generates opcodes for the ZK-friendly VM. This allows us to avoid generating ZK-proofs for all the different parts of each EVM execution step, substantially decreasing prover work.

Type 4 is already pretty far from EVM.

Even though the contracts can be compiled, further work is needed if the dapps use EVM handwritten bytecode.

Type 4 ZK-EVMs also need their own developer tools (only those that work on the opcode level), such as debuggers and tracers.

In the ZK circuit that proves the execution trace, all the constraints are implemented for each step, so the cost of each step is the sum of all opcodes. That is why Type 4 ZK-EVMs try to use as few complex opcodes as possible to optimize efficiency.

Custom opcodes (i.e., those not covered by Ethereum) also allow the implementation of new features not available on Ethereum by default. For example, multiple call execution for Account Abstraction features or initiating smart-contract wallets using out-of-the-box solutions like (e.g., Argent).

Conclusion

Different Types of ZK-EVMs focus on different goals and prioritize different characteristics (Type 1 – Ethereum-equivalence while Type 4 – efficient proof generation), while other Types stay in between these two edge cases, declaring their intentions to move towards Ethereum-equivalence in the future.

It might be the case, that the four-type taxonomy is not the endgame for ZK-Rollups, and further modifications can occur in the future. Taiko doesn’t claim to stay Type 1 forever. But it does claim to be uncompromisingly and ultimately Ethereum-aligned. That is, whatever specs or new roadmap objectives are introduced by Ethereum, Taiko will support it along the way.