zkEVMs: The Future of Ethereum Scalability

Introduction

Zero-knowledge Ethereum Virtual Machines (zkEVMs) are an ambitious and game changing technology for improving Ethereum scalability both in the short and long-term. This year, three major Ethereum scaling projects ­- zkSync, Polygon, and Scroll – have each announced major developments in their zkEVM implementations, many of which have launched in early alpha stages this year and operate today as their own independent Layer-2 (L2) blockchains. Over time, zkEVMs have the potential of being operated directly from the base layer of Ethereum.

As background, zkEVMs are virtual machines that can execute the same high-level programming languages or low-level bytecode as the Ethereum Virtual Machine (EVM) and prove this code using zero-knowledge proofs (ZKPs), cryptographic proofs that verify data without revealing any information about the data itself, such as its properties or content. ZKPs were first introduced as a concept back in 1982 by computer scientists Goldwasser, Micali, and Rackoff (Silvio Micali is the founder of the Algorand blockchain). ZKPs are often confused with homomorphic encryption, which is another branch of cryptography that allows operations to be performed on encrypted data without the need to unencrypt it. Homomorphic encryption schemes were first proposed in 1978 by Rivest, Adleman, and Dertouzos and have been one of the key technologies enabling cloud computing and storage. Notably, homomorphic encryption has also been used in some public blockchain protocols like the privacy coin Grin to obfuscate transaction amounts.

Over the last 40 years, computer scientists have invented several algorithms for securely and efficiently generating ZKPs, many of which fall under two broad categories: Scalable Transparent Arguments of Knowledge (STARKs) or Succinct Non-Interactive Arguments of Knowledge (SNARKs). These algorithms have been developed for a plethora of use cases including nuclear disarmament, identity authentications systems, and more recently via the advent of public blockchains and cryptocurrencies for achieving blockchain scalability. On Ethereum specifically, many developers consider ZKPs to be the “holy grail” of scaling due to the succinctness and easily verifiable characteristics of ZKPs compared to other cryptographic schemes for verifying transaction data. Being hard to construct or break but simple to verify is a common goal for developers of cryptographic protocols because allows for wide and efficient distribution.

For all the benefits of zero knowledge systems, they are notoriously difficult to generalize and apply to proving code of arbitrary complexity. Building ZKPs to natively support and prove all types of transaction activity on the Ethereum blockchain has been an ongoing research initiative by developers for the last few years. It was only in November 2021 that Starkware launched the first general purpose ZK system for proving Ethereum-based transactions. This was made possible through the creation of a custom programming language by the Starkware team known as Cairo. However, more recently, in July 2022, three different Ethereum-based, L2 protocols – zkSync, Polygon, and Scroll ­ – announced breakthroughs in leveraging ZKPs for scaling Ethereum in the form of zkEVMs.

Note: While colloquially called zkEVMs, these virtual machines do not take advantage of the privacy benefits of ZKPs and benefit exclusively from the security and efficiency benefits of ZKPs. Therefore, a more accurate name for these types of virtual machines is validity proof generating EVMs but for the purposes of this report, they will be referred to by their more popular name, zkEVMs.

This report aims to familiarize the reader with the general concept of zkEVMs as well as examine the various implementations in development on Ethereum. As zkEVMs are an advanced topic, this report begins by giving a brief overview of the Ethereum network as it stands today and lays the groundwork for understanding zkEVMs by introducing core concepts such as block production, the EVM, and rollups. Then, we will summarize the different types of zkEVMs that can exist on Ethereum and compare the 5 main zkEVM implementations in production currently. We will then highlight what challenges this nascent technology faces in implementation and our outlook on the competitive landscape for zkEVMs over time. Overall, zkEVMs remain in an early stage of development and adoption on Ethereum, though their potential to become the go-to scaling technology for L2 blockchains and ultimately the Ethereum protocol itself is high.

Ethereum as it is today

Before diving into the complexities of zkEVMs, it’s important to first understand at a high-level how transactions are included in blocks on Ethereum.

Block production

When a user submits a new transaction to Ethereum, computers connecting to the network, also called nodes, store the transaction in a local data structure called the mempool, which is responsible for maintaining a list of unconfirmed transactions. Then, validators who operate nodes and stake increments of 32 ETH as collateral to the network are selected at random to batch and process transactions from the mempool into blocks. The validator chosen to append a new block to the Ethereum blockchain is sometimes referred to as the “proposer.” Some proposers will rely on a third-party block builder instead of their local mempool when building a block to earn additional rewards from maximal extractable value (MEV). For more information about MEV, read this Galaxy Research report.

Blocks are organized sequentially and are linked together via the parent hash, the previous block’s header hash. Each block contains the previous hash of its parent block, chaining the blocks together and forming the blockchain data structure. The linking of blocks via the parent hash is displayed in the figure below:

Up until September 15, 2022, Ethereum relied on a proof-of-work (PoW) consensus mechanism where instead of validators, miners were responsible for block production and instead of expending large amounts of capital, miners were required to expend large amounts of electricity to process user transactions. For a full breakdown of the impacts of PoS on Ethereum, read Galaxy’s compendium of Merge research here.

