[Rollup Series]#2: Classification of zkEVMs and Taiko
We will examine Vitalik Buterin’s proposed five classifications of zkEVMs, specifically focusing on Taiko, which aims to implement Type-1 zkEVM.
Review: Steve Kim (@steve_nw_kim)
This article is Part 2 of the Rollup Series. If you would like to read the other parts, please check out the list below:
Part 1: Scroll, the Dream of a Native zkEVM
Part 2: Classification of zkEVMs and Taiko
Part 3: Beyond Equivalence to EVM-Native, Specular
Part 4: Exploring Coinbase’s L2 Network, Base
TL;DR
1) Vitalik Buterin categorized zkEVMs into five types based on their performance in generating zero-knowledge proofs and EVM compatibility.
2) Taiko is a general-purpose ZK rollup network that aims to become a Type-1 zkEVM with perfect EVM-equivalence.
3) While Taiko shares the same goal as Scroll, it prioritizes EVM compatibility and decentralization in the process of achieving it.
1. Introduction
In the Part 1 of the series, we explored Scroll network. Now we will focus on a project called Taiko, which aims to prioritize EVM compatibility and decentralization even more than Scroll. Taiko is a general-purpose ZK rollup network that is being developed specifically for Type-1 zkEVM. What does Type-1 mean here?
There are two main methods for classifying zkEVMs: one is based on language, bytecode, and runtime-level compatibility, which we covered in the previous article of the series, and the other is based on the performance of generating zero-knowledge proofs (ZKPs) and EVM compatibility presented by Vitalik Buterin. Both methods are similar in nature, but the number and names of the categories may vary slightly. Type-1 is one of the categories in Vitalik Buterin’s zkEVM classification, which refers to the zkEVMs with the highest level of compatibility with EVM. Before diving into Taiko, let’s take a brief look at Vitalik Buterin’s zkEVM classification method.
1.1 Classification of zkEVMs
Currently, there are several projects working on building zkVMs and zkEVMs, and Vitalik Buterin has proposed five classifications based on both the zero-knowledge proof (ZKP) generation performance (x-axis) and the Ethereum Virtual Machine (EVM) compatibility (y-axis). In the Type-n category, as the value of n increases, the speed of ZKP generation also increases, but EVM compatibility decreases.
1.1.1 Type-1
Type-1 is a category that prioritizes EVM compatibility over faster ZKP generation by avoiding any significant changes to the existing Ethereum system. In other words, it tries to maintain the original EVM system as much as possible and uses the same hash function, state tree, and transaction tree that Ethereum currently uses. The Ethereum Foundation’s PSE (Privacy and Scaling Explorations) team, Scroll team, and Taiko team are working together to develop Type-1 zkEVM.
The advantage of Type-1 is the ability to leverage existing development tools and infrastructure of Ethereum, including the client. However, the EVM is not optimized for zk-friendly design, leading to the need for extensive computations to generate ZKPs. Currently, creating one Zero Knowledge Proof (ZKP) of an Ethereum block can take several hours, but this can potentially be improved through the parallel operation of the prover (the entity that creates ZKP) and the development of hardware accelaration such as ASICs in the long term.
1.1.2 Type-2
Type-2 also strives for EVM-equivalence to the greatest level possible while making slight modifications to the system for more efficient ZKP generation. One notable modification is replacing the current hash function used in Ethereum, Keccak256, with a zero-knowledge-friendly hash function such as Poseidon, resulting in the changes in data structures like the block structure and state tree accordingly. In the medium term, Scroll and Polygon’s zkEVMs aim to achieve Type-2 compatibility.
The benefit of Type-2 is perfect equivalence at the VM level. Despite any changes made to data structures, dApps can still function in Type-2 zkEVM as in the existing Ethereum network because the EVM itself does not directly access these structures. Additionally, existing development tools can still be utilized.
However, one drawback of Type-2 is that the existing Ethereum client cannot be used as-is and requires slight modifications. Additionally, since the hash function has changed, it is not compatible with verifying the Merkle proof of the previous block (although this issue is already being addressed in the Ethereum roadmap, specifically through the transition from Merkle Tree to Verkle Tree). It’s also important to recognize that while changing the hash function to a zk-friendly one is a step forward, the ZKP generation time is still slow due to the many non-zk-friendly elements inherent in the EVM.
1.1.3 Type-2.5
Type-2.5 improves the worst-case scenario of ZKP generation by significantly increasing the gas costs of specific tasks, such as when generating ZKP is particularly difficult in Type-2. However, changing gas costs may create compatibility issues with existing Ethereum development tools, and it may also cause unexpected situations such as exceeding the gas limit of a block or rapidly increasing gas usage for dApps.
1.1.4 Type-3
Type-3 is a type of zkEVMs where some features that are exceptionally challenging to implement are removed, with Ethereum Precompiles being a typical example. It is mostly compatible with Ethereum dApps, but those using precompiles may require minor code modifications. Both the current Scroll and Polygon zkEVM fall into Type-3, with both aiming for higher compatibility. The EVM compatibility at the bytecode level described in Part 1 of the Rollup Series means Type-3.
1.1.5 Type-4
Type-4 involves converting high-level programming languages into zk-friendly languages. Therefore, a separate virtual machine (VM) needs to be built instead of using an existing one like EVM. Projects like StarkNet and zkSync are examples of Type-4. Type-4 offers the advantage of fast ZKP generation compared to the other types discussed earlier but has poor compatibility with existing Ethereum dApps.
2. Taiko
2.1 Overview
Taiko is a general-purpose ZK rollup project that aims to become a completely EVM-equivalent Type-1 zkEVM, as evident from the main screen of its homepage. As it pursues to become a Type-1 zkEVM, it prioritizes EVM-equivalence over ZKP generation speed, planningto support all EVM opcodes.
Taiko is largely consists of three parts, and its types and functions are more or less the same as other ZK rollups:
- zkEVM circuits: Taiko aims to generate ZKPs of EVM by maintaining the compatibility of Ethereum without any modifications. This is a significant advantage, as smart contracts are prone to errors, but using the battle-tested code from the Ethereum network and the existing development tools as they are is highly advantageous. Furthermore, the Taiko-client is based on the Geth, which ensures compatibility with future Ethereum protocol upgrades.
- L2 rollup nodes: Nodes in Taiko Rollup are responsible for collecting and executing users’ transactions using Geth’s fork.
- L1 smart contracts: Smart contracts deployed on Ethereum L1 are responsible for verifying data availability and zk-SNARKs (ZKP).
Blocks in Taiko Rollup have two states: finalized and on-chain finalized. In the finalized state, the rollup block is submitted to the L1 smart contract, and the order of blocks remains unchanged, creating an environment where anyone can validate the state. In the on-chain finalized, the submission of ZKP for the block has been completed and verified.
2.2 Improvement of Disadvantages
Since Taiko targets Type-1, it prioritizes EVM-equivalence over ZKP generation speed, which makes it disadvantageous in terms of ZKP generation time and cost compared to other ZK rollups. As the performance of ZKP generation deteriorates, it takes a longer time to achieve finality.
The fact that it takes a long time for the block to achieve finality (on-chain finalized state) is not a big problem, as Taiko has a special way to solve this, as mentioned by Vitalik Buterin in his tweet. When Taiko blocks are submitted to the L1 smart contract, they are typically given a finalized state that ensures the order of blocks cannot be changed, so there are no major issues from a UX perspective. (While it is important to have trust in Taiko’s sequencers for this approach to work, Taiko plans to decentralize sequencers when launching its mainnet.) Furthermore, even in scenarios where verification is required, such as network bridging, it is possible to do so without using full ZKPs. This is because proving the validity of a specific past state, such as a wallet balance, and demonstrating that it has remained unchanged for a certain period of time, due to the absence of transactions, is easier than proving the current state. As a result, this approach can simplify the verification process necessary for bridging.
2.3 Decentralization
In addition to EVM compatibility, Taiko has a strong focus on decentralization. While most rollup networks prioritize performance and gradually increase decentralization, Taiko plans to launch with decentralized proposers (sequencers) that submit blocks and provers that creates ZKPs. This highlights how much Taiko values decentralization, as there is currently no rollups with decentralized sequencers. (Reference: [Research] Efforts for Rollup Decentralization.) In addition to decentralizing the sequencers and provers, the team has also announced plans to prioritize DAO and will reveal specific details in a future post.
2.4 Testnet
Taiko has recently closed its alpha-1 testnet. According to the official website, the alpha-2 testnet is scheduled to launch soon. It is recommended to follow Taiko’s Twitter account to stay up-to-date with the latest developments.
3. Closing
Like Scroll reviewed in Part 1, Taiko is also a ZK rollup targeting to become a native zkEVM. Taiko aims to achieve full zkEVM, but differs from Scroll in its approach to EVM compatibility. While Scroll incrementally enhances EVM compatibility, starting from Type-3 zkEVM during its development, Taiko is designed with the objective of achieving greater EVM compatibility right from the beginning. Another difference between the two projects is their approach to decentralization. Scroll plans to decentralize the sequencers and provers after the mainnet launch, whereas Taiko plans to decentralize these components right from the beginning. It will be interesting to compare the progress of Scroll and Taiko, as they pursue the same goal but follow different paths to achieve it.
4. References
Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decisions based on the information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.
All for Equivalence
