Author: cookies

Compiled by: TechFlow

Do you really understand ZK-EVM?

This article provides a detailed exploration of the five types of ZK-EVM, each with its unique architecture, advantages and disadvantages, as well as potential solutions.

Additionally, the article includes real-world project examples to help readers better understand how these types perform in practical applications. Whether you are a blockchain developer or simply interested in blockchain technology, this article will offer you insightful and concise perspectives.

Let’s dive into the types of ZK-EVM, along with their pros and cons.

1. Type 1: Fully equivalent to Ethereum;

2. Type 2: Fully equivalent to EVM;

3. Type 2.5: Partially equivalent to EVM;

4. Type 3: Nearly equivalent to EVM;

5. Type 4: High-level language equivalence.

Type 1 | Fully Equivalent to Ethereum

Architecture: Exactly the same as Ethereum, without changing any part of the Ethereum system.

Type 1 | Advantages

Perfect compatibility:

· Capable of verifying Ethereum blocks;

· Helps improve Ethereum L1 scalability;

· Suitable for Rollups, as they can reuse significant existing infrastructure.

Type 1 | Disadvantages

Perfect compatibility:

· Ethereum was not originally designed with ZK-friendliness in mind;

· Many components of Ethereum require substantial computation to generate ZK proofs (ZKP);

· Generating a ZK proof for an Ethereum block may take many hours.

Potential Solutions:

· Large-scale parallelization of provers;

· ZK-SNARK ASICs.

Type 2 | Fully Equivalent to EVM

Architecture:

· Data structures (block structure and state trees) differ significantly from Ethereum;

· Fully compatible with existing applications;

· Makes minor modifications to Ethereum to facilitate easier development and faster proof generation.

Type 2 | Advantages

· Faster proof times compared to Type 1;

· Data structures are not directly accessed by the EVM;

· Applications running on Ethereum are likely to run on Type 2;

· Supports existing EVM debugging tools and other development infrastructure.

Type 2 | Disadvantages

Before understanding the drawbacks, let's first clarify what "Keccak" is:

· The hash algorithm used by the Ethereum blockchain;

· Used to secure data on Ethereum;

· Ensures information is transformed into hashes.

Type 2 is incompatible with applications that use Merkle proofs to verify historical transactions, receipts, or states, because such proofs become invalid if the hash algorithm changes (i.e., no longer uses Keccak).

We can think of Keccak as a language—Merkle proofs being the "letters." If a ZK-EVM replaces Keccak with another hash function (e.g., Poseidon), the Merkle proofs become unintelligible, and applications can no longer read or validate them.

Potential Solution: Ethereum could add future scalable precompiles for historical data access.

Projects under Type 2

· Scroll;

· Polygon Hermez.

However, these projects have not yet implemented more complex precompiles, so they can be considered incomplete Type 2 implementations.

Type 2.5 | Partially Equivalent to EVM

Architecture:

· Increases gas costs for specific EVM operations that are difficult to prove under ZK;

· Precompiles;

· Keccak opcodes;

· Contract calling patterns;

· Memory access;

· Storage.

Type 2.5 | Advantages

· Significantly improves worst-case proof time;

· Safer than making deeper structural changes to the EVM stack.

Type 2.5 | Disadvantages

· Reduced compatibility with development tools;

· Some applications will no longer function.

Type 3 | Nearly Equivalent to EVM

Architecture:

· Removes certain features that are exceptionally hard to implement in ZK-EVMs, typically precompiles;

· Minor differences in handling contract code, memory, or stack within the ZK-EVM implementation.

Type 3 | Advantages

· Shorter verification time;

· Easier to develop for EVM;

· Aims to require minimal rewriting for less-compatible applications.

Type 3 | Disadvantages

· More incompatibilities;

· Applications relying on removed precompiles in Type 3 must be rewritten.

Type 3 | Projects

Currently, Scroll and Polygon are considered Type 3. However, ZK-EVM teams should not be satisfied with staying at Type 3—this type serves as a transitional phase where ZK-EVMs add precompiles to improve compatibility and progress toward Type 2.5.

Type 4 | High-Level Language Equivalence

Architecture:

· Accepts smart contract code written in high-level languages such as Solidity or Vyper;

· Compiles it into a language specifically designed to be ZK-SNARK friendly.

Type 4 | Advantages

· Very fast proof generation;

· Lower overhead (cost, time, and computational effort);

· Lowers the barrier to becoming a prover: enhances decentralization.

Type 4 | Disadvantages

· In Type 4 systems, contract addresses may differ from those in the EVM, as addresses depend on exact bytecode;

· This means that if a Type 4 ZK-EVM lacks bytecode, it cannot recreate the address;

· In such cases, Type 4 becomes incompatible with applications relying on counterfactual contract deployment;

· Much of the debugging infrastructure cannot be ported, as it operates on EVM bytecode.

Type 4 | Projects

· zkSync

Finally, we can summarize and compare the above types to provide a clear understanding of different ZK-EVMs.