The lack of scalability when it comes to the Ethereum blockchain under both a PoW and PoS consensus protocol is rooted in the issue of limited block space. Block space is measured on Ethereum in units of gas. Transactions requiring more computational effort to execute are generally priced in higher gas units while transactions with a lower computational cost (i.e., less resource intensive) have a lower gas cost. Gas is converted into ETH through a dynamic gas rate known as the base fee that is set automatically by the Ethereum network. The Ethereum protocol limits blocks so they can only contain up to 30 million units of gas. This maximum block gas limit preserves fast block propagation times and reduces the risk of chain splits. For more information about the fee dynamics of Ethereum, read this Galaxy Research report.

The Ethereum Virtual Machine

Once transactions are included in a block on Ethereum, these transactions are then executed through a custom runtime environment known as the Ethereum Virtual Machine (EVM). The EVM is designed to deploy code on Ethereum of arbitrary complexity. This is essentially what makes Ethereum a general purpose blockchain, also sometimes referred to as a Turing-complete system.

There are rules to the way the EVM executes transactions. First, the EVM compiles human readable programming languages like Solidity and Yul down to a machine-oriented or “low-level” language known as the EVM bytecode. The EVM then parses the bytecode into a list of sequential instructions known as “opcodes.” Each opcode commands the EVM to execute a different task and is represented in EVM bytecode in hexadecimal form. For example, the opcode that commands the EVM to hold on to transient data while a smart contract is being executed on-chain is represented mnemonically as “MSTORE” and in hexadecimal form as “0x52”. To help conceptualize opcodes for the reader, the following is a snapshot of simple opcodes defined in the Ethereum yellow paper:

Over the years, Ethereum developers have added new opcodes to the EVM. They have also added precompiles, which offer users the ability to execute more advanced operations on the network such as hashing functions and scalar multiplication. As the first runtime environment of its kind, the EVM has become widely adopted as the standard for smart contract deployment on general purpose public blockchains. However, being the first technology of its kind, the EVM does possess design limitations, the most relevant of which to this report is the EVM’s lack of compatibility with ZKPs.

Rollups all the way down

To improve the scalability of Ethereum, there are several L2 networks that abstract transaction execution away from the base layer to a rollup. Rollups compress transaction data such that the amount of block space needed to commit a batch of transactions to the base layer is significantly lower than confirming these transactions all individually through the mempool on-chain. Instead of validators or miners, rollups are operated by network operators known as “sequencers.” Sequencers are responsible for validating the state transition of a rollup. They are the entities that bundle user transactions into a rollup batch and then submit a proof for this batch of transactions to the base layer of Ethereum. The following is a diagram illustrating the role of sequencers in a rollup:

For the full overview of Ethereum’s L2 ecosystem, read this Galaxy research report.

Rollups differ 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 from Ethereum’s scalability roadmap. There are two main types of rollups: optimistic and zero-knowledge (ZK). Optimistic rollups rely on fraud proofs, meaning that changes to an L2 network’s state are published to Ethereum without direct proof of their validity. So long as there is at least one honest actor watching the state transitions of an optimistic rollup, invalid state transitions can be detected and cancelled. In the case of both Arbitrum and Optimism, the “challenge window” during which a fraud proof can be submitted lasts one week. Once the challenge window has ended, the state transition of an optimistic rollup is considered final and valid.

ZK rollups on the other hand rely on ZKPs, which generate validity proofs that are published to Ethereum every time a transaction batch is processed on the L2. The automatic generation of validity proofs for all transaction batches increases the security guarantees of a ZK rollup. It also means that funds from ZK rollups can be withdrawn every time a new validity proof is committed to Ethereum, while for optimistic rollups there is usually a waiting period of around 7 days to allow for disputes and fraud proof generation. ZK rollups also offer superior data compression than optimistic rollups. The following is a table summarizing the high-level difference between optimistic and ZK-rollups:

The main advantage of an optimistic rollup over a ZK rollup is that the virtual machine of an optimistic rollup is near identical to that of the EVM. The optimistic rollup implementations that are live on Ethereum today such as Optimism and Arbitrum mimic the same transaction execution environment as Ethereum and are referred to as the OVM and AVM respectively. Most ZK rollups are application-specific, meaning that 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 support specific types of payments, token swaps, and/or NFT minting.

Certain ZK rollups such as StarkNet are general-purpose, meaning they support all types of transactions and dapps. However, these ZK rollups require dapp developers to learn how to execute their smart contract code in a new custom execution environment that is optimized for generating ZKPs, instead of EVM compatibility. This presents a challenge for adoption of ZK rollups on Ethereum given the difficulty for existing decentralized applications and users to onboard to a new execution environment. To overcome this issue, ZK rollup projects such as Polygon Hermez, zkSync, and Scroll are working on a ZK rollup that achieves compatibility 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 not only differentiated by the type of proofs posted on-chain (a fraud proof in the case of optimistic rollups or a validity proof in the case of ZK rollups) but also by the rollup’s data availability strategy and proving algorithm.

As mentioned earlier in this report, there are two broad categories of validity proofs known as SNARKs and STARKs.

• SNARKs rely on elliptic curve cryptography which is a data encryption technique most popularly used in Bitcoin and Ethereum. SNARKs also generally rely on a trusted setup, which means that the algorithm requires a piece of data to be generated in advance by a trusted entity. The trusted setup ceremony is not a repeated event but rather a one-time procedure where a person or group of people generates the core data. This data is known as the common reference string (CRS), and it is a value that is then used in a zk-SNARK algorithm to generate trustworthy proofs. If the inputs that were needed to generate the CRS becomes compromised than this could lead to faulty proof generation. Therefore, it is important that the inputs for generating the CRS/SRS are destroyed by all ceremony participants or made irretrievable after the ceremony is complete. Some examples of SNARK-based algorithms include Sonic, Plonk, Redshift, and Marlin.

• STARKs on the other hand do not rely on elliptic curves or a trusted setup. STARKS rely on hash functions, which some developers see as advantageous for being quantum resistant cryptography. STARKs however are more complex and require more computing resources to run. They were also introduced later than SNARKs in 2018, whereas SNARKs have been around since 2012. For these reasons, SNARKs are more widely used than STARKs as a proving algorithm. Some examples of STARK-based algorithms include Fractal, SuperSonic, Fri-STARKs, and genSTARK.

In addition to differing methods for generating a validity proof, ZK rollups can differ by their data availability strategy, meaning their strategy for what components of a transaction batch are ultimately posted on-chain. Rollups, both optimistic and ZK, usually commit three pieces of data to mainnet Ethereum every time a batch of transactions is processed. First, validators of the rollup will submit the root hash of the new network state to Ethereum. (State refers to the updated record of transactions and account balances on the L2.) The state is recorded in a Merkle tree data structure, as shown below:

The root hash is a cryptographic commitment of the entire Merkle tree and is sometimes referred to as a state commitment. It is not a requirement that all ZK rollups commit the root hash to Ethereum, but it is common that they do for the purposes of easily reconstructing and verifying transactions executed on a rollup using data posted on Ethereum.

In addition to the high-level root hash, confirming the new state of the Layer 2 blockchain, a cryptographic proof is also recorded on Ethereum. This proof can be a ZKP or a fraud proof in the case of optimistic rollups. It can be generated through a STARK or SNARK algorithm. Finally, in addition to these two pieces of data, ZK rollups post a compressed version of batched transactions, also called the state delta, to Ethereum. State delta is a cost-effective way to commit large amounts of transaction data to Ethereum that is unique to ZK rollups. Optimistic rollups, in lieu of state delta, use other data compression techniques to batch transactions and commit them on-chain.

(As a side note, certain ZK rollups projects such as the Scroll team do not actually rely on the additional data compression gains from posting state delta to Ethereum. In the minds of Scroll developers, upcoming code changes such as Ethereum Improvement Proposal 4844 and danksharding will significantly reduce costs of committing transaction data to Ethereum such that the efficiency gains from state delta over other data compression tricks will be negligible.)

Using data from the lowest level of the Merkle tree, which are the leaves, and combining it with the root hash from the highest level of the Merkle tree, the root, allows anyone to reconstruct and verify the contents of transaction batches committed on-chain. A defining characteristic of most rollups is the ability to recreate transactions executed on a Layer-2 network using the data committed on-chain to Ethereum. However, certain rollups avoid committing state delta or other compressed transaction data to Ethereum and instead posts the data elsewhere to reduce operational costs and increase network scalability. Certain developers will argue Layer-2 networks that avoid committing transaction data to Ethereum and thereby break the guarantee of transaction reconstruction should not be classified as a rollup.

The way a rollup handles state delta is what determines whether the network can be classified as validium or a volition.

• Validiums are best understood as rollups that only commit the validity proof and root hash on-chain while storing the state delta off-chain on a separate network. This theoretically increases the transaction throughput of a rollup to 9,000 TPS as the rollup is no longer reliant on Ethereum for data availability and constrained by the network’s block space. The downside of validiums is security. The separate network for posting off-chain data does not inherit the same security guarantees as Ethereum.

• Volitions, on the other hand, leave the decision of posting state delta off-chain or on-chain up to the user. They were first pioneered by Ethereum scaling startup Starkware. It is a novel way of letting users decide whether their transactions require enhanced security at perhaps a greater cost by confirming directly on-chain to Ethereum or to an off-chain network such as Starkware’s trusted Data Availability Committee (DAC).

The 4 main levels to EVM equivalence

Give the above framework for understanding transaction execution on Ethereum, the EVM, and ZK rollups, we can now discuss zkEVMs. zkEVMs are a type of ZK rollup that mimics the same transaction execution environment as mainnet Ethereum. Implementation of zkEVMs differ in their proving algorithms, as well as data availability strategy. zkEVMs also differ in their level of EVM-equivalence. There are four main levels of EVM-equivalence. The following is a high-level summary of the different levels:

Language level equivalence

