Skip to main content

Architecture

Zesu is a stateless EVM block executor designed to run as a guest program inside a zero-knowledge virtual machine (zkVM). This page explains how Zesu fits into the end-to-end proving pipeline and why it is structured as a relocatable ELF object 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 client 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 witness and makes it available to the prover 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 with a bump allocator that never reclaims memory. Skipping deallocation keeps the execution trace simpler and cheaper to prove, which differs from how many guest programs manage memory.

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 bump 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​