Author: Grant Griffith
Original title: The Race for zkEVMs Explained
When it comes to scaling Ethereum via rollups, the advent of zero-knowledge (ZK) rollups, especially EVM-compatible ZK-rollups (zkEVMs), is often considered the holy grail. While were not quite there yet in terms of development, there has been an uptick in innovation in various projects lately, making things that are years away seem within reach. The race for zkEVMs is now on, and this article examines which early adopters are able to successfully implement zkEVM at scale and gain an advantage in terms of early user adoption.
First, please note that this article is not an introductory article on rollup. Therefore, if you are not familiar with the Rollups situation on Ethereum and the general advantages/disadvantages of using ZK-rollup in particular, I recommend reading this article first, which details the basics (A Comprehensive Guide for Those With “Zero Knowledge ” on Rollups).
Keeping the above in mind, lets quickly remind ourselves why ZK-rollups are often favored over optimistic rollups. While both forms of rollups offer huge improvements in scalability and throughput, ZK-rollups offer advantages in transaction finality (no challenge period) and security. For the latter, ZK-rollups are generally considered more secure, as they rely on trustless cryptography for security, rather than relying on the honesty of other participants to submit fraud proofs. Of course, optimistic rollups have their special benefits, like not requiring complex computations on specialized machines to generate proofs (which has its costs), but these are key things to be aware of, other things being equal.
Between the two forms of rollups, only optimistic rollups are generally EVM compatible, making optimistic rollups more popular in terms of total value locked (TVL).
EVM compatibility and equivalence explained
I find the concept of the EVM and the compatibility of its various forms to be one of the most overlooked and misunderstood topics in the field. The term is thrown around so often that youd think everyone understands the ins and outs, but that most likely isnt the case.
Public, universal rollups often share a common goal of getting developers and users on board as quickly as possible to generate network effects in terms of adoption. In short, the argument is that EVM compatibility helps facilitate new blockchain networks/rollups. Lets explore how and why.
EVM (Ethereum Virtual Machine)
First, what is EVM? The full name of EVM is Ethereum Virtual Machine, which is essentially a software platform.
At a high level, remember that for a blockchain, there can only be one canonical state (similar to a balance sheet) at any given time. This state includes all accounts, balances, etc. in the blockchain at a specific moment. In the case of Ethereum, the EVM partially acts as a large database to hold all this data.
However, the EVM also plays a more dynamic role. The state of Ethereum is not only a large data structure holding all accounts and balances, but also the so-called machine state, which can change from one block to another according to a set of predefined rules. These rules, are defined by the EVM - so any smart contract that wants to execute a transaction on Ethereum, if it is not written according to the EVM, will not be processed. Not only that, but as the records of the Ethereum blockchain change with each allowed transaction, the EVM keeps track and calculates the new state of the network (thus acting as both a gatekeeper and a real-time registrar). Lets look at an example here to help illustrate.
image description
Image credit: Reddit blog post
Therefore, the EVM can almost be considered the lifeblood of Ethereum. By interpreting/executing smart contracts and responding to smart contract input data to calculate the state of the Ethereum network from one block to another, it defines the rules that can be processed and updates the network state in real time.
EVM Compatibility
image description
Image Credit: GoCrypto Blog
EVM compatibility has to do with how smart contracts for a particular blockchain are written and deployed. If a blockchain is considered EVM compatible, it means that its smart contracts are written in a way that complies with the specific specifications and rules of the EVM.
EVM compatibility has to do with how smart contracts for a particular blockchain are written and deployed. If a blockchain is considered EVM compliant, it means that its smart contracts are written in a way that complies with the specific specifications and rules of the EVM.
In too simple terms - if you basically copy/paste code that is readable on the ethereum network and deploy it on a different blockchain, if another blockchain is built to support and handle This transposed smart contract/code, it will be considered EVM compatible. Why would another blockchain build itself to these standards? The answer is that this"plug and play"The ability to greatly expand the possibilities of emerging blockchains to attract developers to their ecosystems. Ethereum is the most popular network in the world — in order for other chains to potentially take advantage of its extensive network of developers and applications, they must conform to what others are familiar with.
Consider the case of non-EVM compliant chains. By building entirely new standards and ecosystems, non-EVM compliant chains are free to fundamentally change the Ethereum toolset and stand out in various ways (some for the better). However, it also makes it more difficult to attract developers to the new ecosystem, as most of them are likely already familiar with Ethereum. For example, if the blockchain is EVM-compatible, developers can quickly copy an existing dApp on Ethereum and deploy it to this new chain without rewriting code or conducting costly and time-consuming smart contract audits. Ethereum developers porting to non-EVM compliant chains do not have this luxury, which directly results in lower project counts and market shares for these other chains.
Thus, EVM compatibility has made many blockchains very successful by lowering the barrier of entry for application developers to deploy smart contracts on these new chains. Some popular examples of EVM-compatible Layer 1s that you may be familiar with include Avalanche, BNB Smart Chain, and Fantom.
So, considering all of the above, are EVM-compatible blockchains essentially just Ethereum clones? Not quite. Although the smart contracts of an EVM-compatible blockchain are written in an EVM-compatible way, this does not require it to be the same as Ethereum in every respect—for example, the way the protocol is secured may differ, the underlying technology wait
EVM equivalence
At this stage, the so-called EVM equivalence should also be noted. In short, EVM equivalence goes a step further than EVM compatibility, meaning that smart contracts for blockchains are written and deployed in full compliance with the EVM specification.
Recall the plug and play functionality of EVM-compatible blockchains explained in the previous section. For EVM-equivalent chains, this is truly plug and play - all code conforms to the Ethereum Yellow Paper (the formal definition of the protocol), and can be deployed on another such chain exactly as written on an EVM-compatible chain superior. This setup creates greater network effects when deploying existing smart contracts and dApps elsewhere.
In contrast, smart contracts written on EVM-compliant blockchains do not need to achieve exact EVM equivalents—minimal rewriting of the smart contracts underlying code may occur. These deviations will eventually lead to some fragmentation among EVM-compatible chains, although it will still be relatively easy for Ethereum developers to replicate existing dApps on these chains. For example, there might be five different blockchains, each compatible with the EVM, but still have slightly different code bases (which makes things more complicated than if each blockchain were EVM-equivalent).
gather everything
The main benefit of having EVM compatibility should be clear by now - it makes it easier to grow these diverse ecosystems by lowering the barriers to entry for application developers building on new chains.
As mentioned earlier, of the two forms of aggregation, only optimistic aggregation is currently EVM compatible. Given the complexity involved in zero-knowledge technology and proofs, Ethereum was not originally designed around ZK-friendliness, thus causing a delay in the development of a general-purpose zkEVM at scale. However, innovation is happening — let’s now take a look at the projects leading the way in developing a functional zkEVM.
Project working on zkEVM
This section, for each project listed, mainly highlights the current development status and EVM compatibility for reference.
Polygon zkEVM
Development status: Less than a month ago, Polygon announced the launch of a public testnet for Polygon zkEVM, which is the name of their specific zkEVM project. The announcement follows a series of activities by Polygon to support its zero-knowledge proof technology, including the acquisition of Mir Protocol and the merger with Hermez Network. The testnet is currently in battle-testing mode, and Polygon encourages users to deploy on the network and help uncover potential bugs.
The mainnet is expected to launch sometime in early 2023.
image description
Image Credit: Polygon Blog
zkSync 2.0
Development status: Similar to Polygon, zkZync (founded by Matter Labs) has had a lot of activity lately in launching its zkEVM (dubbed zkSync 2.0). Just a few days ago, on October 28, 2022, the project announced the release of its Baby Alpha. This is technically equivalent to the zkEVM mainnet launch, and while the platform does not support any external projects yet, the team is continuing to stress test to make sure everything is working and performing as expected. With the release, zkSync 2.0 becomes the first zkEVM solution to be deployed on the Ethereum mainnet.
image description
Image source: zkSync Twitter
EVM compatibility level: zkSync 2.0 is building for EVM compatibility (not equivalence), but it is less compatible than Polygon. Polygon achieves opcode-level equivalence by supporting all EVM opcodes with minimal rewriting of any code, while zkSync 2.0 does not explicitly support some EVM opcodes (see documentation for more details). While this deviation may lead to certain advantages, such as faster proof generation times or reduced costs, it creates more friction when supporting Ethereum dApps and/or shared EVM tools due to lower overall compatibility.
Scroll
Development status: Of the projects that announced at EthCC 2022 that they are working on a general purpose zkEVM, Scroll is definitely the least known of Polygon and zkSync. However, this project should not be dismissed. Just a few weeks ago, it announced an upgrade to its pre-alpha testnet that enables smart contracts to be deployed on the platform. This upgrade provides developers with the first opportunity to interact with the infrastructure and experience contract deployment on the platform. Shortly after this upgrade, Scroll expects to launch a wider alpha testnet, open to all users without whitelisting, and eventually launch the mainnet.
image description
Image source: Scroll.io
Taiko
Development status: Not all projects developing zkEVM are as well advanced or well-supported as the first three mentioned. For example, Taiko is by far the earliest project in development. The project, however, shared its white paper for the first time on October 7, 2022. Also, their latest community updates include various news on team changes and core development (e.g. implementing opcodes, etc.). This project, and probably many others that exist, are really in the early stages.
image description
Image credit: Taiko Labs Blog
StarkNet
Development status: Starkware is the pioneer of ZK-STARK technology. StarkNet alpha was launched on the Ethereum mainnet in November 2021, and more than a hundred projects have been developed on the platform and started to go live.
EVM Compatibility Level: StarkNet uses the Cairo programming language in its infrastructure and contracts (not Solidity) and is not EVM compatible. However, the team is actively creating ways to increase compatibility. In particular, Netherminds Warp project is building a Solidity to Cairo translator that enables Ethereum-based projects written in Solidity to translate their codebase into Cairo for deployment on StarkNet. The Warp plugin is still in development, but once its perfected and live, it will make the StarkNet EVM compatible to a similar degree as zkSync 2.0.
image description
in conclusion
in conclusion
As a summary, all public, general-purpose rollups have a vested interest in: (i) migrating existing Ethereum dApps (and developers) to their ecosystem; (ii) being used by EVM tools such as wallets, market, etc.) support.
Each of these goals greatly aids individual rollups in terms of user adoption, and one of the easiest ways to achieve these goals is to make rollups compatible with the EVM. Especially for ZK-rollup, it is highly valued compared to optimistic rollup, which means creating a"zkEVM"- That is, a generic rollup that is compatible with the generic interface of the Ethereum ecosystem. While the complexities surrounding zero-knowledge techniques and proofs have prevented us from achieving a proven zkEVM to date, various projects (highlighted) are actively innovating and are now on the verge of achieving what was once thought to be years away.
image description
different"type"A taxonomy of EVM equivalence, image source: Vitalik Buterin blog post ("Different types of ZK-EVM"）。
A core takeaway from Vitaliks article is that having some type or degree of EVM compatibility doesnt necessarily mean that one items scrolls are definitively better or worse than others. Instead, there are just different trade-offs to consider -- for example, a less compatible (lower type in the taxonomy) rollup might make that particular ecosystem harder to build when attracting new developers, but unlike this At the same time, deviating from the existing EVM infrastructure may allow for faster proof generation times. This is something to keep in mind when analyzing different projects. For example, if the proposed zkEVM does not seek EVM equivalence, what other benefits justify this tradeoff?
references:
references:
A Comprehensive Guide for Those With “Zero Knowledge” on Rollups
Polygon and Matter Labs Compete on zkEVM Rollups
The Different Types of ZK-EVMs (Vitalik Buterin Blog)
The Benefits of Optimistic Rollups vs ZK-Rollups
ZK-Rollup Projects: Inner Workings, Importance & Analysis
Making Sense of Rollups, Part One: Optimistic vs. Zero Knowledge
Ethereum Virtual Machine
What Is an Ethereum Virtual Machine (EVM)? A Beginner’s Guide
What Is the Ethereum Virtual Machine & How Does It Work?
What is EVM? — Ethereum Virtual Machine
Introducing EVM Equivalence
Scroll — zkEVM
Ethereum’s Rollup Race: What is a ‘True’ zkEVM?
zkSync Twitter Post
Baby Alpha Has Arrived! (Matter Labs)
zkEVM FAQ (zkZync)
Polygon and Matter Labs Compete on zkEVM Rollups
Ground Up Guide: zkEVM, EVM Compatibility & Rollups (Immutable X)
Decentralized Exchange Uniswap v 3 Gets ‘Warp’ed’ Onto StarkNet
What Are Zero-Knowledge Proofs?
ZK Roundup: Ethereum Scaling Projects Are Forging Ahead