To achieve language-level EVM-equivalence, zkEVMs must be able to understand and natively compile EVM-friendly languages. In other words, these types of zkEVMs can translate EVM-friendly programming languages such as Solidity or Yul into a custom-built language optimized for generating ZKPs. This is thought to be one of the easiest and most efficient ways to achieve EVM compatibility within 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 high-level programming language of the EVM to a custom-built, low-level language that can be interpreted by a virtual machine designed for producing ZKPs. For most users and smart contract developers on Ethereum who only care about interactions with the EVM through Solidity code, the underlying behavior of a zkEVM may not matter so long as the same type of code can be executed through the zkEVM as on Ethereum mainnet. On the other hand, sophisticated developer tooling, frameworks and testing environments built for the EVM will likely require modification to use on a zkEVM that only has language-level EVM compatibility.

Bytecode level equivalence

The second and third levels of EVM-equivalence are the bytecode-level, which requires a ZK rollup to be able to interpret EVM bytecode compiled down from a higher-level language (e.g. Solidity or Yul). zkEVMs that can mimic the same high-level programming language of the EVM and the low-level bytecode achieve a deeper level of compatibility with the EVM. These types of zkEVMs are more complex to build because they require more advanced engineering.

As discussed earlier in this report, the way EVM bytecode is executed by virtual machines is through a specific list of instructions called opcodes. Each opcode commands the EVM to execute a different task. The goal of a bytecode-compatible zkEVM is to create a ZK system that can prove EVM bytecode and parse through the various opcodes that bytecode contains. The advantage of these types of zkEVMs is their compatibility with EVM-based applications and tooling. A fully bytecode compatible zkEVM would be able to support the same debugging tools and developer infrastructure as native Ethereum-based applications. However, achieving full bytecode compatibility often has the negative outcome of creating an inefficient and costly ZK system. To reduce costs and improve efficiency, partially bytecode compatible zkEVMs may remove certain features of the EVM such as precompiles that are harder to prove using ZK math and cryptography.

At present, there are two bytecode compatible zkEVMs, the Polygon zkEVM and the Scroll zkEVM. Both will be discussed in more detail later in this report. In their current design, these two implementations are only partially compatible with the EVM bytecode. However, these implementations are working towards full compatibility over time.

Consensus level equivalence

The fourth and final level of EVM-equivalence is at the consensus level. This is the highest of native compatibility to the EVM that ZK rollups can achieve. It is sometimes referred to as “enshrined rollups,” though not all enshrined rollups need to be ZK-based but could be an optimistic rollup. The idea is that the cryptographic proofs generated by a zkEVM do not need to be re-executed on Ethereum in any capacity. The proofs themselves can be used to validate blocks produced on mainnet Ethereum. In a sense, zkEVMs that achieve consensus level compatibility are the truest form of zkEVMs.

To some developers, ZK rollups that can achieve consensus level compatibility are the only type of ZK rollups that should be called zkEVMs, while the other ZK rollups with language and bytecode compatibility should be considered EVM-compatible and EVM-equivalent, respectively, but not a zkEVM. There is a significant amount of dispute between Ethereum developers about the precise definition of zkEVMs and their varying levels of EVM equivalence. In truth, EVM-equivalence is a spectrum and every single one of the levels described above are not rigid categories. The early nature of zkEVM development means that projects building for language level compatibility may also offer some type of bytecode level compatibility and bytecode level compatible zkEVMs may eventually develop to be a hybrid rollup with come amount of consensus level equivalence.

In the next section of this report, we will take a deeper look at the five zkEVM implementations currently under production on Ethereum.

Overview of zkEVM projects on Ethereum

At present, no zkEVM implementation that is close to production-ready can achieve consensus level compatibility. This is an ongoing area of research and development that has been described by Ethereum core developers as a “multi-year engineering effort.” However, there are implementations that achieve equivalence on both the language and bytecode level, which still offers an improvement to the current ZK rollup Layer 2 ecosystem on Ethereum, which is mostly application focused. Building a ZK rollup to execute general smart contracts and user transactions instead of application-focused transactions is a difficult task that so far, only a handful of projects have successfully launched on mainnet.

The following is a high-level overview of the five zkEVM projects on Ethereum:

zkSync 2.0

Matter Labs is a blockchain engineering team that was founded in December 2018. The team launched their own ZK rollup protocol on Ethereum known as zkSync in June 2020. zkSync is the 6th largest L2 network on Ethereum by total value locked and supports a limited range of smart contract operations including low gas transfers of ETH, ERC20 tokens, and native NFTs, as well as atomic swaps and limit orders. The company recently raised $50mn through a Series B funding round led by Andreessen Horowitz and has announced a $200mn treasury fund dedicated to expanding the zkSync ecosystem in the coming 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 SNARK-based proving algorithm known as UltraPLONK. It also relies on an open-source compiler infrastructure known as the LLVM to compile Solidity and other types of programming languages into zkEVM bytecode. The project launched in a “baby alpha” phase in October 2022 and is expected to open fully for external users by the end of 2022, although the full details on proof generation on zkSync 2.0 remain undisclosed by the Matter Labs team. (Due to fierce competition between L2 networks and due to the nascency of rollup technology creating greater technical risks for bugs, most rollups projects operate with a high-level of secrecy and do not subscribe to an open-source process for development.) Once launched, zkSync 2.0 will be a volition, giving the optionality for users to post state delta from their transactions off-chain to a separate protocol known as zkPorter instead of on-chain to Ethereum. This strategy would theoretically boost the transactions per second throughput of zkSync 2.0 from 2,000 TPS to over 20,000 TPS.

