Ground Up Guide: zkEVM, EVM Compatibility & Rollups

  1. What differs between application-specific and general purpose rollups?
  2. What is a zk-EVM rollup? What do terms like EVM-equivalent and EVM-compatible actually mean, and how do they apply to rollups?
  3. What is the current state of the zk-rollup ecosystem, and what does that mean for my project?

ZK-Rollups

ZK-rollups are made possible by a simple observation: proof systems like STARKs or SNARKs allow for a linear number of statements to be verified with sub-linear processing (e.g. 1000 statements → 10 verifier checks, 10,000 statements → 11 verifier checks). We can use this property to create massively scalable blockchain transaction processing as follows:

  1. Users submit transactions involving those assets to an L2 sequencer, which gathers them into ordered batches, and generates a validity proof (e.g. a STARK/SNARK) and aggregated state update for each batch
  2. This state update and proof are submitted to and verified by our L1 zk-rollup smart contract, and used to update our L1 state
  3. Users can use this L1 state (subject to different data availability mechanisms) to retrieve their assets, allowing for full self-custody and “Ethereum security”
Simplified ZK-Rollup Architecture

Application-Specific Rollups

So far, all production-grade zk-rollups have been what we call “application-specific rollups’’. In an application specific rollup, the rollup supports a fixed number of “state transitions” (e.g. trading) defined by the rollup operator. This is incredibly useful for hyper-optimizing common use cases e.g.:

  • 3 separate projects (zkSync, Polygon Hermez/zkEVM and Scroll) all announced at ETH CC 2022 that they would be the first “zkEVM” to reach mainnet

Understanding the EVM

The Ethereum Virtual Machine is the runtime environment in which Ethereum transactions are executed, initially defined in the Ethereum Yellow Paper and later modified by a series of Ethereum Improvement Proposals (EIPs). It is composed of:

  • ~140 priced “opcodes” which perform state transitions in this machine
Diagram from https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
  • Arithmetic Operations — ADD (adds numbers), SUBTRACT
  • State Operations — SSTORE (store data), SLOAD (load data)
  • Transaction Operations — CALLDATA, BLOCKNUMBER (return information about the currently executing transaction)
  • Every operation must be deterministic (as all nodes must agree on the state after transaction execution)
  • We need blockchain-specific concepts (e.g. smart contracts, transactions)
  • Some complex operations must be primitives (e.g. cryptography)
  • Transactions must be sandboxed, with no I/O or external state access

Ethereum Compatibility

However, what people refer to as being an “EVM chain” usually extends beyond just mirroring this runtime environment. There are several major specifications which began on Ethereum and have become de facto global standards:

  • Ethereum’s JSON-RPC Client API (a specification for interacting with Ethereum nodes)
  • ERC20/ERC721 (Ethereum token standards)
  • ethers.js (a web library for interfacing with Ethereum)
  • Ethereum’s cryptography (e.g. keccak256 as a hash function, ECDSA signatures over secp256k1)
Why does Medium not support tables?

ZK-EVM

Public general purpose rollups all share a common goal: onboard developers and users to generate network effects as quickly as possible. This requires a combination of creating the most performant rollup technology, having the best BD team and doing the earliest or most effective marketing. However, all rollup teams (for the reasons outlined above) are deeply concerned about:

  • Being supported by existing EVM tooling (e.g. libraries, wallets, marketplaces etc.)
  1. Create a custom VM, map EVM opcodes into opcodes for that VM, then prove the correctness of the trace in that custom environment
  2. Create a custom VM, transpile Solidity into your custom VM’s bytecode (directly, or via a custom high level language), and prove in your custom environment

Option 1: Proving the EVM Execution Trace

Scroll

Let’s start with the most intuitive: proving the EVM execution trace itself, an approach currently being worked on by the Scroll team (alongside the Privacy Scaling Group at the Ethereum Foundation). To make this work, we’ll need to:

  1. Design a circuit to link the bytecode with the real execution trace
  2. Design a circuit for each opcode (allowing us to prove the correctness of reads, writes and computations for each opcode)

Option 2: Custom VM + Opcode Support

This realisation has driven teams to adopt the “EVM-compatible” approach canvassed above: create a custom VM with optimized performance, then convert EVM bytecode directly into bytecode for your VM.

Polygon

