Lecture 12: zkEVM Design, Optimization and Applications

What this lecture covers

This lecture, given by a Scroll co-founder, explains why zero-knowledge proofs became a practical way to scale Ethereum and how a zkEVM is actually built. It answers the question of how you prove that a batch of Ethereum Virtual Machine transactions executed correctly without re-executing them, and why doing this for the EVM specifically (rather than a custom, ZK-friendly virtual machine) is both attractive and hard.

The lecture sits at the applied end of the course's proof-system material: it assumes you already know constraint systems and proving protocols, and uses that background to walk through a real production system. After watching, you should understand the tradeoffs between zkEVM design levels, how Plonkish arithmetization with custom gates and lookups supports a dynamic virtual machine, how a full zkEVM circuit is assembled from many interconnected sub-circuits, and what open research problems remain in circuit design and proving performance.

Key ideas

• Rollup (layer 2): a scaling layer that batches transactions off-chain and posts a succinct validity proof to layer 1, so Ethereum only verifies one proof instead of re-executing every transaction.
• zkEVM: a set of circuits that proves an EVM execution trace is valid, letting any existing smart contract be proven without an application-specific circuit.
• Design levels (Justin Drake's taxonomy): language-level (new VM plus a compiler, most efficient, least compatible), bytecode-level (proves EVM bytecode directly, Scroll's choice), and consensus/EVM-equivalent (also proves storage and block-header details, most compatible, slowest).
• Plonkish arithmetization: a table-based constraint system supporting custom gates, permutation constraints, and lookup arguments, chosen over R1CS because it handles the EVM's dynamic, op-code-dependent execution trace efficiently.
• Lookup tables: used to prove range checks, bitwise operations, hashing, and read/write consistency for stack, memory, and storage by looking values up in separately-constrained tables instead of writing large constraint sets inline.
• Two-layer proving: a first layer proves EVM logic with an expressive, hardware-friendly system (Halo2 with KZG commitments), and an aggregation layer compresses many sub-circuit proofs into one small proof cheap to verify on Ethereum.
• Random linear combination (RLC): a technique for encoding a 256-bit EVM word (split into 32 limbs) or a dynamic-length lookup tuple into a single field element using randomness derived mid-proof, which requires a multi-phase prover.

Walkthrough

Why the zkEVM matters (0:00)

The lecture opens with Scroll's motivation: layer-1 Ethereum is secure and decentralized but slow and expensive because every node re-executes every transaction. Rollups fix this by posting a succinct proof of validity instead of raw transactions, potentially increasing throughput by orders of magnitude while keeping equivalent security. Building a general zkEVM, rather than one circuit per application, is what lets any existing Ethereum contract and tool work unmodified on the rollup.

Why zkEVMs became feasible (11:04)

The lecture explains four advances that made zkEVMs practical in the last two years: flexible polynomial commitment schemes enabling custom gates and lookups, hardware-accelerated proving (GPU/FPGA/ASIC), and recursive proof aggregation. Together these cut proving overhead by roughly three orders of magnitude, and the lecture places Scroll's bytecode-level design among the three zkEVM types by compatibility and proving cost.

Choosing Plonkish over R1CS (17:13)

The lecture compares R1CS (variables in a flat vector, degree-two linear constraints) with Plonkish arithmetization (variables in a table, supporting custom gates, permutation constraints, and lookups). It walks through concrete examples of range checks and bitwise operations done far more cheaply with lookups than with R1CS, and explains why lookups are essential for proving that reads from memory are consistent with earlier writes.

Building the EVM circuit (29:29)

Using ADD as a running example, the lecture shows the three kinds of witness data in each execution step: step context (program counter, gas, stack pointer), a "key switch" selector indicating which op code is active, and op-code-specific witness values. Constraints tie adjacent steps together and, through lookups, tie each step to separate circuits for RAM (stack/memory/storage consistency) and hashing, so the full architecture is an EVM circuit connected to specialized sub-circuits by lookup tables.

Choosing the proof system (47:41)

The lecture lays out separate requirements for the two proving layers: the first layer needs expressiveness (custom gates, lookups) and a hardware-friendly, highly parallel prover; the second (aggregation) layer needs a tiny verification circuit and low on-chain gas cost. It surveys candidates (Plonky2, Halo2, Nova-style folding schemes) and explains why Scroll uses Halo2 with KZG commitments in both layers, differing from Polygon Hermez's Stark-based approach.

Circuit-side research problems (1:05:03)

The lecture discusses open problems: encoding 256-bit words and dynamic-length inputs efficiently with RLC while managing the multi-phase prover overhead it forces on interconnected circuits, better ways to lay out hundreds of custom gates for different op codes, and how to let sub-circuits like hashing grow dynamically instead of being padded to a fixed maximum size.

Backend performance and applications (1:24:24)

The lecture covers GPU acceleration of multi-scalar multiplication and NTT, data-copy and witness-generation bottlenecks, and memory optimization from roughly a terabyte down to a few hundred gigabytes. It closes with applications beyond rollups: "enshrined" layer-1 validity proofs, recursive proofs of an entire chain's history, proof-of-exploit bug bounties, and ZK oracles that prove facts about historical on-chain state.

Before you watch

• Be comfortable with constraint systems (R1CS) and polynomial IOP/commitment-based proving protocols covered earlier in this course.
• Know roughly how the EVM executes transactions and updates state (stack, memory, storage, state root).
• Familiarity with Plonk-style custom gates and lookup arguments helps but is introduced again here with examples.

Check your understanding

1. Why does proving arbitrary EVM bytecode require a general-purpose "virtual machine circuit" rather than one circuit per smart contract?
2. What advantage does Plonkish arithmetization have over R1CS for handling the EVM's dynamic execution trace?
3. Why are lookup tables essential for proving that stack, memory, and storage reads are consistent with earlier writes?
4. What problem does random linear combination (RLC) solve, and why does it require a multi-phase prover?
5. Why does the aggregation (second) layer have different proof-system requirements than the first layer that proves EVM logic directly?