Original author -Lisa Akselrod

Compile - Odaily 0xAyA

Editors note: The author compiled it based on the ZK-EVM introduction article written by Vitalik before, and introduced in detail the various types of ZK-EVM and the differences between them.

About a year ago, a group of ZK-EVMs announced their upcoming testnet launch. These moves have piqued the curiosity of the Ethereum community and sparked discussion about the nuances behind terms like Ethereum equivalence and EVM equivalence.

To clarify, Vitalik wrote an important article entitledDifferent Types of ZK-EVMs, classify various ZK-EVMs into four types and explain their differences.

The core idea is: Type 1 (e.g. Taiko) is fully equivalent to Ethereum, while Type 4 (e.g. zkSync) excels at efficient proof generation. All other types, Type 2, Type 2.5 and Type 3, are in between (e.g. Polygon zkEVM, Scroll, Linea).

Most ZK-EVMs are initially Type 2.5 and Type 3, with some intentions revealed toward moving toward Type 1 or Type 2, although these projects have not provided specific timelines or commitments for this.

This article focuses on the differences between Type 1 and Type 2/Type 2.5 and describes the possible consequences of breaking Ethereum equivalence. Well also briefly touch on other types.

The main goal of ZK-EVM is to scale Ethereum, i.e. increase Ethereum’s throughput while retaining its other features (security, developer experience, etc.). Ideally, ZK-EVM should be able to:

• Proven execution of unmodified native bytecode (covering 100% of Ethereum opcodes) according to the Ethereum Virtual Machine specification in the Yellow Book.

• Generate proofs quickly and cheaply.

• Allows 100% reuse of tools and infrastructure developed for Ethereum.

• Allows any Ethereum dApp to be redeployed on ZK-EVM “as-is” (“as-is” means no changes required, no compromises).

Differences between ZK-EVM types

In the ZK-EVM space, the differences come primarily from the level of Ethereum/EVM equivalence, the impact of ZK-unfriendly elements on proof generation cost and speed, and the complexity of the circuit implementation (such as VM construction or state trees).

Lets analyze these differences, specifically distinguishing Type 1 from Type 2/Type 2.5. Well also touch on the use cases most relevant to each type.

When comparing various types, the following chart is often used:

For those who are not working full-time in the ZK-EVM field, this table may seem confusing, so let’s translate these terms into layman’s terms and take a look:

This diagram gives a clearer picture of what each type actually looks like, but it can still be a bit obscure, so let’s fully explore the world of ZK-EVM by explaining each type individually.

Type 1: Equivalent to Ethereum

Vitalik Buterin：

“Type 1 ZK-EVM is what we ultimately need to make Ethereum Layer 1 itself more scalable.”

Type 1 means not changing any part of the Ethereum system to make it easier to generate proofs. No changes to Ethereum means no compromise on security, as most cryptographic primitives (e.g. hash functions), developer infrastructure (e.g. debuggers) or chain infrastructure (e.g. execution clients) are already 9 years of field testing.

Type 1 ZK-EVM does not replace anything: hashes, state trees, transaction trees, precompilation, or any other consensus logic, everything is exactly the same as mainnet’s EVM.

• Type 1 is the only type that can verify the Ethereum chain itself - from entire blocks to transaction execution, smart contracts and account logic.

Type 2: Equivalent to EVM

Type 2 makes proof generation faster and circuit development easier by removing some parts that are not conducive to ZK. However, due to the consequences of this, it may make the development of other parts of ZK-rollup (such as the node software) more complex. These complexities may be caused by incompatibilities between established best practices and testing tools and the changes being implemented (such as an altered state tree).

Note: Equivalent to Ethereum and equivalent to EVM are not the same. While equivalence to Ethereum means that no part of Ethereum has been changed, i.e. fully compatible with all Ethereum dApps, equivalence to EVM allows for changes to data structures (such as block structures or state trees).

While these adjustments may seem minor, they impact Ethereum’s compatibility. Changing data structures may cause Ethereum dApps to be incompatible with Type 2 ZK-EVM, especially when validating Merkle proofs about past transactions, receipts, or states (e.g., cross-chain bridges).

Remove ZK unfriendly elements

The modifications to Ethereum are intended to simplify development and increase the speed of proof generation. The goal is to prune the parts of Ethereum that rely on unfriendly zero-knowledge cryptography. In more technical terms, parts that require a large number of gates (addition and multiplication operations) due to non-local domains (such as hash functions); a large number of multi-scalar multiplications and/or fast Fourier transforms (FFT); or Just the part that requires a lot of manipulation.

Specific examples of unfriendly zero-knowledge elements that Type 2 ZK-EVM may modify:

