In-depth 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 unique architecture, advantages, disadvantages, and possible solutions. In addition, the article lists some practical project examples to help readers better understand the performance of these types in actual 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: Identical to Ethereum;

• Opportunities and Reflections on the Future of Ethereum Block Space
• Arkham was snapshot on July 8th and ARKM airdrop rewards will be distributed on July 18th.
• Divine Fish: Three things worth paying attention to in the second half of 2023

2. Type 2: Identical to EVM;

3. Type 2.5: Partially identical to EVM;

4. Type 3: Almost identical to EVM;

5. Type 4: Advanced language identical.

Type 1: Identical to Ethereum

Architecture: Completely identical to Ethereum and does not change any part of the Ethereum system.

Advantages

Perfect compatibility:

• Can 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 initially designed for ZK functions;

• Many components of Ethereum require a lot of computation to generate ZK proofs (ZKP);

• Proofs for Ethereum blocks take many hours to generate.

Problem solutions:

• Massively parallelize provers;

• ZK-SNARK ASIC.

Type 2: Identical to EVM

Architecture:

• Data structures (block structure and state tree) are significantly different from Ethereum;

• Fully compatible with existing applications;

• Minor modifications have been made to Ethereum to make it easier to develop and generate proofs faster.

Advantages

• Provides faster proof time than Type 1;

• Data structures are not directly accessed by the EVM;

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

• Supports existing EVM debugging tools and other development infrastructure.

Disadvantages

Before discussing the disadvantages, let’s understand what “Keccak” is:

• The hash algorithm of the Ethereum blockchain;

• Used to protect data on Ethereum;

• Ensures that information is transformed into a hash.

Type 2 is incompatible with Merkle proofs that verify application history transactions, receipts/status. 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 statements.

Potential solutions to the disadvantages: Ethereum can add future scalable historical access precompiles.

Projects

• Scroll;

• Polygon Hermez.

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

Type 2.5: Partially Equivalent to EVM

Architecture:

Increases the gas cost of specific EVM operations that are difficult to ZK-proof;

• Precompile;

• Keccak opcode;

• Call contract pattern;

• Access memory;

• Storage.

Advantages

• Significantly improves worst-case proof time;

• It is safer to make deeper changes than to compare EVM stacks.

Disadvantages

• Reduced compatibility with development tools;

• Some applications will not work.

Type 3: Almost equivalent to EVM

Architecture:

• In the ZK-EVM implementation, some difficult-to-implement features, usually precompilation, are removed;

• ZK-EVM has slight differences in handling contract code, memory, or stack.

Advantages

• Shortened verification time;

• Makes EVM easier to develop;

• The goal is to require minimal rewriting of incompatible applications.

Disadvantages

• More incompatibility;

• Applications using precompilation that are deleted in Type 3 will need to be rewritten.

Projects

Currently, Scroll and Polygon are considered Type 3, however, the ZK-EVM team should not be satisfied with being Type 3, as Type 3 is a transitional stage where ZK-EVM adds precompilation to improve compatibility and transitions to Type 2.5.

Type 4: Equivalent to high-level languages

Architecture:

• Accept smart contract code written in high-level languages (such as Solidity, Vyper);

• Compile into a language designed to be ZK-SNARK friendly.

Advantages

• Very fast proof time;

• Reduces cost (cost, time, and computational work);

• Reduces the threshold for becoming a prover: increases decentralization.

Disadvantages

• In Type 4 systems, the address of a contract may be different from the address in EVM because the address depends on the exact bytecode;

• This means that if the Type 4 ZK-EVM has no bytecode, they will not be able to create addresses;

• In the above case, Type 4 will be incompatible with applications that depend on counterfactual contracts;

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

Project

• zkSync

Finally, we can put the above types together to make a comparison, which helps everyone to easily understand the different zkEVMs.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.