zkEVM Performance Test Guide: How Developers Choose ZK rollups Projects?

Original Author: Jarrod Watts 

Original Compilation: BlockBeats

In the Ethereum scaling war, Optimistic rollups have a natural advantage over Arbitrum and Optimism in terms of developer adoption due to its high EVM compatibility or even complete equivalence. Its seamless code migration from L1 to L2 and rich development tools can quickly attract developers to join and deploy/create applications on the platform.

In contrast, ZK-based solutions are more challenging. The inherent features of ZK rollups require them to customize their own virtual machines, which means that project teams need to do more work to "interpret" the code from the EVM or even develop/write new code from scratch. However, multiple ZK rollup projects, including Taiko, Polygon, Linea, Scroll, and ZkSync Era, have launched their own zkEVM implementations.

As the holy grail of scaling, the zkEVM has a crucial impact on developers' experience in deploying contracts. Faced with a wide range of ZK rollup projects, how should developers choose?

This article compiles the summary from Jarrod Watts' tweet. He is a developer relations engineer at Polygon, who deployed smart contracts (one Solidity contract and one NFT contract) on popular ZK rollup projects and conducted performance tests on Taiko, Polygon, Linea, Scroll, and ZkSync Era. He compares their respective pros and cons and L2 to L1 confirmation times to provide a testing guide for developers who want to deploy Layer 2 contracts.

Below is the compilation from BlockBeats:

What is ZK-EVM and why do we need it?

Before understanding what ZK-EVM is, let's see why we need ZK-EVM.

ZK Rollups bring scalability and high performance to Ethereum. On the other hand, a downside of ZK Rollups is that the solution is not compatible with EVM (Ethereum Virtual Machine). This means that ZK Rollups only support limited operations, including transfers, minting, or burning of tokens, and also requires the development of wallets and other tools for users.

Therefore, we need ZK Rollups that are compatible with EVM. To achieve this, several companies have developed their own ZK-EVM.

ZK-EVM, which stands for Zero-Knowledge EVM, is an Ethereum Virtual Machine implementation compatible with zero-knowledge proofs.

The main function of ZK-EVM is to batch process transactions on Ethereum Layer 2 (L2) and send back the "validity proof" of that batch transaction to Ethereum Layer 1 (L1). Typically, zkEVM can do everything on the Ethereum mainnet. 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-friendlyness. This means that zero-knowledge proofs require a significant amount of computational resources.

Among them, certain EVM opcodes are particularly "ZK unfriendly", which leads to different EVM compatibility in the ZK-EVM products designed by different companies.

What are opcodes, bytecode, and EVM?

Time for some education! Opcodes, bytecode, and EVM, what are they?

First of all, EVM is the execution environment for smart contracts on Ethereum. Ethereum stores the so-called "machine state" in a trie data structure, and this structure changes after executing transactions in a block.

EVM is deterministic, which means 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 result in a new valid output state S'

