For AI agents: a documentation index is available at /llms.txt. Markdown versions of pages are available by appending .md to any documentation URL.
Skip to main content

Architecture

Zesu is a stateless EVM block executor designed to run as a guest programGuest program A program that runs inside a zkVM. Zesu is a guest program: it executes blocks inside the zkVM, which then produces a proof that the execution was correct. inside a zero-knowledge virtual machine (zkVM)zkVM A zero-knowledge virtual machine that executes a guest program and produces a proof that the execution was correct. Zesu runs as a guest program inside a zkVM to generate block-validation proofs.. This page explains how Zesu fits into the end-to-end proving pipeline and why it is structured as a relocatable ELF objectELF object An Executable and Linkable Format object. Zesu is compiled as a relocatable rv64im ELF object named zesu.rv64im.o that zkVM hosts link against to produce a guest binary. rather than a zkVM-specific binary.

The proving pipeline​

At a high level, the pipeline has three stages.

Stage 1: Witness assembly

A stateful execution clientExecution client A stateful node that holds the full chain state, executes or re-executes blocks, and produces the execution witness Zesu needs to re-execute a block statelessly. For example, Besu. executes or re-executes a block while recording the account, storage, code, and ancestor-header data that the block's transactions access. It packages this data into an execution witnessExecution witness A record of the chain state a block's transactions access, captured as Merkle proofs against the block's pre-state root. The execution client produces it and Zesu consumes it to re-execute a block without holding chain state. and makes it available to the proverProver A network role, distinct from validators and block builders, that runs Zesu inside a zkVM to generate a block-validation proof and distributes the resulting execution proof. node. See Witness retrieval for how Zesu retrieves the witness.

Stage 2: Guest execution

The prover node runs Zesu as a guest program inside a zkVM. Zesu receives a StatelessInput bundle via the zkVM's read_input interface, re-executes the block against the witness, and emits a 105-byte public commitment via write_output. The zkVM then produces a proof that Zesu executed correctly. See Inputs and outputs for the full I/O contract.

Stage 3: Proof distribution

The prover node wraps the proof and the public commitment into an ExecutionProof, signs it, and broadcasts it over the consensus layer p2p network as a SignedExecutionProof message on the execution_proof gossip topic, as defined by EIP-8025. Proof-verifying nodes receive it via gossip and use the public commitment to confirm the proof covers the expected payload.

warning

EIP-8025 is in draft status and currently hosted on the spec author's fork rather than the canonical ethereum/EIPs repository. The details described here may change as the spec evolves.

The relocatable ELF design​

Zesu is compiled as a relocatable rv64im Executable and Linkable Format (ELF) object named zesu.rv64im.o. rv64im is the RISC-V 64-bit base integer instruction set with the integer multiply extension.

All EVM and stateless execution logic lives in this single object. Platform-specific behavior (I/O, heap bounds, logging, and cryptographic acceleration) is left as unresolved extern symbol references. Each zkVM host provides a host object that satisfies these references using platform-native circuits or software fallbacks, then links it against zesu.rv64im.o to produce the final guest binary.

This design decouples EVM logic from zkVM specifics at the ELF/ABI level. Adding support for a new zkVM requires only a new host object that satisfies the symbol contract; the EVM implementation itself does not change.

Memory is a joint concern. The zkVM's linker script places the ELF object, stack, and heap in the guest address space, while Zesu manages that heap itself. The allocator is selected at build time. The guest build defaults to a free-list allocator that reclaims freed memory and reuses it within the fixed heap, which prevents heap exhaustion on allocation-heavy blocks. The source also retains a simpler bump allocator that never reclaims memory: it keeps the execution trace cheaper to prove, but it can exhaust the fixed heap, so it is no longer the default.

Pre-built zesu.rv64im.o artifacts are published as GitHub releases so zkVM hosts can integrate Zesu without a source dependency on this repository. The zesu-zkvm repository provides example integrations for the Zisk, OpenVM, and Linea zkVMs. It is a stop-gap for zkVMs that don't yet implement the zkVM standards; as they adopt the common interface, they can satisfy the symbol contract directly. The same source also builds as a native binary that runs on a host CPU without any zkVM, used for debugging execution against captured blocks and validating zkVM integrations against the same I/O contract.

See Obtain the guest program for the relocatable ELF, or Install the native Zesu binary for the native build.

The symbol contract​

The extern references that zkVM hosts must satisfy fall into three categories.

  • I/O: how the host passes the StatelessInput to Zesu and receives the public commitment back. The two I/O symbols (read_input and write_output) are the only channel between the guest and the host at runtime.

  • Runtime: execution environment support: logging, process termination, and the heap allocator's position and upper-bound variables. These let Zesu operate in a freestanding environment without an operating system.

  • Accelerators: EVM precompile operations (keccak256, secp256k1 recovery, BN254 pairings, and so on) delegated to zkVM-native implementations where available. Hardware-accelerated precompiles reduce proof cost significantly for computationally expensive EVM operations.

See zkVM symbol reference for the full symbol tables including signatures and descriptions.

Next steps​