Which zkEVM has the best performance? Ethereum L2 Contract Deployment Test

Question

Author: Jarrod Watts; Compilation: Block Beats

In the Ethereum expansion war, Optimistic rollups are highly compatible or even completely equivalent to the EVM, which leads to the inherent advantages of Arbitrum and Optimism on the track for developers to adopt. Its L1 to L2 seamless porting of code and rich development tools can quickly attract developers to settle in and deploy and create applications on the platform.

In contrast, the ZK series is more difficult. Its inherent technical characteristics cause ZK rollups to customize their own virtual machines, which means that the project party needs to do more work to "interpret" the code from the EVM or even develop and write new code from scratch. However, several ZK rollups track projects including Taiko, Polygon, Linea, Scroll and ZkSync Era have launched their own implementations of zkEVM.

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

This article compiles a summary of tweets from Jarrod Watts. He is a developer relations engineer at Polygon. By deploying smart contracts (1 Solidity smart contract and an NFT contract) on the current popular ZK rollups project, he measured the zkEVM performance of projects such as Taiko, Polygon, Linea, Scroll and ZkSync Era, and compared their respective advantages and disadvantages and L2 to L1 credits Time to provide a practical test guide for developers who want to try to deploy two-layer contracts.

The following is a compilation of the original text from BlockBeats:

**What is ZK-EVM and why do we need it? ****Before interpreting what ZK-EVM is, let's see why ZK-EVM is needed? **

ZK Rollups brings scalability and high performance to Ethereum. On the other side of the coin, the ZK Rollups solution is not compatible with EVM (Ethereum Virtual Machine), which means that the ZK Rollups solution can only support limited operations, including transfer, minting or burning, and tools such as wallets have to be developed for users.

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

ZK-EVM, or 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 L2 (layer 2), and send the "validity proof" of the batch transactions back to Ethereum L1. In general, zkEVM can do everything for 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 is that Ethereum was not originally designed with ZK friendliness in mind. This means that zero-knowledge proofs require a lot of resources to compute.

Among them, some EVM operation code opcodes are particularly "ZK-unfriendly", which leads to the ZK-EVM products finally designed by various companies with different EVM compatibility.

** What are opcodes, bytecode and EVM? **

It’s time for popular science, what are opcodes, bytecodes and EVM?

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

The EVM is deterministic, meaning that executing a set of instructions on any particular state will result in the same new state.

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

You can think of it as a game like chess. Ethereum is like a chessboard, where there are different game states, and in Ethereum, the possibilities of this state are infinite. Board games have their own specific rules of movement (compare transactions on Ethereum) and have specific restrictions on which actions can be performed on which pieces. Gamers take actions (compared to users submitting transactions on Ethereum), and the game (Ethereum) formulates and enforces the rules, resulting in a new board (Ethereum global) state after each round (corresponding to block time).

For Ethereum or any EVM-compatible blockchain development, smart contracts need to be written in Solidity. Solidity is a high-level language designed to be human-readable so that developers can focus on writing code rather than registers, memory addresses, call stacks, and other abstractions.

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

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

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

After compiling the Solidity code with the Remix IDE compiler, you can see the specific opcode that the smart contract is converted into, and view the bytecode generated from the opcode.

Here are the opcodes:

The following is the bytecode corresponding to the above opcode.

By translating bytecodes into opcodes, it is possible to know which execution instructions are contained in bytecodes.

Due to the difficulty of ZK proof for some specific opcodes in EVM, ZK-EVMs with different degrees of compatibility have appeared on the market. Among them, some ZK-EVM and EVM opcode sets are completely equivalent, some have partially modified some EVM opcodes, and one has completely different bytecodes.

Different types of ZK-EVM

Since the Ethereum design did not consider ZK friendliness at the beginning, in theory, the closer to the Ethereum design, the more difficult and time-consuming it is to generate ZK proofs. In August 2022, Vitalik, the founder of Ethereum, published a blog post "Listen to Vitalik's interpretation of the future of different types of ZK-EVM", classifying different ZK-EVMs.

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

1, the first type of ZK-EVM is completely 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 completely equivalent to the EVM, but changes some different internal representations, such as the storage method of the chain state, to speed up the generation time of ZK proofs. 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 exactly equivalent to the EVM, except that the gas cost of certain types of operations is increased to "significantly reduce the worst-case proof time". Currently, there is no ZK-EVM of this type on the market; however, a new ZK-EVM project called Kakarot is working on it.

