Which is the best performing zkEVM? Real-world testing of Ethereum L2 contract deployment.

Original author: Jarrod Watts

Translation: BlockBeats

In the Ethereum scaling war, Optimistic rollups have a natural advantage in developer adoption due to their high compatibility with EVM, even to the point of being completely equivalent. This has led to Arbitrum and Optimism occupying a leading position in this field. Their seamless migration of code from L1 to L2 and rich development tools can quickly attract developers to deploy and create applications on their platforms.

Compared to that, the ZK series is more difficult. Its inherent technical characteristics require ZK rollups to customize their own virtual machines, which means that project parties need to do more work to "interpret" code from EVM or even develop and write new code from scratch. However, multiple ZK rollup projects in the Taiko, Polygon, Linea, Scroll, and ZkSync Era tracks, including their own zkEVM implementations, have been launched.

As the holy grail of expansion, zkEVM has a crucial impact on the deployment experience of developers' contracts. Faced with a variety of ZK rollups projects, how should developers choose?

This article compiles the summary of tweets from Jarrod Watts, who is a developer relations engineer at Polygon. He deployed a Solidity smart contract and an NFT contract on the popular ZK rollups project to test the zkEVM performance of Taiko, Polygon, Linea, Scroll, and ZkSync Era projects. He compared their respective advantages and disadvantages, as well as the time it takes to transfer from L2 to L1, providing a testing guide for developers who want to deploy second-layer contracts.

Translated from the original article by BlockBeats:

ZK-EVM is and why do we need it?

Before interpreting what ZK-EVM is, let's first take a look at why ZK-EVM is needed?

ZK Rollups bring scalability and high performance to Ethereum. On the other hand, the flip side of ZK Rollups is that the solution is incompatible with the Ethereum Virtual Machine (EVM). This means that the ZK Rollups solution can only support limited operations, including transfers, minting, or burning, 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, multiple companies have developed their own ZK-EVM.

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

ZK-EVM's main function is to batch process transactions on Ethereum L2 (Layer 2) and send the "proof of validity" of the batch transaction back to Ethereum 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 of 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.

Among them, some EVM opcodes are particularly "ZK-unfriendly", which has led to different EVM compatibility in the ZK-EVM products designed by various companies.

What are opcodes, bytecode, and EVM?

It's time for a popular science lesson. What are opcodes, bytecode, and EVM?

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

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, a new valid output state S' will be generated by Ethereum when an old valid state (S) and a set of new valid transactions (T) are combined.

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

To develop on Ethereum or any EVM compatible blockchain, it is necessary 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 abstract concepts such as registers, memory addresses, and call stacks.

However, EVM is unable to read Solidity. Instead, it can only understand "bytecode", which is a binary, machine-readable low-level code.

In the EVM, "bytecode" refers to a series of EVM "opcodes". Opcodes are low-level, readable instructions of a program that represent specific operations that can be executed in the EVM.

Due to the fact that 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 bytecode, which is then executed by the EVM. This is the job of the compiler.

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

Here are the operation codes:

Here are the bytecode corresponding to the above operation codes.

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

Due to the difficulty of providing ZK proofs for certain opcodes in EVM, there are different levels of compatibility for ZK-EVM in the market. Some ZK-EVMs are completely equivalent to the EVM opcode set, while others have made partial modifications to some EVM opcodes. There is also a type of ZK-EVM that has completely different bytecode.

Types of ZK-EVM

Due to the fact that Ethereum's design did not initially 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 "Understanding the Future of Different Types of ZK-EVM with Vitalik", classifying different ZK-EVMs.

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

1. The first type of ZK-EVM is completely equivalent to Ethereum and will not modify 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 fully equivalent to EVM, but changes some different 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 completely equivalent to EVM, except that it increases the gas cost of certain operations in order to "significantly shorten the proof time in the worst case". Currently, there is no ZK-EVM of this type on the market; however, a new ZK-EVM project called Kakarot is working towards this direction.

3, Type 3 is almost equivalent to EVM in terms of functionality, but it has made some concessions in terms of equivalence accuracy to further shorten proof time and simplify EVM development. Currently, Polygon, Linea, and Scroll belong to this type.

4, Type 4 is equivalent to the advanced language of ZK-EVM. This type of ZK-EVM compiles the source code of smart contracts into ZK-SNARK friendly language, which will bring faster proof time but also lead to drawbacks such as incompatibility and limitations. Currently, zkSync Era belongs to this type.

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

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

The theoretical knowledge review is completed, and 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 and corresponding defects of each ZK-EVM were tested. The author also provided available developer resources, and the evaluation was conducted from two dimensions: developer experience and bridging time from L2 to L1.

Taiko ZK-EVM

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

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

The disadvantage of type 1 ZK-EVM is that when everything is identical to Ethereum (even internally), generating proofs takes a long time. This means that it takes several hours for users to process the transfer of ETH from Taiko L2 back to Ethereum L1 (as shown below).

Linea ZK-EVM

Linea belongs to type 3 ZK-EVM. Currently, it cannot prove all opcodes or pre-compilations. It represents the internal state of a chain that is different from Ethereum, such as the use of different hash functions.

The deployed bytecode is the same as Ethereum.

This deployment process was almost seamless, allowing for easy deployment of two smart contracts and interaction with them. This is similar to Ethereum's behavior; existing tools and wallets can be used to deploy smart contracts, interact with them, mint NFTs, and more.

At the time of writing this article, Linea has not yet launched the bridged front-end interface. Therefore, only the bridged smart contract functions can be directly called.

According to the Linea document, the L2 to L1 bridging of ETH usually takes about 15 minutes, but in this case study, it took several hours.

Polygon ZK-EVM

Polygon ZK-EVM belongs to Type 3 ZK-EVM and has launched its mainnet since the end of March this year.

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

Deploying bytecode on Polygon zkEVM is the same as on Ethereum, making it very easy to deploy smart contracts and interact with them. Vitalik has stated that "Polygon zkEVM has a unique design and they are using ZK verification for their 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, with the goal of becoming a 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 testing phase. Scroll is also listed in the official documentation as the difference between ZK-EVM and Ethereum EVM.

Like the other 3 types of ZK-EVM, the deployment process was almost seamless, and Solidity smart contracts and NFT collections were easily deployed and interacted with. Bridging 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. Unlike other ZK-EVMs, the smart contract bytecode deployed on zkEVM in ZkSync Era is different from Ethereum.

This allows ZkSync Era to provide a unique feature, which is native support for account abstraction. This will bring 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, providing a wider range of functionality. Additionally, the zkEVM still allows developers to use the same high-level languages, such as Solidity.

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

For example, in the following case, it is necessary to use the custom zkSync extension to install and configure the Hardhat environment to generate bytecode that can be deployed to Era ZK-EVM.

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

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

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

Kakarot ZkEvm

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

Related Reading:

"Detailed Explanation of Kakarot: The zkEVM Project Favored and Invested by Vitalik"

Conclusion

For end users, it doesn't matter who wins the game, because the progress of EVM-compatible ZK solutions is a great victory for the entire industry. For each project party, it is more like exploring different methods to promote the progress of the entire industry rather than a competition. Vitalik even has a "multi-prover theory", the basic premise of which is that different Rollups can work together to enhance the overall security of Ethereum.

Ultimately, everyone hopes that Ethereum can succeed. L2 scaling transformation is one of the three technical transformations that Vitalik believes Ethereum needs to undergo. We look forward to seeing how it will develop in the future.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia