EPF Study Group #3: zkEVMs

Cody Gunton and Ignacio Hagopian - March 25, 2026

https://codygunton.github.io/talks-and-writing/2026-03-25-epf-study-zkevms/

QR code to slides

Introduction

Outline

  1. Why do we want zkEVMs? (The scaling problem)
  2. What is a SNARK? (Concepts and history)
  3. Ethereum guests (Understand what we are proving)
  4. Protocol changes (Adapting Ethereum for proofs)

Goal of introducing zkEVMs

Allow the EVM to execute more compute per block while keeping the work done by the consensus network small to preserve decentralization.

Attester Requirements Today

An attester must re-execute every transaction. As blocks get bigger, this time pressure is the bottleneck.

The Scaling Problem

If we allow more transactions in a block, eventually we exhaust the following attester resources:

  • bandwidth: the transactions don't arrive in time
  • compute: the transactions can't be processed quickly enough
  • state: the amount of storage used grows faster

How SNARKs Help

  • zkVMs create an asymmetry:

    • A network of low-power nodes (verifiers)
    • can check the work of powerful nodes (provers)
    • using only a very small amount of data (hashes and proofs)

  • In our application:

    • attesters will be low-power nodes who will verify proofs
    • proofs will be produced by computationally powerful provers
    • attesters will only need a small amount of data even as we increase throughput

Block Size and Proof Size

  • Without ZKEVM proofs:

    • Average: currently ~175 KB; max ~1.26 MB adversarial (EIP-7623)
    • Higher gas limit => blocks get bigger, i.e., more data for attesters to receive

  • With ZKEVM proofs:

    • ≤300 KB, insensitive to block size and configurable at a cost
    • Fixed-size proof replaces variable-size re-execution — this is the asymmetry

Optional Proofs and Mandatory Proofs

ZKVMs

SNARK and other words

  • SNARK (Succinct Non-interactive Argument of Knowledge): a logical argument that allows one party (a Prover) to convince another party (a Verifier) that they (the Prover) did the work of executing a particular computation

    • hazy terminology: SNARK, SNARK protocol, SNARK proof

  • ZKSNARK: a SNARK where the Prover keeps some details of the computation private

    • requires extra engineering and computation; these are not widely in use yet

  • ZK: a term abused to refer to the use of SNARKs in general

  • (ZK)STARK: T = Transparent; used for systems without a certain trust assumption

  • ZKVM: a particularly flexible approach to implementing SNARKs

History on one slide

I Was Told Real-Time Proving Is Impossible in 2021

Now we're there™

Interactive Proof System

  • There are two parties, Prover and Verifier

    • They agree on a computation. V wants to be convinced that P did the computation.
    • P writes down every step of the computation.
    • They exchange messages. The set of P messages = the proof.

  • Typical part of the exchange:

    • V: "use this random number I chose to do some math and send me the result. I'll check the result satisfies this formula."
    • P: "even if I had all of the computers in the world, the only way I know of to make a result value that satisfies the formula is to be honest, so I guess I'll do that."

Non-interactive Proof System

  • Goal: avoid P and V having to communicate over a network.
  • Solution: P uses an out-of-control function (hash function) to produce challenge values rather than asking V for random values.

Skeleton of a SNARK: The Program

  • "P and V agree on the computation" -- what does that mean?
  • Proof systems argue about computations given in special, low-level languages describing arithmetic circuits.
    • Traditional paradigm: everything is built up from logical operations like AND, NOT, OR, XOR, etc.
    • Arithmetic circuits: everything is built up from arithmetic operations like +, *, -.
  • There exist special languages for writing programs for SNARKs
    • e.g.: circom, Noir, Cairo, gnark
    • tooling is improving but rough; fragmented ecosystems

Skeleton of a SNARK: Proving

  • trace generation: execute the program, saving all intermediate values in an "execution trace", a collection of polynomials
  • commitment computation: create a binding fingerprint of the trace data using a polynomial commitment scheme
  • reduction: reduce checking the logic of each step in the computation is valid to check that logic "at a random point" is valid
  • spot checking: check the logic "at a random point" is valid
  • PCS opening: use the commitments to argue that the "random points" came from the execution trace that was committed before

Skeleton of a SNARK: Proving

  • trace generation: expensive serial bottleneck; returns polynomials (univariate or multilinear)
  • commitment computation: FRI-based or WHIR-based; KZG; Hyrax
  • reduction: quotient argument; sumcheck
  • spot checking: evaluate the constraints at a random evaluation of the trace polynomials
  • PCS opening: check Merkle proofs and FRI folding steps; elliptic curve pairing

Putting This Into Practice: Generalities

  • Different applications have different requirements. Design space:
    • How do we write programs for proving them?
    • Does the application need privacy?
    • Where will the program be proven? (Memory constraints? Compute constraints?)
    • Where will the program be verified? (Bandwidth constraints on proof size?)

Putting This Into Practice: ZKVMs

  • Goal:

    • Allow developers to write programs using normal programming languages such as Rust or C++ or Go or Java
    • Unlock robust, maintainable systems
    • Rely on widely used compiler infrastructure

  • Reality:

    • VM overhead is real but tolerable; huge success overall for Ethereum applications
    • Only Rust and C++ work well and programmers still have to "target zk"
    • Go support is improving significantly in recent weeks

zkEVM = zkVM + Guest Program

Cartoon picture to be further developed:

Ethereum Guests

How does a node work today?

Today's node architecture

Today vs Future

Today's node architecture
Future node architecture

How do zkVMs help the as we increase the gas limit?

