Explain the five types of ZK-EVM in detail: architecture, advantages and disadvantages and solutions

Original Author: s

Compilation of the original text: Deep Tide TechFlow

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

In addition, the article also lists some practical project examples so that readers can 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-EVMs, their pros and cons.

1. Type 1: completely equivalent to Ethereum;

2. Type 2: completely equivalent to EVM;

3. Type 2.5: Partially equivalent to EVM;

4. Type 3: almost equivalent to EVM;

5. Type 4: where the high-level language is equivalent.

Type 1: fully equivalent to Ethereum

Architecture: It is exactly the same as Ethereum and does not change any part of the Ethereum system.

advantage

Perfect Compatibility:

• Ability to verify Ethereum blocks;
• Help make Ethereum L1 more scalable;
• Suitable for Rollups as they can reuse a lot of infrastructure.

shortcoming

Perfect Compatibility:

• Ethereum was not originally designed for ZK functionality;
• Many components of Ethereum require a lot of computation to generate ZK proofs (ZKP);
• Proofs for Ethereum blocks take many hours to generate.

Solution to problem:

• Large-scale parallelization prover;
• 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 proof generation.

advantage

• Provides faster proof times than Type 1;
• The data structure is not directly accessed by the EVM;
• Applications running on Ethereum: likely to run on Type 2;
• Support for existing EVM debugging tools and other development infrastructure.

shortcoming

Before understanding the disadvantages, first understand what is "Keccak":

• The hashing algorithm of the Ethereum blockchain;
• Used to protect data on Ethereum;
• Make sure the message is converted to a hash.

Type 2 is not compatible with applications that verify Merkle proofs of historical blocks to verify information about historical transactions, receipts/states. This is because if the hashing algorithm changes (no longer Keccak), the proof will become invalid.

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

Potential solution to shortcomings: Ethereum could add future scalable history access precompilation.

project

• Scroll;
• Polygon Hermez.

However, these projects have not yet implemented more sophisticated precompilation, therefore, they can be considered incomplete Type 2 .

Type 2.5: Partially equivalent to EVM

Architecture:

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

• Precompiled;
• Keccak opcode;
• The mode of calling the contract;
• Access memory;
• storage.

advantage

• Significantly improved worst-case proof time;
• Safer than making deeper changes to the EVM stack.

shortcoming

• The compatibility of development tools is reduced;
• Some apps will not work.

Type 3: Almost equivalent to EVM

Architecture:

• In the ZK-EVM implementation, some functions that are extremely difficult to implement are deleted, usually precompiled;
• ZK-EVM has slight differences in how it handles contract code, memory or stack.

advantage

• shorten the verification time;
• Make EVM easier to develop;
• The goal is to require minimal rewrites for less compatible applications.

shortcoming

• More incompatibilities;
• Applications that use precompilation that were removed in Type 3 will need to be rewritten.

project

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

Type 4: high-level language equivalent

Architecture:

• Accept smart contract code written in high-level languages (such as Solidity, Vyper);
• Compiled to a language designed to be ZK-SNARK friendly.

advantage

• Very fast proof time;
• Reduced overhead (cost, time and computational effort);
• Lower the barrier to becoming a prover: increase the degree of decentralization.

shortcoming

• In a type 4 system, the address of the contract may be different from the address in the EVM, because the address depends on the exact bytecode;
• This means that if type 4 ZK-EVMs don't have bytecodes, they won't be able to create addresses;
• Type 4 will be incompatible with applications relying on counterfactual contracts in the above cases;
• Many debugging infrastructures are not portable because they run on EVM bytecode.

project

• zkSync

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