StarkNet

Like zkSync, StarkNet is a general purpose ZK rollup already live on Ethereum built by the Starkware team. Starknet’s transaction execution environment is called the StarkNet OS and its native smart contract programming language is called Cairo. Compared to other ZK rollups, Starknet is one of the fullest featured. StarkNet offers users an optional off-chain data solution (making the rollup a volition) for achieving exponentially lower transaction fees than a non-volition type rollup. The StarkNet OS relies on a STARK-based proving algorithm. Like zkSync 2.0, the process for generating proofs on StarkNet OS is not open-sourced. Similar to its competitors like zkSync, open sourcing the details around proof generation over time so that anyone can connect to the network, run specialized hardware, and earn rewards for generating proofs is part of the rollup’s long-term development roadmap.

StarkNet does not natively support language-level compatibility with the EVM. However, there is a Solidity to Cairo language compiler called Warp actively being built by the team behind Nethermind, an Ethereum execution layer software client. Using the Warp compiler, StarkNet users can deploy Ethereum-based smart contract without having to rewrite their code in Cairo. In addition, there is a community driven project called Kakarot to build another Solidity to Cairo language compiler to help support StarkNet’s compatibility with the EVM.

The Starkware team unveiled in July their plans to launch a native StarkNet token and a new foundation. The proposed distribution for the token became a source of controversy after it was revealed that one-third of the initial 10bn supply would be allocated to StarkNet core contributors. This year, Starkware as a company raised $100mn at a $8bn valuation. The round was led by investment firms Greenoaks Capital, Coatue, and Tiger Global. In addition to StarkNet, StarkWare offers users a customizable blockchain scalability solution known as StarkEx that leverages the company’s novel STARK-based ZK technology. Unlike StarkNet, StarkEx is a ZK rollup that is application focused. Some of the noteworthy DeFi applications that use StarkEx for greater scalability on Ethereum include soRare, Immutable, and DeversiFi.

Polygon zkEVM

The zkEVM implementation built by the team at Polygon, formerly known as the Matic Network, achieves bytecode level compatibility with the EVM. Polygon’s zkEVM is expected to launch on Ethereum sometime in early 2023 and has recently been open sourced to the public for review. (It is important to note that while the code is publicly available to view, it cannot be used, modified, or shared as it was not published under an open-source code license.) Polygon’s zkEVM implementation relies on both SNARK and STARK-based proofs. Specifically, zk-SNARKs are used to attest to the correctness of zk-STARKs. This has the advantage of leveraging the fast-proving times associated with zk-STARKs coupled with the comparatively light computational resources required to generate zk-SNARKs. On the topic of data availability, Polygon’s zkEVM implementation will not immediately support an off-chain data solution. However, Polygon is actively working towards making their zkEVM implementation a volition through the development of Polygon Avail.

Founded in 2017, Polygon is a company that focuses primarily on different scaling solutions for Ethereum. It launched a proof-of-stake based sidechain of Ethereum known as Polygon PoS in June 2020. Since then, the product suite of Polygon has grown and diversified significantly. In addition to the company’s zkEVM implementation, it is actively developing two other ZK rollup implementations, Polygon Miden and Polygon Zero, as well as a hybrid rollup implementation that marries both optimistic and ZK rollups called Polygon Nightfall. Earlier this year, the Polygon teamed closed their first major financing round since their initial coin offering of the MATIC token and raised $450mn from 40 venture capital firms. The round was led by Sequoia Capital India.

Scroll

Scroll is another bytecode level compatible zkEVM implementation. Scroll was founded in 2021 by Sandy Peng, Ye Zhang, and Haichen Shen, who announced in 2022 the launch of their pre-alpha version testnet for whitelisted users. Notably, all the code surrounding their zkEVM implementation is public and published under an open-source license. Scroll will rely on a type of SNARK-based proving algorithm and will not support an off-chain data availability solution. In addition, the Scroll team is designing a decentralized marketplace for proof generation to support their zkEVM. To this end, they are also focusing on building specialized hardware that can be run by users around the world to generate ZKPs in a permissionless and censorship resistant way.

The Scroll team works in close collaboration with the Ethereum Foundation’s research and development team for scaling solutions, known as the Privacy Scaling Ethereum (PSE) team. The PSE’s work on zkEVMs will be discussed in the next section of this report. In comparison to the other teams like zkSync, StarkWare, and Polygon, Scroll is smaller, and more research focused (i.e., less commercially oriented). They are also solely focused on their zkEVM implementation whereas other competing teams have a suite of other ZK-related products and services. Scroll raised $30mn in a Series A funding round this year from the likes of leading crypto VC firms including Polychain Capital and Bain Capital Crypto, as well as several angel investors including the Ethereum Foundation’s Ying Tong and Carlos Aria.

