Which zkEVM performs the best? How should developers choose?

What is ZK-EVM and Why Do We Need It?

Before interpreting what ZK-EVM is, let's first look at why we need ZK-EVM?

ZK Rollups bring scalability and high performance to Ethereum, but the flip side is that ZK Rollup solutions are not compatible with EVM (Ethereum Virtual Machine). This means that ZK Rollup solutions can only support a limited set of operations, including transfers, minting, or burning, and also require the development of wallets and other tools for users.

Therefore, we need ZK Rollups that are compatible with EVM, and for this reason, multiple companies have developed their own ZK-EVMs.

ZK-EVM, or Zero-Knowledge EVM, is an implementation of the Ethereum Virtual Machine that is compatible with zero-knowledge proofs.

The main function of ZK-EVM is to batch process transactions on Ethereum L2 (Layer 2) and send the "validity proof" of that batch transaction back to Ethereum L1. Typically, zkEVM can do everything that the Ethereum mainnet can do. It compiles human-readable code in Solidity or Vyper into bytecode, executes smart contracts, and updates the blockchain state.

The difficulty in building EVM-compatible ZK Rollups lies in the fact that Ethereum's initial design did not consider ZK friendliness. This means that zero-knowledge proofs require a significant amount of resources for computation.

Some EVM opcodes are particularly "ZK unfriendly," leading to varying degrees of EVM compatibility in the ZK-EVM products ultimately designed by various companies.

What are opcodes, bytecode, and EVM?

It's time for some education: what are opcodes, bytecode, and EVM?

First, EVM is the execution environment for smart contracts on Ethereum. Ethereum stores what is called "machine state" in a trie tree data structure, which changes after executing each transaction in a block.

EVM is deterministic, meaning that executing a set of instructions on any specific state will produce the same new state.

According to the Ethereum developer documentation, an old valid state (S) + a set of new valid transactions (T) will produce a new valid output state S'.

You can think of it like a game of chess. Ethereum is like a chessboard, where different game states exist, and the possibilities of these states are infinite. Board games have their specific movement rules (compared to transactions on Ethereum), and there are specific restrictions on what types of pieces can perform which actions. Players take actions (comparable to users submitting transactions on Ethereum), and the game (Ethereum) sets and enforces the rules, resulting in a new board (global state of Ethereum) after each turn (corresponding to block time).

Developing on Ethereum or any EVM-compatible blockchain requires writing smart contracts in Solidity. Solidity is a high-level language designed to be human-readable, allowing developers to focus on writing code rather than abstract layers like registers, memory addresses, and call stacks.

However, EVM cannot read Solidity directly. Instead, it only understands "bytecode," which is a binary, machine-readable low-level code.

In EVM, "bytecode" represents a series of EVM "opcodes," which are low-level readable instructions that represent specific operations that can be executed in EVM.

Since high-level languages like Solidity cannot be executed directly in EVM, we need a way to convert smart contract code from human-readable Solidity to opcode bytecode, which can then be executed by EVM. This is the job of the compiler.

When using the Remix IDE compiler to compile Solidity code, you can see the specific opcodes that the smart contract is converted into and view the bytecode generated from those opcodes.

Here are the opcodes:

Here is the bytecode corresponding to the above opcodes.

By translating bytecode into opcodes, we can know which execution instructions are contained in the bytecode.

Due to the difficulty of generating ZK proofs for certain specific opcodes in EVM, various ZK-EVMs with different degrees of compatibility have emerged on the market. Some ZK-EVMs are completely equivalent to the EVM opcode set, while others have made partial modifications to some EVM opcodes, and another type has completely different bytecode.

Different Types of ZK-EVM

Since Ethereum's initial design did not consider ZK friendliness, theoretically, the closer the design is to Ethereum, the more difficult and time-consuming it is to generate ZK proofs. In August 2022, Ethereum founder Vitalik published a blog post titled “Vitalik Explains the Future of Different Types of ZK-EVM”, categorizing different ZK-EVMs.

In this article, Vitalik classified various ZK-EVMs based on two dimensions: EVM compatibility and ZK proof generation time (performance). He listed four (semi) types in the chart, encompassing all ZK-EVM products currently on the market.

The first type of ZK-EVM is fully equivalent to Ethereum; they do not change any part of the Ethereum system and are easier to generate proofs. In such systems, ZK proofs take a long time (several hours) to generate. Taiko belongs to this type of ZK-EVM.
The second type is fully equivalent to EVM but changes some different internal representations, such as the way chain state is stored, to speed up ZK proof generation time. Currently, there are no ZK-EVMs of this type on the market; however, Polygon, Linea, and Scroll are working in this direction.

2.5. Between type 2 and type 3, there is also a type 2.5. This type is fully equivalent to EVM but increases the gas cost for certain operations to "significantly shorten the worst-case proof time." Currently, there are no ZK-EVMs of this type on the market; however, a new ZK-EVM project called Kakarot is working towards this.

Type 3 is almost equivalent to EVM, but some concessions are made in equivalence accuracy to further shorten proof time and simplify EVM development. Currently, Polygon, Linea, and Scroll belong to this type.
Type 4 is akin to a high-level language for ZK-EVM. This type of ZK-EVM compiles the source code of smart contracts into a language friendly to ZK-SNARKs, which will lead to faster proof times but may also introduce incompatibilities and limitations. Currently, zkSync Era belongs to this type.

