Inputs and outputs

Zesu runs as a guest program inside a zkVM and has a defined contract for what it consumes and what it returns. That contract is defined by EIP-8025, which proposes optional execution proofs for the Ethereum consensus layer. The contract spans three integration points. Execution clients produce the input, the zkVM loads it into memory where Zesu reads it directly, and the output feeds the proof that provers generate, distribute, and verifiers later check.

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 stateless input

Zesu consumes a single SSZ-encoded structure called the stateless input.

class StatelessInput:
    new_payload_request: NewPayloadRequest
    witness: ExecutionWitness
    chain_config: ChainConfig
    public_keys: Tuple[Bytes, ...]

The four fields play distinct roles:

• new_payload_request is the Engine API payload data supplied by the consensus client. It includes the execution payload, blob versioned hashes (EIP-4844), parent beacon block root, and typed execution requests (deposits, withdrawals, consolidations).
• witness is the chain state Zesu needs to re-execute the payload's transactions without holding local state. See Witness retrieval for details.
• chain_config carries the chain ID and an optional fork_name hint (a string such as "Prague") telling the guest which fork rules to apply. When fork_name is omitted, the executor selects the fork based on the block timestamp on the mainnet schedule.
• public_keys optionally contains one 64-byte uncompressed secp256k1 public key (no 0x04 prefix) for each transaction signer, in transaction order. When provided, the guest uses these keys instead of recovering signers from transaction signatures.

The input is "private" in the proof-system sense. The node running Zesu supplies it, but verifiers don't see it. The zkVM proof attests only to the public output described below.

How Zesu receives the input

The wire format for the stateless input is SSZ. How those bytes reach Zesu is up to the host:

• zkVM hosts place the SSZ bytes in a memory-mapped input region the guest reads through the read_input symbol. See zkVM symbols for the symbol contract.
• The native binary reads the SSZ bytes from a file or from standard input. See CLI options for the exact flags and precedence.

The native binary additionally accepts a JSON development format (one file for the block, one for the witness) that deserializes into the same StatelessInput structure. The JSON format is a development convenience for cases where SSZ-encoded inputs are not available; it is not part of the EIP-8025 contract.

The validation result

After re-executing the payload, Zesu emits a public output called the stateless validation result.

class StatelessValidationResult:
    new_payload_request_root: Hash32
    successful_validation: bool
    chain_config: ChainConfig

Zesu serializes this StatelessValidationResult as a 105-byte SSZ commitment:

Bytes	Field	Description
[0..32]	new_payload_request_root	SSZ hash_tree_root of the NewPayloadRequest
[32]	successful_validation	0x01 for success, 0x00 for failure
[33..105]	chain_config	SSZ-encoded SszChainConfig (72 bytes)

Each field serves a verification role.

• new_payload_request_root binds the proof to a specific payload.
• successful_validation reports whether block execution succeeded.
• chain_config tells the verifier which chain and fork configuration the proof applies to.

A proof-verifying node accepts the proof only when the proof itself verifies for the expected guest program, successful_validation is 0x01, and both the request root and chain configuration match what the verifier expects.

Why the contract matters

Keeping the input private and the output public is what makes stateless verification possible. A verifier doesn't need the chain state or the witness to check a proof. It needs the proof, the public commitment, and a copy of the NewPayloadRequest to verify the binding.

Each integration point relies on a different part of this split.

• Execution clients that produce witnesses need to populate every field of the stateless input correctly. A malformed witness or mismatched chain configuration causes the guest to return successful_validation = false.
• zkVM hosts that run Zesu pass the serialized stateless input as private input and surface the 105-byte commitment as public output. The zkVM's symbol ABI for read_input and write_output mediates this exchange.
• Verifiers read only the public output and use it to bind a proof to a specific payload before treating that proof as evidence of valid execution.