Privacy & Scaling Explorations (PSE)

PSE is a research arm of the Ethereum Foundation that is focused on exploring cutting edge research in ZKPs and their applications on Ethereum. They were formerly called the “AppliedZKP” group. In contrast to the other zkEVM implementations highlighted in this report, PSE’s zkEVM is not focused on becoming production-ready in the near future (the production-ready components of PSE’s research are being implemented by the Scroll team). The zkEVM being researched by PSE is focused on achieving consensus-level compatibility with the EVM according to an enshrined rollup model.

The proving algorithm being used in PSE’s research is a zk-SNARK known as Halo2, which was developed by the Electric Coin Company, the core development team of the Zcash (ZEC) cryptocurrency. The development of the zkEVM built by the PSE team is open source and anyone can participate. Along with zkEVMs, the PSE team is advancing several other projects including research for anti-collusion decentralized application infrastructure, enhanced privacy for user transactions, and alternative cryptographic signature schemes. For the full list of project PSE is working on click here.

Challenges to building zkEVMs

There are several ongoing challenges as it relates to building production-ready zkEVM implementations on Ethereum. The unproven and untested nature of implementing a new technology like zkEVMs, decentralizing operations of a zkEVM, and building specialized hardware for producing zkEVM proofs are hurdles that developers face. This section gives some insight into these challenges.

Novelty

zkEVMs are a novel concept on Ethereum and work has only begun in earnest in 2022. One of the simple challenges for this technology is its unproven and untested nature at scale. There remains a great deal of secrecy between most zkEVM implementations in the way proofs are generated, the hardware requirements to produce proofs, and the details around decentralizing sequencers. Building trust in zkEVMs as a reliable scalability solution is an important area of focus for teams like Scroll, Polygon, StarkNet, and zkSync.

Decentralization challenges

Questions around the path forward to decentralize the operations of a zkEVM are broadly applicable to all rollups (including optimistic rollups) as both validity and fraud proof generation depends heavily on centralized sequencers. As explained above, sequencers are the L2 stakeholders responsible for batching user transactions and committing the proofs for these batches to the L1 of Ethereum.

Each rollup that is currently live on Ethereum is operated by a centralized sequencer and relies on upgradeable smart contracts managed by a single entity. A primary reason for the centralized nature of rollups today is due to nascency of the technology and the need for making quick fixes in the event of unexpected bugs in code. In addition, the technology behind zkEVMs in particular is in flux, making it difficult to confidently incentivize users to run the nascent technology on their own devices. Decentralizing sequencers for a rollup usually means launching a token and fleshing out a consensus protocol for organizing multiple sequencers and provers in a permissionless way. While the challenges of launching a token and creating a consensus protocol are not novel to public blockchains, they take time and considerable deliberation to launch responsibly. StarkWare’s announced token plans were a source of controversy due to the design and initial distribution of supply, while Polygon is expected to revamp the tokenomics of its existing MATIC token following the launch of their zkEVM. zkSync is also expected to launch a dedicated token for their rollup in the coming months, while Scroll’s plans for launching a token remain unclear.

An important first step in the context of zkEVMs for the decentralization of sequencers is open sourcing project software, which few have done at the time of writing. zkEVM implementations that can rely on a large community of pre-existing users for their rollup are likely to have the advantage when it comes to decentralizing zkEVM operations.

zkEVM hardware challenges

While zkEVM proofs are trivial to verify, they are computationally intensive to generate in part because the math behind ZKPs rely on a linear sequence of computations. This makes parallelizing the work to generate the proofs on a machine difficult. There have been advancements recently on this front with the use of recursive proving. Recursive proving is a technique for reducing latency in proof generation. It refers to repeatedly generating a proof of a proof to further compress transactions and thereby make it possible to process small batches of transactions on a ZK-rollup in parallel. This is a technique used to generate validity proofs by the StarkNet VM and Polygon’s zkEVM.

Due to the intensive nature of the computation required to generate a ZKP, zkEVMs will likely have to rely on advanced hardware such as graphics processing units (GPUs), field programmable gate arrays (FPGAs), and even application specific integrated circuits (ASICs). The need for specialized hardware to run necessary computations for proof generation is not unlike the need for specialized hardware to efficiently mine blocks under a proof-of-work (PoW) consensus protocol. What differentiates the growth of these two hardware industries is the selection process for provers versus miners.

Provers are the network stakeholders tasked with the responsibility of generating validity proofs. On the other hand, sequencers are responsible for the ordering and packaging of user transactions into a batch and committing data down to a Layer-1 blockchain. Technically, the responsibilities of sequencers and provers could be combined into one role. However, because proof generation and transaction ordering each require highly specialized skills to perform well, splitting these responsibilities prevents unnecessary centralization in a rollup’s function.

