Author: Christine Kim
Original compilation: ETH, 0x11, ForesightNews
Introduction
The zero-knowledge Ethereum Virtual Machine, zkEVM, is a much-anticipated and potentially game-changing technology that could improve Ethereum’s scalability in the short and long term. This year's three major Ethereum scaling projects, zkSync, Polygon, and Scroll, have each announced significant progress in their zkEVM implementations, many of which launched Alpha earlier this year and are now operating independently as L2 blockchains. Over time, it is possible that the zkEVM will run directly on Ethereum's base layer.
zkEVM is a virtual machine that can execute the same high-level programming language or low-level bytecode as the Ethereum Virtual Machine (EVM), and proves this code using a zero-knowledge proof ZKP, and a cryptographic proof to verify the data itself without revealing it any information about , such as its attributes or content. Back in 1982, computer scientists Goldwasser, Micali, and Rackoff (Silvio Micali was the founder of the Algorand blockchain) first introduced the ZKP concept. ZKPs are often confused with homomorphic encryption, another branch of cryptography. Homomorphic encryption, which allows operations to be performed on encrypted data without decrypting it, was first proposed by Rivest, Adleman, and Dertouzos in 1978, and has become one of the key technologies for cloud computing and storage. It is worth noting that homomorphic encryption is also used in some public blockchain protocols, such as the privacy coin Grin, which uses it to obfuscate transaction amounts.
Over the past 40 years, computer scientists have invented a variety of algorithms to safely and efficiently generate ZKPs, many of which fall into two broad categories: Scalable Transparent Arguments of Knowledge (STARKs) or Succinct Non-Interactive Arguments of Knowledge (SNARKs). These algorithms were developed for a wide range of use cases, including nuclear disarmament (the act of eliminating and reducing nuclear weapons), identity systems, and more recently, scalable public blockchains and cryptocurrencies. On Ethereum in particular, many developers consider ZKPs to be the "holy grail" for scaling due to their simplicity and ease of verification compared to other encryption schemes. Difficult to build or crack but easy to verify is a common goal of cryptographic protocol developers so that it can be widely and effectively used.
Zero-knowledge systems are difficult to generalize and apply to prove codes of arbitrary complexity, and building ZKPs to natively support and prove all types of transaction activity on the Ethereum blockchain has been an ongoing research effort by developers over the past few years plan. It wasn't until November 2021 that Starkware launched the first general-purpose ZK system for proving transactions based on Ethereum, which was implemented through Cairo, a custom programming language created by the Starkware team. However, in July 2022, three different Ethereum-based L2 protocols including zkSync, Polygon, and Scroll announced a breakthrough in scaling Ethereum using ZKP in the form of zkEVM.
Note: Although colloquially called zkEVM, these virtual machines do not take advantage of ZKP's privacy advantages, but fully benefit from ZKP's security and efficiency advantages. Therefore, a more accurate name for these types of virtual machines is Proof of Validity Generation EVM, but in this report they will use the more popular name zkEVM.
This report aims to familiarize the reader with the general concept of the zkEVM and understand its various implementations in Ethereum development. Since zkEVM is a relatively abstract topic, this report begins with a brief overview of the current state of the Ethereum network, and lays the foundation for understanding zkEVM by introducing core concepts such as block production, EVM, and Rullups. We will then summarize the different types of zkEVM that can exist on Ethereum and compare the 5 main zkEVM implementations currently in production. We will highlight the implementation challenges of this emerging technology, as well as our outlook for the zkEVM competitive landscape over time. Overall, zkEVM is still in the early stages of Ethereum development and adoption.
Ethereum today
Before diving into the intricacies of the zkEVM, it is important to first understand at a high level how transactions are included in Ethereum blocks.
block generation
When a user submits a new transaction to Ethereum, computers connected to the network (also called nodes) store the transaction in a local data structure called a mempool. The mempool is responsible for maintaining a list of unconfirmed transactions, and then randomly selects validators who run nodes and stake 32 ETH , through which the transactions in the mempool are batched into blocks. Validators who choose to add new blocks to the Ethereum blockchain are sometimes called "proposers". To gain additional rewards from MEV, some proposers will rely on third-party block builders instead of the local mempool when building blocks.
Blocks are ordered and linked together by parent blocks (previous block headers). Each block contains the hash of its parent block and forms the blockchain data structure by linking blocks together. Linking blocks via parent block hashes is shown in the following diagram:
Before September 15, 2022, Ethereum relied on the proof-of-work PoW consensus mechanism. Miners replaced verifiers to be responsible for block production. Miners do not need to mortgage a large amount of capital, but need to consume a large amount of electricity to process user transactions.
Under the PoW and PoS consensus protocols, the lack of scalability of the Ethereum blockchain stems from the limited block space. Block space is limited by Gas on Ethereum. Transactions that require more computational work to execute are typically priced at higher gas units, while transactions with lower computational costs (i.e., less resource intensive) have lower gas costs. Gas is converted to ETH through the Ethereum network automatically setting a dynamic gas rate called the base fee. The Ethereum protocol limits block space, they can only contain a maximum of 30 million units of Gas. This maximum block gas limit ensures fast block propagation times and reduces the risk of hard forks.
Ethereum Virtual Machine
Once transactions are included in a block on Ethereum, they are executed through a custom runtime called the Ethereum Virtual Machine (EVM). The EVM is designed to deploy code of arbitrary complexity on Ethereum, which is what makes Ethereum a general-purpose blockchain, sometimes referred to as a Turing-complete system.
There are certain rules for how the EVM executes transactions. First, the EVM compiles human-readable programming languages such as Solidity and Yul into a machine-oriented or "low-level" language called EVM bytecode. The EVM then parses the bytecode into a list of sequential instructions called "opcodes". Each opcode instructs the EVM to perform a different task and is represented in the EVM bytecode in hexadecimal form. For example, an opcode that instructs the EVM to preserve transient data when a smart contract is executed on-chain is represented mnemically as "MSTORE", or in hexadecimal as "0x52". To help readers conceptualize opcodes, the following are simple opcodes as defined in the Ethereum Yellow Paper:
Over the years, Ethereum developers have continued to add new opcodes to the EVM, and they have also added precompilations that enable users to perform more advanced operations on the network, such as hash functions and scalar multiplication. As the first runtime environment of its kind, the EVM has been widely adopted as the standard for smart contract deployment on general-purpose public blockchains. However, as a first-of-its-kind technology, the EVM does have design limitations, the most relevant of which is the lack of ZKP compatibility of the EVM.
Rollups
In order to improve the scalability of Ethereum, there are some L2 networks that abstract transaction execution from the base layer to Rollups. Rollups compress transaction data so that the amount of block space required to submit a batch of transactions to the base layer is significantly lower than the amount of block space required to confirm these transactions individually through the on-chain mempool. Rollups are run by network operators called "orderers," not validators or miners. The sequencer is responsible for validating the state transitions of Rollups. They are entities that package user transactions into a batch of Rollups, and then submit the proof of this batch of transactions to the Ethereum base layer. The following figure illustrates the role of the sorter in Rollups:
Rollups are different from other scaling solutions on Ethereum, such as Plasma and state channels. Over the course of Ethereum's history, core developers have researched and scrapped Ethereum's scalability roadmap. There are two main types of Rollups: Optimistic Rollups and ZK Rollups. Optimistic Rollups rely on fraud proofs, meaning changes to the state of the L2 network are deployed to Ethereum without direct proof of their validity. Invalid state transitions can be detected and canceled as long as at least one honest participant is observing the state transitions of an Optimistic Rollup . In the case of Arbitrum and Optimism, the "challenge window" in which fraud proofs can be submitted lasts one week. A state transition for an optimistic Rollup is considered final and valid once the challenge window is over.
ZK Rollups, on the other hand, rely on ZKP, which generates proof of validity every time a transaction batch is processed on L2, and publishes it to Ethereum. Automatically generating proofs of validity for all transaction batches also increases the security of ZK Rollup . This also means that funds can be withdrawn from ZK Rollups every time a new proof of validity is submitted to Ethereum, whereas for optimistic Rollups there is usually a waiting period of about 7 days in order to allow disputes and fraud proofs to be generated. ZK Rollups also provides better data compression than optimistic Rollups. The following table summarizes the differences between optimistic and ZK Rollup :
The main advantage of Optimistic Rollup over ZK Rollups is that the virtual machine of Optimistic Rollup is almost the same as that of EVM. Optimistic Rollup implementations currently running on Ethereum, such as Optimism and Arbitrum, simulate the same transaction execution environment as Ethereum, called OVM and AVM respectively. Most ZK Rollups are application-specific, meaning they do not support all types of Ethereum-based transactions and DApps. Loopring, StarkEx Rollups, and zkSync 1.0 are examples of application-specific ZK Rollups that enable specific types of payments, token transactions, and NFT minting.
Certain ZK Rollups like StarkNet are universal, meaning they support all types of transactions and DApps. However, these ZK Rollups require Rollup developers to learn how to execute their smart contract code in a new custom execution environment, which is usually optimized for ZKP generation rather than EVM compatibility. This presents a challenge for the adoption of ZK Rollups on Ethereum, given the difficulty for existing decentralized applications and users to onboard the new execution environment. To overcome this problem, ZK Rollups projects such as Polygon Hermez, zkSync, and Scroll are working on implementing ZK Rollups compatible with the EVM, which is the native execution environment for all smart contract code on Ethereum.
STARKs, SNARKs, Volitions and Validiums
In practice, Rollups are differentiated not only by the type of proofs issued on the chain (fraud proofs in optimistic Rollup or validity proofs in ZK Rollups), but also by Rollups' data availability strategies and proof algorithms.
There are currently two broad categories of validity proofs known as SNARKs and STARKs.
SNARKs rely on elliptic curve cryptography, a data encryption technique most commonly used in Bitcoin and Ethereum. SNARKs also typically rely on a trusted setup, meaning that the algorithm requires a piece of data to be generated in advance by a trusted entity. A trusted setup is not a recurring event, but a one-time process by which a person or group of people generates core data. This data is called the Common Reference String (CRS), and it is a numerical value used in the zk-SNARK algorithm to generate trustworthy proofs. If the inputs required to generate the CRS are compromised, it could lead to incorrect proof generation. Therefore, it is important that all trusted setup participants destroy the inputs used to generate the CRS/SRS, or make them irrecoverable after the ceremony is complete.
STARKs do not rely on elliptic curves or trusted settings. STARKs rely on hash functions, which some developers believe are beneficial against quantum cryptography. However, STARKs are more complex and require more computing resources to run. It was launched in 2018, after SNARKs, which have been around since 2012. For these reasons, SNARKs are more widely used than STARKs. Some examples of STARKs-based algorithms include Fractal, SuperSonic, Fri-STARKs, and genSTARK.
In addition to different methods of generating validity proofs, ZK Rollups also differ in their data availability strategies. The data availability policy will determine which components of the transaction batch are ultimately published on-chain. Rollups, including Optimistic and ZK, typically commit three copies of data to mainnet Ethereum each time a batch of transactions is processed. First, Rollups validators submit the root hash of the new network state to Ethereum. (The state refers to the updated record of transactions and account balances on L2.) The state is recorded in a Merkle tree data structure, as shown in the following figure:
The root hash is a cryptographic commitment of the entire Merkle tree, sometimes called a state commitment. While not all ZK Rollups are required to commit the root hash to Rollup , they typically do so in order to allow data published on Ethereum to easily reconstruct and verify transactions executed on the Rollup .
Cryptographic proofs are recorded on Ethereum in addition to the high-level root hash used to confirm the new state of the L2 blockchain. In the case of an Optimistic Rollup , this proof can be a ZKP or a Fraud Proof. It can be generated by STARKs or SNARKs algorithm. Finally, in addition to these two pieces of data, ZK Rollups also publishes to Ethereum a compressed version of the processed transaction batch, also known as the State delta. State delta is a cost-effective way to submit large amounts of transaction data to Ethereum, which is unique to ZK Rollups. Optimistic Rollups use other data compression techniques to batch transactions and submit them on-chain.
Also, some ZK Rollups projects, such as the Scroll team, don't actually rely on posting state deltas to Ethereum for the additional data compression benefit. Scroll developers believe that upcoming code changes such as Ethereum Improvement Proposal EIP-4844 and danksharding will significantly reduce the cost of submitting transaction data to Ethereum, such that the efficiency gains of State delta over other data compression techniques are negligible.
Rollups use data from the lowest level of the Merkle tree and combine it with the root distribution from the highest level (the root) of the Merkle tree, allowing anyone to reconstruct and verify the contents of batches of transactions submitted on-chain. A defining feature of most Rollups is the ability to recreate transactions executed on the L2 network using on-chain data committed to Ethereum. However, some Rollups avoid submitting state delta or other compressed transaction data to Ethereum, and instead publish the data elsewhere to reduce operational costs and improve network scalability. Some developers will argue that L2 networks that avoid committing transaction data to Ethereum and thus break transaction reconstruction guarantees should not be classified as Rollups.
The way Rollup handles State delta determines whether the network can be classified as Validium or Volition.
Validium can be understood as Rollups, which only submit validity proofs and root hashes on the chain, while storing State delta on a separate network off the chain. Because Rollups no longer relies on Ethereum's data availability and is limited by network block space, this can theoretically increase the transaction throughput of Rollups to 9,000 TPS. The downside of Validiums is security, the separate network used to publish off-chain data does not have the same security guarantees as Ethereum.
Volitions leave the decision to issue State deltas off-chain or on-chain to users, pioneered by Ethereum scaling startup Starkware. This is a novel way to let users decide if their transactions require enhanced security by confirming directly on-chain to an off-chain network like Ethereum or Starkware's trusted Data Availability Council (DAC), at potentially higher cost .
4 main levels of EVM equivalence
The above content helps to understand the overall framework of transaction execution on Ethereum, EVM and ZK Rollups, and now discuss zkEVMs.
zkEVM is a ZK Rollup that mimics the same transaction execution environment as mainnet Ethereum. Implementations of zkEVM differ in proof algorithms and data availability strategies, as well as in the EVM equivalent level of zkEVM. There are four main levels of EVM equivalence. Here is a summary of the different levels:
language proficiency equivalent
In order to achieve language-level EVM equivalence, zkEVM must be able to understand and natively compile an EVM-friendly language. In other words, these types of zkEVMs translate an EVM-friendly programming language such as Solidity or Yul into a custom language optimized for generating ZKPs. This is considered to be one of the easiest and most effective ways to achieve EVM compatibility in ZK-Rollups. However, these types of zkEVMs are the most limited in terms of providing users and smart contract developers with the same experience as interacting with the EVM.
Language-level compatibility with the EVM means running Solidity through a compiler that translates the EVM's high-level programming language into a custom low-level language that is interpreted by a virtual machine designed to generate ZKPs. For most Ethereum users and smart contract developers who only care about interacting with the EVM through Solidity code, the underlying behavior of the zkEVM may not matter as long as the same type of code can be executed through the zkEVM as on the Ethereum mainnet. On the other hand, complex development tools, frameworks, and test environments built for the EVM may need to be modified to work on zkEVM with only language-level EVM compatibility.
bytecode-level equivalent
The second and third level of EVM equivalence is the bytecode level, which requires ZK Rollups to interpret EVM bytecode compiled from a higher level language such as Solidity or Yul. zkEVM can emulate the same high-level programming language and low-level bytecode as the EVM, enabling deeper compatibility with the EVM. These types of zkEVMs are more complex to build and require more advanced engineering.
The way a virtual machine executes EVM bytecode is through a specific list of instructions called opcodes, each of which instructs the EVM to perform a different task. The goal of bytecode-compatible zkEVM is to create a ZK system that can prove EVM bytecode and parse the various opcodes contained in the bytecode. The advantage of these types of zkEVMs is that they are compatible with EVM-based applications and tools. A fully bytecode-compatible zkEVM will be able to support the same debugging tools and developer infrastructure as native Ethereum-based applications. However, achieving full bytecode compatibility often leads to the creation of inefficient and expensive ZK systems, and reducing costs and improving efficiency have to be considered.
Currently, there are two bytecode-compatible zkEVMs, including the Polygon zkEVM and the Scroll zkEVM. In their current designs, these two implementations are only partially compatible with EVM bytecode, however, over time, these implementations are working towards full compatibility.
consensus level equivalence
The fourth and final level of EVM equivalence is the consensus level. This is the highest native EVM compatibility ZK Rollups can achieve. It is sometimes called "enshrined Rollups", although not all "enshrined Rollups" need to be based on ZK, and can also be Optimistic Rollups. The idea is that cryptographic proofs generated by zkEVM do not need to be re-executed on Ethereum in any capacity, the proofs themselves can be used to verify blocks produced on mainnet Ethereum. In a sense, a zkEVM that achieves consensus-level compatibility is the truest form of zkEVM.
For some developers, ZK Rollups that achieve consensus-level compatibility are the only ZK Rollups that should be called Rollup , while other ZK Rollups with language and bytecode compatibility should be considered EVM-compatible respectively Equivalent to the EVM, but not a zkEVM. There is a great deal of debate among Ethereum developers about the precise definition of zkEVM and the equivalence of its different levels of EVM. In fact, EVM equivalence is a range, and each level described above is not a strict category. The early nature of zkEVM development means that projects built for language-level compatibility may also offer some type of bytecode-level compatibility, and bytecode-level compatible zkEVMs may eventually evolve to have substantial consensus-level equivalence Mixed Rollups.
An overview of the zkEVM project on Ethereum
At present, there is no practical zkEVM that can achieve consensus-level compatibility, and developers are still researching and developing. Ethereum core developers describe it as "multi-year engineering efforts." Some zkEVMs have achieved equivalents at the language and bytecode levels, providing ideas for improving the current ZK Rollup Layer 2 ecosystem that is mainly application-centric on Ethereum. Building ZK Rollup to execute general smart contracts and user transactions rather than application-centric transactions is a daunting task, and only a handful of projects have successfully launched on mainnet so far.
Here is an overview of the five zkEVM projects on Ethereum:
zkSync 2.0
The blockchain development team Matter Labs was founded in December 2018 and launched their own ZK Rollups protocol called zkSync on Ethereum in June 2020. zkSync is the 6th largest L2 network on Ethereum by total locked value, supporting a limited range of smart contract operations, including low-gas transfers of ETH, ERC 20 tokens, and native NFTs, as well as atomic swaps and limit orders. The company recently raised $50 million in a Series B round led by Andreessen Horowitz and announced a $200 million treasury fund dedicated to expanding the zkSync ecosystem over the next few years.
zkSync 2.0 is a language-level compatible zkEVM designed to support all types of smart contract operations. zkSync 2.0 relies on a proof algorithm based on SNARKs called UltraPLONK. It also relies on an open-source compiler infrastructure called LLVM, which compiles Solidity and other types of programming languages into zkEVM bytecode. The project will begin its "baby Alpha" phase in October 2022 and is expected to be fully open to external users by the end of 2022, but the Matter Labs team has yet to disclose full details of zkSync 2.0 proof generation. Due to fierce competition among L2 networks, and due to the greater risk of technical vulnerabilities due to the initial stage of Rollup technology, most Rollup projects are run under high secrecy and do not support open source. Once successfully launched, zkSync 2.0 will be a way for users to choose to publish State deltas from their off-chain transactions to a separate protocol called zkPorter, rather than on-chain to Ethereum. This strategy would theoretically increase the transaction per second throughput of zkSync 2.0 from 2,000 TPS to over 20,000 TPS.
StarkNet
Like zkSync, StarkNet is a generic ZK Rollup built by the Starkware team that is already running on Ethereum. Starknet's transaction execution environment is called StarkNet OS, and its native smart contract programming language is called Cairo. Compared to other ZK Rollups, Starknet is one of the most fully functional blockchain networks. StarkNet provides users with an optional off-chain data solution to achieve exponentially lower transaction fees than non-Volitions-type Rollups. The StarkNet operating system relies on a proof algorithm based on STARKs. As with zkSync 2.0, the process of generating proofs on StarkNet OS is not open source. Similar to its competitor zkSync, over time the details around proof generation will be open-sourced so that anyone can connect to the network over a dedicated line.
StarkNet itself does not support language-level compatibility with the EVM, but the team behind Nethermind, an ethereum execution layer software client, is actively building a Solidity to Cairo language compiler called Warp. Using the Warp compiler, StarkNet users can deploy Ethereum-based smart contracts without having to rewrite the code in Cairo. Additionally, there is a community-driven project called Kakarot to build another Solidity-to-Cairo language compiler to help support StarkNet compatibility with the EVM.
The Starkware team announced the native StarkNet token and plans for the new foundation in July. The token distribution scheme became a source of controversy after it was revealed that a third of the initial 10 billion supply would be allocated to StarkNet core contributors. This year Starkware raised $100 million at an $8 billion valuation. The round was led by investment firms Greenoaks Capital, Coatue and Tiger Global. In addition to StarkNet, StarkWare also offers users a customizable blockchain scalability solution called StarkEx. The solution utilizes the new technology of ZK based on STARK. Unlike StarkNet, StarkEx is an application-centric ZK Rollup. Some notable DeFi applications using StarkEx to achieve greater scalability on Ethereum include soRare, Immutable, and DeversiFi.
Polygon zkEVM
The zkEVM (formerly Matic Network) built by the Polygon team achieves bytecode-level compatibility with the EVM. Polygon’s zkEVM is expected to launch on Ethereum sometime in early 2023, and it was recently open-sourced for public review. Of course while the code is publicly viewable, it cannot be used, modified or shared because it is not released under an open source license. Polygon's zkEVM implementation relies on proofs based on SNARKs and STARKs, specifically, zk-SNARKs are used to prove the correctness of zk-STARKs, which has the advantage of taking advantage of the fast proof times associated with zk-STARKs as well as generating zk-SNARKs Advantages of relatively light computing resources. Regarding the data availability issue, Polygon's zkEVM implementation will not immediately support off-chain data solutions, however, Polygon is actively working on developing applications with higher availability.
Founded in 2017, Polygon is a company mainly focused on Ethereum scaling solutions. It launched a proof-of-stake-based Ethereum sidechain called Polygon PoS in June 2020. Since then, Polygon's product plugins have grown significantly and become more diverse. In addition to the zkEVM implementation, Polygon is actively developing two other ZK Rollups implementations, Polygon Miden and Polygon Zero. They are a hybrid Rollups implementation combining Optimistic Rollup and ZK Rollup called Polygon Nightfall. Earlier this year, the Polygon team closed its first major funding round since its ICO and raised $450 million from 40 venture capital firms, led by Sequoia Capital India.
Scroll
Scroll is another zkEVM implementation that is compatible at the bytecode level. Scroll was founded in 2021 by Sandy Peng, Ye Zhang, and Haichen Shen, and in 2022 announced the launch of their pre- Alpha version testnet for whitelisted users. Notably, all code surrounding its zkEVM implementation is public and released under an open source license. Scroll will rely on a proof algorithm based on SNARKs and will not support off-chain data availability solutions. Additionally, the Scroll team is designing a decentralized marketplace for proof generation to support their zkEVM. In order to generate ZKPs in a permissionless and censorship-resistant manner, they are also focusing on building dedicated hardware facilities that can be run by users around the world.
The Scroll team works closely with the Ethereum Foundation's scaling solution research and development team, known as the Privacy Scaling Ethereum (PSE) team. Compared to other teams like zkSync, StarkWare, and Polygon, Scroll is smaller and more research-focused and less commercial. They are only focusing on their zkEVM implementation, while other competing teams have a suite of other ZK related products and services. Scroll raised $30 million in Series A funding this year from leading cryptocurrency venture capital firms like Polychain Capital and Bain Capital Crypto, as well as several angel investors including Ying Tong and Carlos Aria of the Ethereum Foundation people.
Privacy & Scaling Explorations (PSE)
PSE is a research institution of the Ethereum Foundation, focusing on exploring the cutting-edge research of ZKP and its application on Ethereum. They were formerly known as the "AppliedZKP" group. In contrast to other zkEVM implementations highlighted in this report, PSE's zkEVM is not focused on satisfying large-scale usage in the near future (practical components of PSE research are being implemented by the Scroll team). The zkEVM being researched by PSE focuses on achieving consensus-level compatibility with the EVM according to the "enshined Rollup" model.
The proof algorithm used in the PSE study is a zk-SNARK called Halo 2, which was developed by the Electric Coin Company, the core development team behind the Zcash (ZEC) cryptocurrency. The zkEVM implementation built by the PSE team is open source and anyone can contribute. In addition to zkEVM, the PSE team is advancing several other projects, including research on anti-collusion decentralized application infrastructure, enhanced user transaction privacy, and alternative cryptographic signature schemes.
Challenges of building zkEVM
There are some ongoing challenges in building a production-ready zkEVM implementation on Ethereum. The unproven and tested nature of implementing new technologies such as zkEVM, the decentralized operation of zkEVM, and building specialized hardware for generating zkEVM proofs is a major hurdle for developers. This section discusses some insights into these challenges.
New Field
zkEVM is a new concept on Ethereum, and it will only officially start running in 2022. A simple challenge with this technology is its unproven and large-scale tested nature. There are still a lot of unknowns about how most zkEVM implementations generate proofs, the hardware requirements for generating proofs, and the details of the decentralized sequencer. Building trust in zkEVM as a reliable scaling solution is an important area of focus for teams such as Scroll, Polygon, StarkNet, and zkSync.
The challenge of decentralization
The issues surrounding a decentralized path to zkEVM operations apply to all Rollup(including Optimistic Rollups), since the generation of validity and fraud proofs depends heavily on a centralized orderer. As mentioned above, sequencers are L2 stakeholders responsible for batching user transactions and submitting proofs of these batches to Ethereum L1.
Every Rollup currently running on Ethereum is operated by a centralized sequencer and relies on upgradable smart contracts governed by a single entity. One of the main reasons for the centralized nature of Rollup today: In the early days of the technology, unexpected bugs in the code required quick fixes. Additionally, the technology behind zkEVM in particular is constantly changing, making it difficult to confidently incentivize users to run this nascent technology on their devices. Implementing a decentralized orderer for Rollup typically means launching a token and creating a consensus protocol that organizes multiple orderers and provers in a permissionless manner. While launching tokens and creating consensus protocols is nothing new for public blockchains, it takes time and forethought to launch responsibly. StarkWare's token plans have caused controversy due to their supply design and initial distribution, and Polygon is also expected to improve the current token economics after its zkEVM launch. zkSync is expected to launch a token for its Rollup in the coming months, while plans for a Scroll token remain unclear.
In the current context of zkEVM, an important first step towards decentralization of the sorter is to open source the project software, which at the time of writing this article has very few people doing so. A Rollup zkEVM implementation that already has a large number of users may have an advantage in terms of decentralized zkEVM operations.
zkEVM Hardware Challenge
While zkEVM proofs are simple to verify, generating them is computationally intensive, in part because the mathematics behind ZKPs relies on linear sequences of computations. This makes it difficult to parallelize work to generate proofs on machines. Recent progress has been made in this direction using recursive proofs. Recursive proof is a technique to reduce the delay of proof generation, which refers to repeatedly generating proofs to further compress transactions, so that small batches of transactions on ZK Rollup can be processed in parallel. This is the technique StarkNet VM and Polygon's zkEVM use to generate validity proofs.
Since generating ZKPs is computationally intensive, zkEVMs may have to rely on advanced hardware such as graphics processing units (GPUs), field-programmable gate arrays (FPGAs), or even application-specific integrated circuits (ASICs). Specialized hardware is required to run the necessary computations to generate proofs, no different than specialized hardware is required to efficiently mine blocks according to the Proof-of-Work (PoW) consensus protocol. The difference in the growth of the two hardware industries lies in the selection process of provers and miners.
Provers are network stakeholders responsible for generating proofs of validity. On the other hand, the sequencer is responsible for ordering and packaging user transactions into batches and submitting the data to the layer-1 blockchain. Technically, the responsibilities of orderer and prover can be combined into one role. However, because both proof generation and transaction ordering require highly specialized skills to perform efficiently, splitting these responsibilities prevents unnecessary centralization in the Rollup function.
If the selection process of provers and orderers is similar to the selection process of miners, relying on achieving Nakamoto consensus and rewarding the most efficient hardware participants, then it is possible for the ZKP "mining" industry to follow the same path as Bitcoin mining. track development. However, there are several reasons why the selection process for a particular prover is more likely to be similar in design to Proof-of-Stake (PoS) rather than PoW consensus.
First, a Satoshi-style selection process means that the prover with the most efficient hardware will dominate the proof market. To avoid monopolizing the prover market while reducing power consumption, projects like Scroll are looking at alternative designs that require provers to stake assets as collateral, unlike the way Ethereum validators are required to stake 32 ETH . The implementation of the staking model ensures that the prover can be punished for actions that violate the security and liveness of the network, such as failing to compute a validity proof for a specified batch of transactions.
Another benefit of deterministically selecting provers to generate proofs, rather than having all provers compete to generate proofs, is improved transaction throughput and network scalability. Choosing a prover means that several provers can generate proofs for different batches of transactions in parallel, rather than all provers generating proofs for the same batch of transactions. However, leader election systems that rely on some form of staking and punishment have a weakness: complexity. Compared to Satoshi-style PoW systems, PoS systems rely on a more complex design of checks and balances to keep participants honest. For example, Nakamoto-style consensus typically only requires participants, the miners, to produce proofs of their work in order to be rewarded.
Most zkEVMs will likely try to minimize Rollup 's electricity usage by opting for a deterministic (assignment-based) rather than a probabilistic (competition-based) permissionless prover selection process. Ethereum co-founder Vitalik Buterin estimates that computing zkEVM proofs of validity requires less than 1% of the electrical energy used to mine ETH . The goal of the zkEVM designers was to reduce proof times as much as possible while making proof generation economically accessible to as many users as possible. One of the requirements to achieve a consensus-level compatible zkEVM is to reduce the proof generation time to be comparable to Ethereum L1's block time (average 13.5 seconds).
Only when the specification behind zkEVM becomes clear and standardized can ZKP hardware manufacturers truly grow and mature. Finally, predicting the electricity usage of the Validity Proof Computing industry will remain difficult unless Rollups adopts and implements a model for permissionless selection of provers and sequencers.
zkEVM Competitive Outlook
In the short term, zkEVM participants are competing to be the first project to launch on mainnet. However, in the long run, they will compete on EVM compatibility level (from language to consensus level) and VM efficiency. zkEVM will likely also have to compete with optimistic Rollups and other L2 scalability solutions for user acquisition once the technology behind zkEVM is more widely tested, used, and understood.
First-mover advantage and late-mover advantage
The zkEVM implementations of the zkSync, Polygon, and Scroll teams are racing to launch on mainnet. Launching the mainnet earlier could give it a first-mover advantage in attracting Rollup developers, which could be a particularly important advantage given the difficulty of interoperability between Rollups and composability of DApps. DApp composability, the ability to build DApps on top of DApps like building blocks, is a particularly important feature of the Ethereum Decentralized Finance (DeFi) ecosystem, making it more likely that DApp developers will be accepted by already widely adopted Attracted by L1 or L2.
On the other hand, due to the novelty of zkEVM as a technology, the first rollout implementations of zkEVM are unlikely to be optimized for Ethereum DApp developers. As mentioned in this report, a zkEVM implementation that is fully compatible with the EVM at the bytecode level and the consensus level is not yet ready for production use. A zkEVM implementation that more natively supports the deployment of Ethereum DApps may not be the first to launch, and a zkEVM with more EVM equivalents has the advantage of being a latecomer. The deeper the equivalence, the lower the barrier to entry for zkEVM developers. In other words, the more tools that the EVM, which has been the main DApp execution environment since 2015, can migrate to, the smoother the adoption of zkEVM DApp developers.
Attracting DApp developers through EVM equivalence is the first obvious area of competition between zkEVM implementations, and while the first-mover advantage for DApp developer adoption is strong, the technology is still in its infancy, so there is still significant iteration and improvement to be done space to build a production-ready zkEVM. Ultimately, the game resembles the innovator's dilemma from scratch: Is it better to be the first and try to build a layout and community, or is it better to be the second and overthrow the first mover with better features?
virtual machine design
Another area of competition and improvement for zkEVM over time is efficiency. As mentioned earlier, the EVM is not optimized for the ZK system, and building a general-purpose ZK Rollup can prove to be a significant overhead for Ethereum-based smart contracts and DApps. Over time, other virtual machine designs optimized for SNARK or STARK proofs may reduce EVM compatibility, a view strongly held by the Starkware team. Compiling Solidity to Cairo's Warp tool, and others like it, were community-driven initiatives, as the internal StarkWare team focused on making StarkNet's virtual machine as efficient as possible, rather than simply being EVM compatible.
On Ethereum, it is worth noting that the EVM (and associated Solidity) cannot be significantly changed or upgraded without breaking DApp backwards compatibility. Since the EVM was released in 2015, developers have tinkered with the EVM and its high-level programming language, Solidity, to improve usability and security in small ways. For example, during the 2019 Ethereum Istanbul hard fork upgrade, core developers added a new opcode called "CHAINID" to the EVM, which would return a unique identifier for the canonical chain. This is to prevent upgraded nodes from connecting to non-upgraded nodes by allowing nodes to check the CHAINID, which is a particularly useful upgrade to help prevent "replay attacks".
Ethereum core developers have been insisting that further upgrades to the EVM will still be made in Ethereum's development roadmap. New opcodes and precompilations will likely continue to be added to the EVM, suggesting that existing zkEVM implementations must be flexible to accommodate changes in the EVM. However, even with these improvements, L1 blockchains such as MINA, Sui, and Aptos still have the opportunity to experiment with different virtual machine and smart contract language designs, which may render the EVM obsolete in the long run. The zkEVM implementation mainly focuses on deep compatibility with EVM at the bytecode and consensus level, betting on the relevance and dominance of EVM in smart contract development for a long time.
Optimistic Rollups to ZK Rollups
In the end, it is not a foregone conclusion that the five zkEVM implementations discussed in this report beat Optimistic Rollups such as Optimism or Arbitrum. On a technical level, ZK Rollups are safer, more efficient, and potentially more cost-effective than optimistic Rollups. However, their flexibility in proving general-purpose computing designed for EVMs has not been tested and deployed at scale. Once zkEVM is launched and the technology behind it is more mature and robust, fraud proof-based Optimistic Rollups such as Optimism and Rollup may be upgraded and transitioned to generating validity proofs. Additionally, hybrid Rollup and multi-prover systems use fraud proofs to optimistically verify user transactions and issue validity proofs intermittently.
Gradually speeding up validity proof generation times will be an active area of research as the technology behind zkEVM evolves, and is being discussed in earnest today by Ethereum core developers like Vitalik Buterin and L2 developers like Optimism's Kelvin Fichter.
Rollup , which has already been launched on Ethereum, has a user base advantage and can theoretically be easily ported to a new upgraded version of Rollup , similar to Arbitrum Nitro, which will be launched in 2022. This may be one of the reasons why the zkEVM team (excluding Scroll) was hesitant to fully open-source their project token until their mainnet launch and build a large user base. The upgradability of optimistic Rollups to ZK Rollups over time shows that competition exists not only between zkEVM implementations, but also in the broader Ethereum L2 ecosystem.
in conclusion
The recent surge in market interest in zkEVM has raised several questions about the endgame of Ethereum’s scalability roadmap. In the truest sense, zkEVM (ZK Rollup with consensus-level compatibility with EVM) represents a long-term bet on EVM dominance while also betting on Ethereum as the primary platform for smart contract execution. zkEVM is also a long-term bet on Rollup ’s scalability roadmap, as it centers around abstracting transaction execution into Rollup rather than combining them with consensus and data availability.
Although several near-production-ready zkEVMs were announced this year, the technology is still in its infancy. Achieving zkEVM with consensus-level compatibility with the EVM is still a research project and may be years away from being ready for production. However, the same was true for zkEVM, which achieved bytecode-level compatibility with the EVM just a year ago. Rapid development of zkEVM implementations by Polygon, zkSync, StarkWare, and Scroll continues to push the boundaries of computer science and mathematics beyond expectations. The launch of Polygon zkEVM and zkSync 2.0 on Ethereum mainnet will be an important starting point for testing zkEVM with real user and DApp activity.
The availability and scalability of two production-ready zkEVMs may disrupt not only the zkEVM competitive landscape, but Optimistic Rollups and L1 competitive chains as well. If zkEVM is successful, Optimistic Rollups will have to convert to ZK Rollup designs to remain competitive in the long run. L1 altchains must also innovate in their virtual machine design to compete with scalable EVMs. Much remains to be proven about the readiness and applicability of ZKPs on Ethereum, and the launch of production-ready zkEVM should be seen as the start of a competitive landscape for this new technology.
Some areas of ongoing focus and development of zkEVMs include their hardware design and token economics. The hardware environment used to generate Rollup and which Rollups successfully decentralize proof generation remains to be seen. Much of this will come down to the community building of the respective teams, and the extent to which any of these Rollups can successfully attract DApps, especially Rollup DApps, to their networks at scale. These areas of development will take time and iterations to gradually hit the ground running. However, given the sophistication zkEVM is attempting to achieve on Ethereum, and their broad potential impact on the future of public blockchains, such developments will be closely watched by Ethereum stakeholders, researchers, cryptographers, and academics alike .