One team focused on this approach is Polygon Hermez (recently renamed to Polygon zkEVM). Polygon’s approach is building a zkEVM is “opcode-level equivalency”, which sounds initially similar to the approach taken by Scroll. However, unlike Scroll, Polygon’s alternate runtime (the “zkExecutor”) runs tailor-made “zkASM’’ opcodes rather than EVM opcodes to optimise the EVM interpretation (i.e. reduce the number of constraints vs. proving the EVM directly). The Hermez team describe this as an “opcode based approach”, because the core challenge is recreating every EVM opcode in their custom VM (you can view the code here), so that they can quickly go from EVM bytecode to a verifiable format.

  • The possible requirement for developers to modify their L1 code or tooling frameworks
  • Potentially increased drift from Ethereum over time

Option 3: Custom VM + Transpiler

The above solutions invest substantial development time in “making the EVM work for zk-rollups”, prioritising compatibility over long-term performance and scalability. There is another option: create an entire new, purpose built VM, and then add support for Ethereum tooling as an additional layer on top.

StarkNet

This is the approach StarkWare has taken with StarkNet, which is currently the most progressed general purpose rollup. StarkNet runs a custom smart contract VM (Cairo VM), with its own low-level language (Cairo), both purpose built for smart contract rollups. This means StarkNet has no Ethereum compatibility out of the box — as we saw earlier, even opcode-level VM-level compatibility is a potential handbrake on rollup performance.

zkSync

Another team adopting this strategy is zkSync. zkSync have created their own VM (SyncVM), which is register-based and defines its own Algebraic Intermediate Representation (AIR). They have then built a specialized compiler to compile Yul (an intermediate language which can be compiled to bytecode for different EVM versions, think a lower-level Solidity) into LLVM-IR, which they then compile into instructions for their custom VM. This is similar to the approach taken by StarkWare, but theoretically provides more flexibility around the base language (though currently only Solidity 0.8.x is supported). The zkSync team originally created their own CAIRO-like language (Zinc), but have pivoted the majority of their efforts to focus on the Solidity compiler to allow a simpler migration for L1 developers. In general, their strategy is to reuse more of the Ethereum toolset than StarkNet — I’d expect their client APIs etc. to be more “Ethereum compatible” as well.

Vitalik’s zkEVM Types

Vitalik Buterin’s blog on zkEVMs highlighted the fundamental dilemma currently facing rollup teams: the EVM wasn’t built for “verifiable” programs. In fact, as we’ve shown through the analysis above, the more compatible you seek to be with Ethereum, the less performant your program in “verifiable format” will be. Vitalik identified several broad categories for general purpose rollups based on their degree of compatibility with existing EVM infrastructure:

Current State of Smart Contract Rollups

Given the detail required to understand the above, it’s no wonder we’ve invented a bunch of confusing language around Ethereum compatibility. In truth, no zk-rollup perfectly mirrors the behavior of the EVM in all circumstances — it’s all a matter of degree, and the detailed choices made by each team will end up mattering most when it comes to maintainability and performance, rather than compatibility alone. My opinion is that the following definitions are clearest and most consistent:

Additional Rollup Factors

Despite the primary focus of this article, it’s not all about Ethereum ecosystem compatibility vs. performance! There are a number of other factors which impact whether or not you should build on a particular general purpose rollup. I’ll suggest several major additional criteria:

  • Proving & Sequencing: all rollups require an entity which is responsible for ordering transactions and producing proofs. Most application-specific rollups today are “single-sequencer”, which produces higher throughput at the cost of resilience. Most general purpose rollups are initially beginning as single sequencer rollups, but they usually have plans to decentralize this sequencer over time.
  • Self-Custody: the core promise of zk-rollups is the ability to unlock scale while preserving Ethereum’s security. However, many general purpose rollups currently don’t have a clear mechanism for the recovery of user assets in the event of a malicious or unavailable sequencer.
  • Data Availability: as mentioned in the introduction, self-custody guarantees are subject to the availability of state data in the failure case. However, full data availability introduces additional costs for users, leading to a spectrum of data availability modes. This is already widely used in the application-specific rollup world (e.g. Validiums, Volitions), but each general purpose rollup will need to add this functionality individually.
Medium has reduced me to screenshotting tables full of links…

Summary

Smart contract rollups are an incredibly exciting part of Ethereum’s scaling roadmap. The different tradeoffs made by those rollups in their relationship to the existing Ethereum toolset are an amazing testament to the diversity of Ethereum’s developer ecosystem.

  • Where is the formal specification of your custom VM, and where is it more performant/less performant than other options?
  • How many changes will be made to the other Ethereum interfaces (e.g. client APIs, libraries) by this rollup, which will break Ethereum tools?
  • When will this rollup be live on testnet? On mainnet? Able to support sustained production throughput of 1000+ custom contract tps?
  • When do you expect to support full self custody for user assets, and what will that look like in the context of a general purpose rollup?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store