Detailed explanation of the five types of ZK-EVM: architecture, advantages and disadvantages, and solutions.

Original author: cookies

Original translation: Deep Tide TechFlow

This article discusses in detail the five types of ZK-EVM, each with its own unique architecture, advantages, disadvantages, and possible solutions.

In addition, the article provides examples of actual projects to help readers better understand the performance of these types in practical applications. Whether you are a blockchain developer or a reader interested in blockchain technology, this article will provide you with in-depth and concise insights.

Let's explore the types of ZK-EVM and their pros and cons.

1. Type 1: Fully identical to Ethereum;

2. Type 2: Fully identical to EVM;

3. Type 2.5: Partially identical to EVM;

4. Type 3: Almost identical to EVM;

5. Type 4: Advanced languages are identical.

Type 1: Fully identical to Ethereum

Architecture: Identical to Ethereum without changing any part of the Ethereum system.

Advantages

Perfect compatibility:

• Ability to verify Ethereum blocks;

• Helps make Ethereum L1 more scalable;

• Suitable for Rollups as they can reuse a lot of infrastructure.

Disadvantages

Perfect compatibility:

• Ethereum was not originally designed for ZK functionality;

• Many components of Ethereum require a considerable amount of computation to generate ZK proofs (ZKPs);

• Proofs for Ethereum blocks take many hours to generate.

Solution to the problem:

• Massively parallelizing provers;

• ZK-SNARK ASIC.

Type 2: Fully Equivalent to EVM

Architecture:

• The data structure (block structure and state tree) is significantly different from Ethereum;

• Fully compatible with existing applications;

• Minor modifications to Ethereum for easier development and faster generation of proofs.

Advantages

• Provides faster proof times than Type 1;

• The data structure is not directly accessed by EVM;

• Applications running on Ethereum are highly likely to run on Type 2;

• Supports existing EVM debugging tools and other development infrastructure.

Disadvantages

Before understanding the disadvantages, let's understand what "Keccak" is:

• The hash algorithm of the Ethereum blockchain;

• Used to secure data on Ethereum;

• Ensures that information is transformed into hashes.

Type 2 is incompatible with applications that verify historical blocks using Merkle proofs for transactions, receipts, or state. This is because if the hash algorithm changes (no longer Keccak), the proofs will become invalid.

We can think of Keccak as a language that uses Merkle proofs (letters). If ZK-EVM replaces Keccak with another hash algorithm (such as Poseidon), the Merkle proofs will become unfamiliar and applications will not be able to read and verify their claims.

Potential solution for the disadvantages: Ethereum can add a future-scalable historical access precompilation.

Projects

• Scroll;

• Polygon Hermez.

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

Type 2.5: Partially Equivalent to EVM

Architecture:

Increase the gas cost for specific EVM operations that are difficult to prove with ZK;

• Precompiles;

• Keccak opcodes;

• Call contract patterns;

• Memory access;

• Storage.

Advantages

• Significantly improve proof time in worst-case scenarios;

• Provide deeper and safer changes compared to EVM stack.

Disadvantages

• Lower compatibility with development tools;

• Some applications may not work.

Type 3: Almost Equivalent to EVM

Architecture:

• In ZK-EVM implementation, some exceptionally difficult features, usually precompiles, are removed;

• There are slight differences in how ZK-EVM handles contract code, memory, or stack.

Advantages

• Reduces verification time;

• Makes EVM development easier;

• Aims to require minimal rewriting for less compatible applications.

Disadvantages

• More incompatibility;<

  Architecture:

  • Smart contract code written in high-level languages (such as Solidity, Vyper) is accepted;

  • Compiled into a language designed for ZK-SNARK compatibility.

  Advantages

  • Very fast proof time;

  • Reduced costs (cost, time, and computational workload);

  • Reduced barriers to being a prover: increased decentralization.

  Disadvantages

  • In type 4 systems, the address of the contract may differ from the address in the EVM, as the address depends on the exact bytecode;

  • This means that if the type 4 ZK-EVM doesn't have bytecode, they won't be able to create addresses;

  • In the above case, type 4 will be incompatible with applications that depend on the factually incorrect contract;

  • Many debugging infrastructures cannot be ported as they run on EVM bytecode.

  

  Projects

  • zkSync

  Finally, we can put the above types together to make a comparison, help everyone understand the different zkEVMs at a glance.