When it comes to scaling Ethereum via rollups, zero-knowledge (ZK) rollups, and in particular the advent of EVM-compatible ZK-rollups (zkEVMs), are often considered the holy grail. Although we are not quite there yet in terms of development, various projects have recently turned up the heat in terms of innovation, making what once appeared years away seemingly within grasp. The race is now on to see which of these first movers can successfully implement a zkEVM at scale and gain the advantage in terms of early user adoption.
EVM (Ethereum Virtual Machine)
First off, what is EVM? EVM stands for Ethereum Virtual Machine, which is in essence a software platform. At a high level, remember that with a blockchain, at any given time there can only be one canonical “state” (akin to a balance sheet). This state includes all of the blockchain’s accounts, balances, etc. at that particular moment. In the case of Ethereum, the EVM partly serves as a large database for holding all of this data.
However, the EVM also plays a more dynamic role. Ethereum’s state is not only a large data structure holding all accounts and balances, but also what is known as a machine state, which can change from block to block according to a pre-defined set of rules. These rules, as you may have guessed, are defined by the EVM?—?so any smart contracts wanting to perform transactions on Ethereum that are not written in compliance with the EVM will not be processed. Not only that, but as the Ethereum blockchain’s record transforms with each permitted transaction, the EVM continuously tracks and computes the new state of the network (therefore serving as both a gatekeeper and real-time registrar). Let’s look at an example here to help illustrate.
Setting the Stage for ZkEVMs
As an initial matter, note that this article does not serve as an introductory piece with respect to rollups. As a result, if you are not already familiar with the rollup landscape on Ethereum as well as the general advantages / disadvantages of using ZK-rollups in particular, I highly recommend reading this piece first which covers these basics in detail. I am sure Eli Ben-Sasson would prefer the use of “validity rollups” throughout this article instead of ZK-rollups, but we will stick with popular convention for now.
Keeping the above in mind, let us quickly remind ourselves why ZK-rollups are often looked on favorably in comparison to optimistic rollups. Although both forms of rollups offer huge improvements in terms of scalability and throughput, ZK-rollups provide an edge in terms of transaction finality (no challenge period) and security. For the latter, ZK-rollups are generally seen as more secure since they rely on trustless cryptographic mechanisms for security as opposed to relying on the honesty of other actors to submit fraud proofs. Of course, optimistic rollups have their particular benefits as well, such as not requiring complex calculations that are best performed on specialized machines to generate proofs (which has its costs), but these are the big-ticket items to note all else equal.
I want to stress “all else equal” because as of today, not everything else is equal. In particular, between the two forms of rollups, only optimistic rollups are generally EVM-compatible, which has contributed to optimistic rollups being more popular to date in terms of total value locked (TVL).
EVM-Compatibility and Equivalence
I find the concept of the EVM and its various forms of compatibility to be one of the more overlooked and misunderstood topics in the space. The term is thrown around so often that you would think everyone understands the ins and outs, but this is most likely not the case. For an article focusing on zkEVMs, it is therefore imperative that we review the topic to ensure everyone has a strong grasp going in.
Keep in mind that public, general-purpose rollups all typically share a common goal?—?to onboard developers and users as quickly as possible in order to generate network effects in terms of adoption. This statement, in short, is what EVM-compatibility helps facilitate for new blockchain networks / rollups. Let’s explore how and why.
Assume you created a smart contract or decentralized application (dApp) on Ethereum. Like any standard smart contract, within this contract is a defined list of operations that are to be executed when certain conditions are met (e.g., given an input, the smart contract performs an output / function). To the extent this smart contract adheres to the current rules of the EVM, the EVM will help facilitate its execution leading to a new block and state on the Ethereum network (which the EVM computes). For the technically inclined, the EVM is helping facilitate execution by translating smart contract opcodes (short for operation codes, which are written in programming languages like Solidity) into bytecode so that instructions can be read and operations can be executed by the virtual machine.
The EVM can therefore almost be looked on as the lifeblood of Ethereum. By interpreting / executing smart contracts and computing the state of the Ethereum network from block to block in response to smart contract input data, it defines the rules for what can be processed and updates the state of the network in real time.