Type 3 is nearly equivalent to EVM, but with some compromises in equivalent accuracy to further reduce proof time and simplify EVM development. Currently, Polygon, Linea, and Scroll are of this type.
Type 4 is equivalent to the high-level language of ZK-EVM. This type of ZK-EVM compiles the source code of the smart contract into a ZK-SNARK-friendly language, which will bring faster proof time and corresponding disadvantages such as incompatibility and limitations. Currently, zkSync Era falls into this category.

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

Practical combat: Taiko, Polygon, Linea, Scroll and ZkSync Era development evaluation

After reviewing the theoretical knowledge, the following is the actual combat 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 are tested. The author also gives the available developer resources, and the evaluation is mainly carried out from the two dimensions of developer experience and the bridging time from L2 to L1.

Taiko ZK-EVM

Taiko is a type 1 ZK-EVM and is currently in the testnet stage. Taiko handles exactly what Ethereum does; using the same hash functions, gas prices, encryption algorithms, etc.

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

The downside of Type 1 ZK-EVM is that it takes a long time to generate proofs when everything is exactly the same as in Ethereum (even internally). This means that it takes several hours for a user to bridge ETH from Taiko L2 back to Ethereum L1 (as shown below).

Line ZK-EVM

Linea belongs to type 3 ZK-EVM, and Linea cannot yet prove all opcodes or precompilation; it represents a different chain internal state from Ethereum, such as using a different hash function.

The deployed bytecode is the same as Ethereum.

The deployment process was almost seamless, making it easy to deploy and interact with both smart contracts. This is the same behavior as Ethereum; existing tools and wallets can be used to deploy smart contracts, interact with them, mint NFTs, etc.

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

According to the Linea documentation, the L2 to L1 bridge of ETH usually takes about 15 minutes, but in this case it took about a few hours.

Polygon ZK-EVM

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

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

Deploying bytecode on Polygon zkEVM is the same as Ethereum, which makes deploying and interacting with smart contracts very simple. Vitalik once said, "Polygon zkEVM has a unique design, and they are using ZK to verify their own internal language called zkASM".

The Polygon engineering team stated that in addition to improving the proof generation and withdrawal time, the remaining precompilation will be completed as soon as possible in the future, with the goal of becoming Type 2 in the Vitalik diagram.

In this deployment case, the zkEVM mainnet bridging went smoothly; the L2 -> L1 bridging process takes about 1 hour.

Scroll

Scroll belongs to Type 3 ZK-EVM and is currently in the testnet stage. Scroll also lists the differences between ZK-EVM and Ethereum EVM in the official documentation.

Like other Type 3 ZK-EVMs, the deployment process is almost seamless, and Solidity smart contracts and NFT collections are 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. Completely different from other ZK-EVMs, the smart contract bytecode deployed on ZkSync Era's zkEVM is different from Ethereum.

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

Although the ZK-EVM of ZkSync Era is quite different from the EVM, ZkSync Era provides a set of best practices and considerations for developers. Additionally, developers will need to make some minor adjustments to the development process to build specifically for ZkSync Era.

For example, in the example below, the Hardhat environment must be installed and configured with a custom zkSync extension to generate bytecode that can be deployed to the Era ZK-EVM.

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

It is worth noting that ThirdWeb has launched zkSync Era to provide developers with a more convenient deployment experience.

A total of two smart contracts are deployed during this operation, interact with them, and send assets from L2 back to L1. Currently, there is a 24-hour delay for withdrawals from the ZkSync Era mainnet to Ethereum L1 for security reasons.

Kakarot ZkEvm

Another project dedicated to realizing Type 2.5 ZK-EVM is Kakarot ZkEvm, which received financing from several institutions including Vitalik Buterin and StarkWare in June this year. Kakarot plans to release the testnet later in 2023.

Conclusion

For end users, it doesn't matter who wins the race, as the progress of an EVM-compatible ZK solution is a big win for the industry as a whole. For various project parties, it is not so much a competition as it is to explore different methods to promote the progress of the entire industry. Vitalik even has a "multi-certifier theory". The basic premise is that different Rollups can work together to enhance the overall security of Ethereum.

At the end of the day, everyone wants Ethereum to succeed. L2 expansion transformation is one of the three technical transformations that Vitalik believes that Ethereum needs to undergo. We will wait and see how it will develop in the future.

View Original