Recently the market is rumored about ZK technology trend, this is a technology that is widely applied on Layer2 such as Zksync, Starknet, Aztec, Taiko,… And almost Layer2 is developing its own zkEVM. So what is the difference between these zkEVM platforms? Let’s find out in this article!
This article was written by Vitalik Buterin and I just summarized it for everyone to read. If you want to read the original article, you can refer to it here.
Overview of zkEVM
zkEVM is an Ethereum virtual machine (EVM – Ethereum Virtual Machine) placed on platforms using Zkrollup technology. ZK technology has many applications to develop ideas that protect user privacy. However, this technology is very difficult to develop.
Like Ethereum-compatible platforms such as BNB Chain, Polygon, Avax C-chain, Fantom,… zkEVM helps developers using the Solidity language on Ethereum to easily develop dApps on ZK platforms without need to edit or edit a little Code.
More or less fine-tuning depends on whether the zkEVM platform is compatible with Ethereum or not. And based on this compatibility, Vitalik has divided zkEVM into 5 types. So how are those different types of zkEVM? Please continue reading the next part!
ZK-EVM Types
Type 1 (equivalent to Ethereum)
zkEVM type 1 is completely equivalent to Ethereum. It do not change any part of the Ethereum system to make it easier to create proofs. They do not replace hashes, state, transaction fees, or any other non-consensus logic.
Advantages: Perfect compatibility
The goal is to be able to verify Ethereum blocks as they are, or at least verify implementation layer side (so, does not include beacon chain consensus logic, but includes all transaction execution, smart contracts, and account logic).
zkEVM type 1 is to make Layer1 Ethereum itself more scalable than other types of zkEVM. In the long run, modifications to experimental Ethereum in zkEVM type 2 or type 3 could be introduced into Ethereum easily, but such refactoring comes with its own complexities.
Type 1 zkEVMs are also ideal for rollups, as they allow rollups to reuse most of Ethereum’s infrastructure. For example, applications operating on Ethereum can be used as-is to create and process blocks and can be reused. tools like block explorer, block producer,…
Disadvantage: Time proven
Ethereum wasn’t originally designed with ZK friendliness in mind, so there’s that much part of the Ethereum protocol that requires a large amount of computation to prove a ZK proof. Type 1 aims to exactly replicate Ethereum, so it has no way of mitigating these inefficiencies. Currently, proof of Ethereum blocks take many hours to create. This can be mitigated by clever techniques for parallel synchronization or by using a ZK-SNARK ASIC (in development).
The project is building with zkEVM type 1
zkEVM Community Edition (started by community contributors including Privacy and Scaling ExplorationsScroll group, Taiko and others) is zkEVM type 1.
Type 2 (equivalent to EVM)
zkEVM type 2 is exactly equivalent to EVM, but not quite equivalent to Ethereum. CThey are identical to Ethereum on the inside, but they have some differences on the outside, especially in data structures such as block structure and status.
The goal is to be fully compatible with existing applications on Ethereum, but when deploying the dApp some minor modifications need to be made to create proofs faster.
Advantages: Perfect equivalent at EVM level
zkEVM type 2 makes changes to the data structure containing the Ethereum state. This are structures that the EVM itself cannot access directly, but applications running on Ethereum will most likely still operate on a type 2 zkEVM compilation. Devs it will not be possible to use Ethereum execution clients as-is, but it will be possible to use them with some modifications, and it will be possible to use EVM debugging tools and most other developer infrastructure.
There are a few exceptions, sIncompatibility arises for applications that verify historical Merkle proofs Ethereum blocks to verify claims about historical transactions, receipts or statuses. A zkEVM that replaces Keccak with another hash function will break these proofs. However, it is not recommended to build applications this way, because of future Ethereum changes would break such applications even on Ethereum itself. A better alternative is to add Ethereum itself compilations before accessing future proof history.
Disadvantages: Improvement but still slow
zkEVM type 2 provides faster proof times than type 1 primarily by eliminating parts of the Ethereum stack that rely on cryptographic complexity that are unnecessarily complex and unfriendly to ZK. In particular, they can change the Merkle Patricia tree based on Ethereum’s Keccak and RLP and also the block and receipt structures. Type 2 zkEVMs may instead use a different hash function, (e.g. Poseidon). Another natural modification is to modify the state tree to store the hash and keccak codes.
These modifications significantly improve authentication times, but they do not solve all problems. The slowness of having to demonstrate EVM as-is, with all the inherent inefficiencies and ZK-unfriendliness of EVM remaining.
The project is building with zkEVM type 2
Scroll’s zkEVM project is building towards ZK-EVM type 2, as well Polygon Hermez. At present, they are not ZK-EVM type 2.
Type 2.5 (equivalent to EVM, minus gas fee)
One way to Significantly improves worst-case proof time is to increase the gas fees of ZK proof operations in EVM. This may involve precompiling, the KECCAK opcode, and possibly contract-specific call patterns or memory access, storage, reverts.
Gas cost changes may reduce developer tools compatibility and crash some applicationsbut it is generally considered less risky than deeper EVM changes.
Another way to manage resource constraints is to simply set hard limits on the number of times the operation can be called. This is easier to do in circuits, but performs much worse with EVM security assumptions.
Type 3 (almost equivalent to EVM)
zkEVM type 3 almost equivalent to EVM, but sacrifices a bit to achieve exact equivalence to further improve normalization time by half and make EVM easier to develop.
Advantages: Easier to build and faster proofing time
Type 3 zkEVM may eliminate some features that are particularly difficult to implement in ZK-EVM. Additionally, Type 3 ZK-EVMs sometimes have slight differences in how they handle contract code, memory, or the stack.
Disadvantages: More incompatibility
The goal of zkEVM Type 3 is compatibility with most of applications and only require minimal rewrites for the rest. That said, there will be some applications that will need to be rewritten because they use compilations that do not match zkEVM Type 3.
The project is building with zkEVM type 3
Scroll and Polygon are both Type 3 in their current form, although they are expected to improve compatibility over time. Polygon has a unique design where they are verifying ZK using their own internal language called zkASM and they interpret zkEVM code using zkASM.
Today, there is no zkEVM group Who wants becomes type 3, lType 3 is simply a transitional phase until the complex pre-compilation work is finished and the project can move to type 2.5. However, in the future a type 1 or type 2 zkEVM may voluntarily become a type 3 zkEVM, by adding zk-SNARK-friendly precompiles new providing functionality to developers with time-to-proof and low gas costs.
Type 4 (high level language equivalent)
Type 4 zkEVM systems work by obtaining smart contract source code written in a high-level language (e.g. Solidity , Viper or some intermediate that both compiles to) and compiles the code that source to some language explicitly designed to be zk-SNARK friendly.
Advantages: Proof time is very fast
Yes very much overhead that you can avoid by not proving ZK in the EVM execution steps but starting directly from the higher level code. Compiling directly from high-level languages can actually significantly reduce costs and help decentralization by making it easier to be a prover.
Disadvantages: Not much compatible
A normal application written in Vyper or Solidity can be compiled and it will work properly, but there are a number of ways that a lot of applications are not normal:
- Contracts may not have the same address in a type 4 system like in EVM, because the CREATE2 contract address depends on the exact bytecode. This breaks applications that rely on undeployed reference contracts, ERC-4337 wallets, single EIP-2470 and many other applications.
- Handwritten EVM bytecode more difficult to use. Many applications use handwritten EVM bytecode in some parts for efficiency. Type 4 systems may not support it, although there are ways to implement limited EVM bytecode support to satisfy these use cases without attempting to become a Type 3 ZK-EVM.
- Lots of debugging infrastructurebecause such infrastructure runs on EVM bytecode. That said, this drawback is mitigated by access more into debugging infrastructure from mid- or high-level languages (e.g. LLVM).
The project is building with zkEVM type 4
ZKSync is a type 4 system, although it may add compatibility to the EVM bytecode over time. Project Warp by Nethermind is building a Starkware Solidity to Cairo compiler that will turn StarkNet into a de facto Type 4 system.
The future of zkEVM types
Each type of zkEVM has its own advantages and disadvantagesthey are different trade-offs: types with lower sequence numbers are more compatible with the existing infrastructure but slower, and types with higher sequence numbers are less compatible with the infrastructure Existing infrastructure but faster.
Additionally, zkEVM projects can easily start in higher numbered categories and move to lower numbered categories (or vice versa) over time.
Personally, Vitalik hopes that things will become type 1 over time, through a combination of improvements in zkEVM and improvements to Ethereum itself to make it zk-friendly. More SNARK. In such a future, there will be multiple zkEVMs that can be used both for ZK rollups and for verifying the Ethereum chain itself. Theoretically, Ethereum does not need to standardize on a zkEVM, Different clients may use different proofs.
However, it will take quite a while until we get to such a future. In the meantime, we will see a lot of innovation in different paths to scaling Ethereum and zkRollup on Ethereum.
Summary
The article provides the most comprehensive perspective on zkEVM, the technology that will develop strongly in the future to expand Ethereum. But that’s just the future, and currently this technology is still being raced by projects to develop it the fastest.
Hope this article brings you a lot of useful knowledge!