• Hash functions: While Ethereum uses the Keccak hash function, many ZK-EVMs use the Poseidon hash function, which requires significantly fewer gates. For example, lets estimate how many hash functions of each type can be calculated per second (i.e. a comparison that demonstrates the speed of generation).

Poseidon hash functions have significant speed advantages in proof generation.

However, it is important to note that newer cryptographic primitives are not as popular relative to established cryptographic primitives that are widely recognized by the community. While Poseidon may offer speed, Keccaks battle-tested properties make it more robust and secure as it becomes more widely adopted.

This is why Keccak, despite being older and adopted by a wider community (in other industries, such as security systems or sensors in smart devices), can be considered more tried and tested than Poseidon, which is after all within the ZK community New hash functions to create and use.

• State trees for data storage: for example, while Ethereum usesMerkle Patricia tree(using Keccak hashes), but some Type 2 ZK-EVM optionsSparse Merkle tree(Using Poseidon hashing). Changing the state tree may cause some incompatibilities. For example, Ethereums Merkle trees have different node types and use RLP to encode data, which is a difficult thing to do in ZK.

• Block Structure: Blocks contain a large amount of information. However, when exploring L2, we only care about the execution_payload_header (i.e. the block hash). In the image below, there is the structure (block hash) of all the data contained in execution_payload_header.

Please note: changing any of these components will break Ethereum equivalence.

Type 2.5: Equivalent to EVM, considering gas cost

Type 2.5 ZK-EVM increases the gas cost of certain operations that are difficult to prove using ZK technology in EVM.

Given Ethereums gas limit per block (30 M gas), increasing the gas cost per opcode results in fewer opcodes per block. Therefore, less complex opcodes can be included in a block. Simpler opcodes allow circuits to be smaller and proofs to be generated faster.

• Gas is a unit of measure for work.

• Opcode prices are calculated in gas.

• Opcodes specify operations within machine language instructions.

• A program is a static list of opcodes. Program execution is an execution trace.

• An execution trace is a specific ordered list of opcodes executed by a program.

Parts that are difficult to prove ZK include:

• Keccak opcodes and some other opcodes that depend on Keccak.

• Precompiled: Functions accessible to the EVM. Some of them provide complex or mathematically complex tasks, such as cryptographic functions (such as blake 2 f or sha 256). They do not execute within the EVM, but rather as functions hard-coded in the execution client and exposed to the EVM using CALLs to special addresses.

• Memory access: e.g., increasing memory slot size (e.g., Ethereum usesByte alignmentof memory, while Polygon zkEVM uses 32-byte memory slots). To make this change possible, the internal logic of certain opcodes (such as MLOAD) had to be changed.

• Storage (i.e. changing the hash function or state tree as described above).

Changing gas costs may reduce the compatibility of developer tools and break some dApps. For example, a smart contract that frequently executes opcodes with increasing gas costs may exceed the block gas limit and fail to execute.

Type 3: Almost equivalent to EVM

Type 3 ZK-EVM omits precompilation not applicable to ZK and may adjust memory and storage access.

dApps that relied on removed precompiled apps will need to be rewritten. In unusual cases, differences in how the Type 3 ZK-EVM and the original EVM handle edge cases may require adjustments to the dApp.

Type 4 (equivalent to high-level language)

Type 4 is already far away from EVM.

Smart contract source code written in a high-level language (e.g., Solidity, Zinc) is compiled into an intermediate representation, generating opcodes suitable for a ZK-friendly virtual machine.

• This approach avoids generating ZK proofs for each EVM execution step, thereby greatly reducing the proof effort.

• Even if the contract can be compiled, if the dApp uses EVM hand-written bytecode, further work is required.

• Type 4 ZK-EVM also requires its own developer tools (opcode level only) such as debuggers and tracers.

In ZK circuits that prove execution trajectories, each step implements the constraint, and the cost of each step is the sum of all opcodes. Therefore, Type 4 ZK-EVM is designed to use as few complex opcodes as possible to optimize efficiency.

It’s worth mentioning that custom opcodes (opcodes not covered in Ethereum) make it possible to pass new features that are not possible on Ethereum by default. For example, make multiple calls for execution via the account abstraction feature, or launch a smart contract wallet using an out-of-the-box solution like Argent.

Summarize

Different ZK-EVM types prioritize different goals and characteristics. Type 1 focuses on Ethereum equivalence, while Type 4 prioritizes efficient proof generation. Other types fall in between these extremes, and many Type 2 and 3 ZK-EVM protocols have announced their intention to move to Ethereum equivalents.

These four types of classification may not be the final state of the ZK rollup and may be subject to further modifications in the future. For example, some ZK-EVMs may become hybrid, Type 1/2 may develop Type 4 solutions (with the highest possible efficiency) and provide dApps with both options, while Type 3 and 4 ZK-EVMs may add Ethereum equivalent option.