If the selection process for provers and sequencers is anything like the selection process for miners, which relies on achieving Nakamoto consensus and rewards the participants with the most efficient hardware, there is the potential for a ZKP “mining” industry to develop along the same trajectory as Bitcoin’s PoW mining industry. However, there are a few reasons why the selection process for provers in specific is more likely to be a deterministic process similar in design to proof-of-stake (PoS) rather than Nakamoto-style PoW consensus.

First, using a Nakamoto-style selection process for provers means that the prover with the most efficient hardware will dominate the proving market. To avoid the monopolization of the prover market, as well as the duplication of electricity usage by provers, projects like Scroll are looking into alternative designs for prover selection that requires provers to stake assets as collateral, not unlike the way Ethereum validators are required to stake a balance of 32 ETH. The implementation of a staking model ensures that provers have skin in the game that can be penalized for behavior that undermines network security and liveness such as failing to compute a validity proof for an assigned batch of transactions. It is important that the incentives for rewarding and penalizing provers are balanced with the model for selecting sequencers on a ZK-rollup so that there is sufficient participation by network stakeholders for fulfilling both responsibilities.

Another benefit for deterministically electing provers to generate proofs rather than having all provers generate proofs in competition is the possibility of increased transaction throughput and network scalability. Electing provers means that several could be generating proofs for different batches of transactions in parallel rather than all provers generating proofs for the same batch of transactions. However, one of the weaknesses of a system for leader election that relies on staking and slashing in some form is complexity. Compared to Nakamoto-style PoW systems, PoS systems rely on a more intricate design of checks and balances to keep participants honest. For example, Nakamoto-style consensus often only requires participants, that is miners, to generate a proof of their work to earn rewards. Deterministic PoS systems can require much more from participants, often called validators, such as depositing assets, delegating assets, voting on transactions and blocks, proposing blocks, and monitoring the behavior of other validators.

It is likely that most zkEVMs will try to minimize electricity usage of their rollup by opting for a permissionless prover selection process that is deterministic (based on assignment) rather than probabilistic (based on competition). Ethereum co-founder Vitalik Buterin estimates that computing validity proofs for zkEVMs will require less than 1% of electricity used to mine ether under a PoW consensus protocol. The goal for zkEVM designers is to reduce proof times as much as possible while also keeping proof generation economically accessible for as many users as possible. One of the requirements for achieving a consensus-level compatible zkEVM is to reduce proof generation times to be equivalent to that of Ethereum Layer 1 block times (13.5 seconds on average).

Only once the specifications behind zkEVMs become clear and standardized can ZKP hardware manufacturers grow and mature in earnest. Finally, predicting the electricity usage of the validity proof computation industry will remain difficult until rollups adopt and implement a model for permissionlessly selecting provers and sequencers.

Outlook on zkEVM competition

In the short-term, zkEVMs are competing to be the first to launch on mainnet. However, long-term, they will compete in terms of their level of EVM compatibility (from language to consensus level) and VM efficiency. Once the technology for enabling zkEVMs becomes more widely tested, used, and understood, it is likely zkEVMs will also have to compete with optimistic rollups and other L2 scalability solutions for user adoption.

First and second-mover advantages

zkEVM implementations by the zkSync, Polygon, and Scroll teams are racing to be the first to launch on mainnet. The advantage of launching first on mainnet comes down to gaining a lead over other zkEVM implementations in attracting dapp developers. This may be an especially important lead to gain given that interoperability and dapp composability between rollups is difficult. Dapp composability refers to the ability to build dapps on top of dapps like building blocks and is an especially important feature of Ethereum’s decentralized finance (DeFi) ecosystem that makes dapp developers more likely to gravitate towards the L1 or L2 that already have the most amount of adoption.

On the other hand, due to the novelty of zkEVMs as a technology, the first zkEVM implementations to launch are unlikely to be most optimized for Ethereum dapp developers. As mentioned in this report, zkEVM implementations that are fully compatible with the EVM on a bytecode level and consensus level are not ready for production. zkEVM implementations that can support Ethereum dapp deployment more natively may not launch first and instead have the second-mover advantage of being more EVM-equivalent. The deeper the level of equivalence, the easier the developer onboarding experience for a zkEVM. In other words, the more tooling that can be transferred from the EVM which has been the execution environment for major dapps since 2015, the better in terms of zkEVM dapp developer adoption.

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 so nascent that there is still room for significant iterations and improvements to be made when it comes to building a production-ready zkEVM. Ultimately, the game resembles the innovators dilemma from scratch – is it better to be first and attempt to establish distribution and community, or be second and overthrow the first mover with better features?

VM design

One of the other areas of competition and improvement for zkEVMs over time is efficiency. As discussed, the EVM is not optimized for ZK systems, and building a general ZK rollup that can prove Ethereum-based smart contracts and dapps entails significant overhead. It is possible other VM designs optimized for SNARK or STARK proofs make EVM compatibility less desirable over time, a viewpoint that is strongly held by the team at Starkware. The Warp tool, which compiles Solidity to Cairo, and others like it are community-driven initiatives because the internal StarkWare team is focused exclusively on making StarkNet’s VM as efficient as possible instead of simply EVM compatible.