CPU resources

  • Exploit prover-verifier asymmetry
  • Proving is expensive, but verification is constant & cheap (<100ms)
  • Offload computation from every node to a single prover
  • At some gas limit, verifying a proof becomes faster than re-executing

Storage resources

  • Remove the need for a full state database on the EL

Network resources

  • Proof size is small (~300KiB) and constant vs. block data
  • Makes bandwidth usage more predictable and less bursty

Protocol challenges that do not solve

Full state requirement for particular roles

  • Outside protocol roles: RPC nodes, explorers
  • In protocol roles: block builders

State growth/size

  • State growth still continues...
  • Who stores the state?
  • How do new nodes sync?
  • Can we use zkVMs to help with this?

Proof verification latency, size, and security

Proof verification times across zkVMs
Proof verification QR Proof verification dashboard
Proof verification summary table
Soundcalc QR Soundcalc

EngineAPI flows - Validation

EngineAPI context
EngineAPI new payload

The Guest Program

Guest program architecture

Guest program - ~EngineAPI part

Guest program - EngineAPI

Guest program - STF

Guest program - STF

Execution Witness

ExecutionWitness structure

Outputs commitment

Guest program outputs context Outputs new payload request
  • hash_tree_root(NewPayloadRequest) == hash_tree_root(NewPayloadRequestHeader)

How to build an Ethereum guest? (spec & tests)

  • Execution witness generation

    • Standarize its generation; any ELs can generate it if something goes wrong

  • Guest program

    • Standarized input & output make them fungible
    • New particular logic should be thoroughly reviewed and tested (consensus critical & avoid invalid-block validation)

https://github.com/ethereum/execution-specs/tree/projects/zkevm
https://github.com/ethereum/execution-spec-tests/releases?q=zkevm&expanded=true

How to build an Ethereum guest? (engineering)

Two approaches:

  • From scratch — implement the guest program in a language that compiles to RISCV64IM

  • Refactor an existing EL — adapt Ethrex, Geth, or Reth

    • Challenges: no_std support, refactorings, performance optimizations
    • Tension: re-execution mode vs. guest program mode

zkEVM standards for zkVM-agnosticism

Goal: guest programs should work with any zkVM

  • Standard IO interface for inputs and outputs
    • How the guest reads private inputs and writes public outputs
  • Accelerators (zkVM precompiles) via standard C interface
    • Keccak256, secp256k1, BN254, etc.
    • Each zkVM implements these natively for performance
  • Target (riscv64im_zicclsm-unknown-none-elf)
    • Define a minimal RISC-V instruction set for zkEVMs.

https://github.com/eth-act/zkvm-standards/tree/main/standards

Protocol Changes

Do we need protocol changes?

Resources are limited

  • Capex (hardware costs)
  • Opex (electricity, maintenance)
  • Bandwidth

We have constraints

  • Proving time
  • Proof size (network overhead)
  • Proof verification time
  • Security bits (128 bits, provable security)

Key question: If the protocol isn't aware of proofs, who is responsible for generating and propagating them?

What are "Prover Killers"?

Operations that are cheap in gas compared to proving effort (i.e. mispriced).

An adversary can fill a block with them, making it unprovable in time.

Example:

  • Say we have 7s max. as proving time
  • For 60M gas limit, ADD 3 gas => max ~20M ADD in a block => need 2.85M ADD/s
  • What if we benchmark and find we can only do 1M ADD/s?
  • ADD price scaled by 2.85x ==> ADD price ~9 gas.

https://zkevm.ethereum.foundation/blog/repricings-for-block-proving-part-1
https://zkevm.ethereum.foundation/blog/repricings-for-block-proving-part-2

FOCIL considerations

Without FOCIL With FOCIL
Block txs selection Full liberty Set of txs forced into it
Prover killers impact Builder can avoid them Can't avoid IL-txs impact
Forced gas 0 gas 1 IL × 40 txs × 17M = 680 Mgas

Benchmarks & repricing

Benchmark dashboard

https://eth-act.github.io/zkevm-benchmark-runs/repricing/

Not everything can be solved with repricing

  • Code-chunking — split contracts bytecode into smaller and provable chunks to reduce bytecode verification worst-case

  • Binary trees — consider other tree-arity and other potential hash functions for merkelization to speedup proving

https://ethresear.ch/t/merkelizing-bytecode-options-tradeoffs/22255
https://ethereum-magicians.org/t/eip-7864-ethereum-state-using-a-unified-binary-tree/22611/6

Gain more proving time: ePBS

Slot design

Free network resources: Blocks in Blobs (EIP-8142)

  • Verifying a block doesn't require downloading the whole block
  • Block data is placed in blobs — only provers need the full data
  • Validators just verify the proof
  • Releases bandwidth pressure from the network in a safe way

https://eips.ethereum.org/EIPS/eip-8142

Which "mechanical" changes we can do to speed up?

BAL single guest
  • RISC-V emulation: single threaded
  • Proving of execution trace: highly parallelizable with GPUs

BALs for re-execution acceleration

BAL re-execution BAL re-execution 2

https://eips.ethereum.org/EIPS/eip-7928

BALs for proving acceleration

BAL proving

Prover incentives

  • An economically-rational block builder should want to include proofs
    • But how do we ensure they do?
    • Capex/Opex ties into protocol economics
    • Are current block rewards (+ MEV) enough?
    • What is the relationship between builder and prover?

Get Involved

  • Ethproofs calls & events: youtube.com/playlist — including Beast Mode this week
  • zkEVM team calls: coordination on guest programs, zkVM integration, and protocol changes; to join, find the relevant planing issue; example here

References

Thanks for your attention!

TODO: add a different illustration here, not a table — will describe later

~25 minutes for this section