It is worth noting that the time required to send validity proofs back to Ethereum L1 is the same as the time it takes for users to transfer funds back to L1. If proof generation takes several hours, the user cannot bridge funds back to L1 during that time.

Practical Testing: Taiko, Polygon, Linea, Scroll, and ZkSync Era Development Evaluation

After reviewing the theoretical knowledge, here is the practical part.

By deploying Solidity smart contracts and NFT contracts on Taiko, Polygon, Linea, Scroll, and ZkSync Era, the author tested the performance of each ZK-EVM and identified corresponding defects. He also provided available developer resources, evaluating primarily from the perspectives of developer experience and L2 to L1 bridging time.

Taiko ZK-EVM

Taiko belongs to type 1 ZK-EVM and is currently in the testnet phase. Taiko can accurately handle all behaviors of Ethereum, using the same hash functions, gas prices, and cryptographic algorithms.

Process: A simple Solidity smart contract was deployed, and a simple NFT collection was deployed using the ThirdWeb proxy.

The drawback of type 1 ZK-EVM is that when everything is completely the same as Ethereum (even internally), generating proofs takes a long time. This means that users bridging ETH from Taiko L2 back to Ethereum L1 require several hours of processing time (as shown below).

Linea ZK-EVM

Linea belongs to type 3 ZK-EVM. Linea currently cannot prove all opcodes or precompiles; it represents a different internal state of the chain compared to Ethereum, such as using different hash functions.

The deployed bytecode is the same as Ethereum.

The deployment process was almost seamless, allowing for easy deployment of two smart contracts and interaction with them. This behaves similarly to Ethereum; existing tools and wallets can be used to deploy smart contracts, interact with them, mint NFTs, etc.

As of the writing of this article, Linea has not yet launched a bridging front-end interface. Therefore, it is only possible to directly call the functions of the bridging smart contract.

According to Linea's documentation, bridging ETH from L2 to L1 typically takes about 15 minutes, but in this case, it took several hours.

Polygon ZK-EVM

Polygon ZK-EVM belongs to type 3 ZK-EVM and has been live on the mainnet since the end of March this year.

Polygon zkEVM has listed all current differences between EVM and zkEVM in its official documentation.

Deploying bytecode on Polygon zkEVM is the same as Ethereum, making it very simple to deploy smart contracts and interact with them. Vitalik has stated, "Polygon zkEVM has a unique design, and they are using a ZK verification internal language called zkASM."

The Polygon engineering team has stated that in addition to improving proof generation and withdrawal times, they will also complete the remaining precompiles as soon as possible, aiming to become type 2 in Vitalik's chart.

In this deployment case, the zkEVM mainnet bridging was very smooth; the L2 -> L1 bridging process took about 1 hour.

Scroll

Scroll belongs to type 3 ZK-EVM and is currently in the testnet phase. Scroll has also listed the differences between ZK-EVM and Ethereum EVM in its official documentation.

Like the other type 3 ZK-EVMs, the deployment process was almost seamless, easily deploying Solidity smart contracts and NFT collections, and interacting with them. The bridging of funds from L2 to L1 is expected to take "10 minutes to several hours."

ZkSync Era

ZkSync Era belongs to type 4 ZK-EVM. It is completely different from other ZK-EVMs, as the smart contract bytecode deployed on ZkSync Era's zkEVM differs from Ethereum.

This allows ZkSync Era to provide a unique feature: native support for account abstraction, which will lead to a different developer experience. Typically, most crypto wallets are just standard addresses that can send and receive funds and interact with smart contracts. With account abstraction, crypto wallets can be customized and designed in more complex ways, offering a wider range of functionalities. Additionally, this zkEVM still allows developers to use the same high-level languages, such as Solidity.

Although ZkSync Era's ZK-EVM differs significantly from EVM, ZkSync Era provides a complete set of best practices and considerations for developers. Furthermore, developers need to make some minor adjustments to the development process to specifically build for ZkSync Era.

For example, in the following case, a custom zkSync extension must be used to install and configure the Hardhat environment to generate bytecode that can be deployed to the Era ZK-EVM.

The compilation generated a completely new bytecode that is entirely different from Ethereum, differing completely from the bytecode generated by the above ZK-EVMs.

It is worth noting that ThirdWeb has now launched on zkSync Era, providing developers with a more convenient deployment experience.

In this operation, a total of two smart contracts were deployed, interacted with them, and transferred assets from L2 back to L1. Currently, for security reasons, withdrawals from the ZkSync Era mainnet to Ethereum L1 have a 24-hour delay.

Kakarot ZkEvm

Another project dedicated to achieving type 2.5 ZK-EVM is Kakarot ZkEvm. This project received funding from several institutions, including Vitalik Buterin and StarkWare, in June of this year, and Kakarot plans to launch its testnet later in 2023.

Conclusion

For end users, it doesn't matter who wins the race, as the progress of EVM-compatible ZK solutions is a significant victory for the entire industry. For the various project teams, rather than a competition, it is more about exploring different methods to advance the progress of the entire industry. Vitalik even has a "multi-prover theory," which is based on the premise that different rollups can work together to enhance the overall security of Ethereum.

Ultimately, everyone hopes for Ethereum's success. The L2 scaling transformation is one of the three technological transformations that Vitalik believes Ethereum needs to undergo. How things will develop in the future remains to be seen.

New Developments in Layer2 Networks

Arbitrum, Optimism, zkSync, and StarkWare represent the four kings of Ethereum Layer 2 scaling solutions, with new narratives emerging continuously.

Column

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.