On Ethereum, it’s worth noting that the EVM (and by association Solidity) can’t be altered or upgraded significantly without breaking backwards dapp compatibility. Since the EVM’s release in 2015, developers have tinkered with both the EVM and its high-level programming language Solidity to improve usability and security in minor ways. For instance, in 2019 during Ethereum’s Istanbul hard fork upgrade, core developers added a new opcode to the EVM called “CHAINID” which would return the unique identification number of the canonical chain. This was meant to prevent upgraded nodes from connecting to non-upgraded nodes by allowing nodes to check the CHAINID, a particularly useful upgrade to help protect from “replay attacks,” in which malicious actors can exploit poor node discovery.

Ethereum core developers have been adamant that further changes to the EVM are still to come in the development roadmap of Ethereum. New opcodes and precompiles are likely to continue to be added to the EVM, which suggests that existing zkEVM implementations must be flexible adapting to changes in the EVM. However, even with these improvements, there is still an opportunity for alternative Layer 1 blockchains such as Mina, Sui, and Aptos, to experiment with different VM designs and smart contract language designs which over the long-term may make the EVM obsolete. zkEVM implementations focused primarily on deep compatibility with the EVM on a bytecode and consensus level are making a long-term bet on the relevance and dominance of the EVM for smart contract development.

Optimistic rollups transitioning to ZK rollups

Finally, it is not a forgone conclusion that the five zkEVM implementations discussed in this report beats out optimistic rollups such as Optimism or Arbitrum. On a technical level, ZK rollups are more secure, efficient, and have the potential to be more cost-effective than optimistic rollups. However, their flexibility in terms of proving general computations designed for the EVM is not tested and widely deployed at scale. Once zkEVMs are launched and the technology behind them is more mature and robust, it is possible that fraud-powered optimistic rollups such as Optimism and Arbitrum upgrade and transition to generating validity proofs. In addition, hybrid rollups and multi-prover systems that optimistically verifies user transactions using fraud proofs and publishes validity proofs intermittently, gradually speeding up validity proof generation times as the technology behind zkEVM matures is an active area of research that is being discussed in earnest today by the likes of Ethereum core developers like Vitalik Buterin and L2 developers like Optimism’s Kelvin Fichter.

Rollups that have already launched on Ethereum have the advantage of pre-existing userbases that could theoretically be easily ported over to a new upgraded version of the rollup similarly to how Arbitrum Nitro was launched in 2022. This possibility may be one of the reasons why teams behind zkEVMs (excluding Scroll) are hesitant about fully open sourcing their project’s code until their mainnet launch and until after their rollup has built up a sizable userbase to compete with the network moats of other pre-existing rollups. The upgradeability of optimistic rollups to ZK rollups over time suggests that zkEVM implementations are not only competing amongst each other but in the context of the broader L2 ecosystem of Ethereum.

Conclusion

The recent explosion of interest in zkEVMs has raised several questions about the endgame for Ethereum’s scalability roadmap. In the truest sense, zkEVMs (ZK rollups with consensus level compatibility to the EVM) represent a long-term bet on the dominance of the EVM and, by association, Ethereum as the primary platform for smart contract execution. zkEVMs are also a long-term bet on the scalability roadmap for Ethereum as one centered on rollups and the abstraction of transaction execution into a rollup instead of being coupled with consensus and data availability.

Despite the announcement of several near-production ready zkEVMs this year, the technology is still extremely nascent. Achieving a zkEVM with consensus-level compatibility with the EVM remains a research initiative that is likely years away from being ready for production. However, the same was said for zkEVMs that achieve bytecode-level compatibility with the EVM just a year ago. The rapid development of zkEVM implementations by Polygon, zkSync, StarkWare, and Scroll continues to push the boundaries in computer science and mathematics and has defied expectations. The launch of both the Polygon zkEVM and zkSync 2.0 on Ethereum mainnet will be an important starting point for testing zkEVMs with real user and dapp activity.

The usability and scalability of two production-ready zkEVMs is likely to disrupt the competitive landscape of not just zkEVM protocols, but also that of optimistic rollups and alternative L1 blockchains. If zkEVMs are successful, optimistic rollups will have to convert into a ZK rollup design to remain competitive over the long-term. Alternative L1 blockchains will also have to innovate on their VM designs to compete with that of a scalable EVM. There is still much to be proven about the readiness and applicability of ZKPs on Ethereum and the launch of production-ready zkEVMs should be considered just the beginning of the competitive landscape for this novel technology.

A few areas of continued concern and development for zkEVMs include their hardware design and tokenomics. Both the hardware landscape for generating ZKPs and which rollup succeeds in decentralizing proof generation remains to be seen. Much of this will come down to community building by the individual teams and the extent to which any of these rollups can succeed in sparking a mass migration of dapps, especially DeFi dapps, onto its network. These areas of development will take time and iterating to get right. However, given the advanced nature of what zkEVMs are trying to accomplish on Ethereum, and their potential impact on the future of public blockchains broadly, the progress will be closely watched by Ethereum stakeholders, researchers, cryptographers, and academics alike.