You can think of it like a game of chess. Ethereum is like a chessboard with different game states, and in Ethereum, the possibilities of these states are infinite. Chess games have their own specific move rules (compared to transactions on Ethereum), and there are also specific restrictions on which actions can be performed on which pieces. Players take actions (compared to users submitting transactions on Ethereum), and the game (Ethereum) formulates and enforces rules, resulting in a new chessboard (Ethereum's global) state after each turn (corresponding to block time).

To develop Ethereum or any EVM-compatible blockchain, you need to write smart contracts using Solidity. Solidity is a high-level language designed to be human-readable, allowing developers to focus on writing code rather than dealing with abstractions like registers, memory addresses, and call stacks.

However, the EVM cannot understand Solidity directly. Instead, it can only interpret "bytecode," which is a binary, machine-readable low-level code.

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

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

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

Below are the opcodes:

Below are the corresponding bytecode for the above opcodes.

By translating bytecode into opcodes, you can determine which execution instructions are included in the bytecode.

Because it is difficult to provide ZK proofs for some specific opcodes in the EVM, there are different degrees of ZK-EVM compatibility on the market. Some ZK-EVMs are completely equivalent to the EVM opcode set, some have made partial modifications to some EVM opcodes, and some have completely different bytecode.

Different Types of ZK-EVM

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

In this article, Vitalik classified various ZK-EVMs based on EVM compatibility and ZK proof generation time (performance). In this chart, Vitalik listed four (semi) types, and all ZK-EVM products on the market can be included.

1, the first type of ZK-EVM is completely equivalent to Ethereum and does not change any part of the Ethereum system, making it easier to generate proofs. In this system, ZK proofs take a long time (several hours) to generate. Taiko belongs to this type of ZK-EVM.

2 , the second type is equivalent to EVM, but it changes some internal representations, such as the storage method of chain state, to speed up the generation time of ZK proofs. Currently, there is no such type of ZK-EVM on the market; however, Polygon, Linea, and Scroll are working towards this direction.

2.5 , between type 2 and type 3, there is also a type 2.5 . This type is equivalent to EVM, but increases the gas cost of certain operations to "significantly shorten the proof time in worst-case scenarios". Currently, there is no such type of ZK-EVM on the market; however, a new ZK-EVM project called Kakarot is making efforts in this aspect.

3 , type 3 is almost equivalent to EVM, but makes some concessions in equivalent accuracy to further shorten the proof time and simplify the development of EVM. Currently, Polygon, Linea, and Scroll belong to this type.

4 , type 4 is equivalent to a high-level language for ZK-EVM. This type of ZK-EVM compiles the source code of smart contracts into ZK-SNARK friendly languages, which will bring faster proof time but also limitations and compatibility issues. Currently, zkSync Era belongs to this type.

It is worth noting that the time it takes to send the validity proof back to Ethereum L1 is the same as the time it takes for the user to bridge the funds back to L1. If proof generation takes several hours, the user will be unable to bridge the funds back to L1 during that time.

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

With the theoretical knowledge reviewed, the following is the practical part.

By deploying Solidity smart contracts and NFT contracts on Taiko, Polygon, Linea, Scroll, and ZkSync Era respectively, the performance of each ZK-EVM and the corresponding defects are tested. The author also provides available developer resources, and the evaluation is conducted mainly from the dimensions of developer experience and L2 to L1 bridge time.

Taiko ZK-EVM

Taiko belongs to type 1 ZK-EVM and is currently in the testnet phase. Taiko can accurately handle all Ethereum behaviors; using the same hash function, gas price, encryption algorithm, etc.

Operation process: deployed a simple Solidity smart contract and deployed a simple NFT collection using ThirdWeb proxy.

Type 1 ZK-EVM's drawback is that it takes a long time to generate proofs when everything is exactly the same as Ethereum (even internally). This means that it takes several hours for users to transfer ETH from Taiko L2 back to Ethereum L1 (as shown below).

Linea ZK-EVM

Linea belongs to Type 3 ZK-EVM. Currently, Linea cannot prove all opcodes or precompiles; it represents a different chain's internal state compared to Ethereum, for example, using different hash functions.

The deployed bytecode is the same as Ethereum.

The deployment process this time is almost seamless, making it easy to deploy two smart contracts and interact with them. This behavior is the same as Ethereum; you can use existing tools and wallets to deploy smart contracts, interact with them, mint NFTs, etc.

At the time of writing, Linea has not yet launched a bridge frontend interface. Therefore, only direct invocation of bridge smart contract functions is possible.

The Linea documentation shows that the L2 to L1 bridge for ETH usually 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 since the end of March this year.

The Polygon zkEVM official documentation lists all the current differences between EVM and zkEVM.

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

The Polygon engineering team also stated that in addition to improving proof generation and withdrawal times, they plan to complete the remaining precompiles as soon as possible, with the aim of becoming a type 2 in Vitalik's chart.

In this deployment case, the zkEVM mainnet bridging went smoothly; 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 also lists the differences between ZK-EVM and Ethereum EVM in their official documentation.

Similar to other type 3 ZK-EVM deployments, this deployment process was seamless and easily deployed Solidity smart contracts and NFT collections for interaction. The bridging of funds from L2 to L1 is expected to take "10 minutes to a few hours".

ZkSync Era

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

This allows ZkSync Era to provide native support for account abstraction, which brings 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 are customizable and can be designed in more complex ways, offering a wider range of functionalities. Additionally, the zkEVM still allows developers to use the same high-level language, such as Solidity.

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

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

The compilation generates completely new bytecode that is different from Ethereum, and it is completely different from the bytecode generated by the above ZK-EVM.

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

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

Kakarot ZkEvm

Another project dedicated to implementing ZK-EVM of type 2.5 is Kakarot ZkEvm. The project secured funding from multiple institutions, including Vitalik Buterin and StarkWare, in June this year. Kakarot plans to launch a testnet later in 2023.

Conclusion

For end users, it does not matter who wins the race, as the progress of EVM-compatible ZK solutions is a major victory for the entire industry. For each project, it is more of an exploration of different methods to advance the industry, and Vitalik even has a "multi-prover theory" based on the premise that different Rollups can work together to enhance the overall security of Ethereum.

In the end, everyone hopes for the success of Ethereum. L2 scalability transition is one of the three technological transformations that Vitalik believes Ethereum needs to go through. We look forward to how things will unfold in the future.