Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

EIP-8288 (zkzkframes)

Table of Contents

What EIP-8288 is

EIP-8288, “In-mempool signature and proof aggregation”, adds a dependency frame mode to EIP-8141 frame transactions. A dependency frame declares one or more (scheme, data_hash, verification_key_hash) triples. It executes no EVM code; each triple is a claim that must be proven valid for the block to be valid. Contracts read the declared triples with the existing EIP-8141 introspection instructions.

The proofs themselves never enter the block. Transactions travel in mempool wrappers that carry either the direct proofs or a recursive STARK over them. Mempool nodes recursively aggregate the dependencies of all their pending transactions at a fixed interval, FOCIL inclusion lists carry their own aggregate, and the builder produces one final recursive STARK over the dependencies of the included transactions. The block header commits to that STARK and to the hash of the block’s sorted, deduplicated dependency list.

The EIP was merged as a Draft in September 2026 and supports two schemes: LeanSPHINCS signatures and LeanSTARK proofs.

How a native rollup uses it

A native rollup update declares exactly one dependency:

(LEANSTARK_SCHEME, public_input_root, verification_key_hash)
  • public_input_root is the root of the public output produced by proving the L2 block with L1’s stateless validation program, committed as EIP-8025’s PublicInput, as defined in the Specification.
  • verification_key_hash is the hash of the EVM program’s verification key selected from the EIP-8357 registry, either the current entry or a pinned one.

A LeanSTARK proof is a proof of a program running on leanVM. This book assumes that L1 uses the same zkVM for its own execution proofs, so the L1 stateless validation program is proven on leanVM directly. leanVM’s planned move to RISC-V (leanVM #277) points in this direction: it would run the same guest programs that EIP-8025’s zkVMs run today, once it supports their standard target and interface, including cryptographic accelerators, and continuations for block-sized runs. Declaring a dependency means requiring it, so the native proof is always a single mandatory 1-of-1 proof.

A minimal self-paying transaction looks like this:

frame 0: VERIFY      target = sender, flags = APPROVE_EXECUTION_AND_PAYMENT
frame 1: DEP_VERIFY  data = (LEANSTARK_SCHEME, public_input_root, verification_key_hash)
frame 2: SENDER      target = NativeRollup, data = advance(params, dependency_frame_index = 1)

The VERIFY frame runs the smart account’s authorization; the dependency frame grants no authority on its own. A sponsored transaction replaces frame 0 with an only_verify frame for the sender followed by a pay frame for the paymaster. The L2 data still travels in blobs: EIP-8288 proves correctness, not availability, and BLOBHASH returns the transaction’s versioned hashes in every frame.

The rollup contract verifies no proof itself. It reads the triple with FRAMEPARAM and FRAMEDATACOPY, checks the verification key hash against the EIP-8357 registry, and checks the data hash against the root it reconstructs from its own state. See the NativeRollup contract in the Specification.

Relation to the mandatory L1 proof

EIP-8288’s recursive STARK only proves that every declared dependency is valid. It does not prove that the L1 transactions executed correctly, that the rollup contract matched the dependency to the right transition, or that the dependency list was correctly extracted from the block. With full-payload validation, validators check those things by executing the block themselves.

This book assumes validators instead verify a mandatory L1 execution proof and do not download the full payload. That proof must therefore also bind EIP-8288’s dependency hash and recursive STARK. Since both proofs come from the same zkVM, the mandatory L1 proof can recursively verify the EIP-8288 aggregate, leaving validators a single proof.

Open issues

  1. LeanSTARK dependencies cannot be proven yet. leanVM aggregates signatures, but has no way to express that a proof of an arbitrary program verifies under a given key, and its planned RISC-V rewrite drops the recursion code. The ethrex prototype of EIP-8288 therefore refuses LeanSTARK dependencies. Native rollups need exactly this, together with a leanVM build of the L1 stateless validation program.
  2. What a LeanSTARK data_hash commits to. EIP-8288 calls it the public inputs hash, without saying how it is derived from a program’s public values. leanVM’s RISC-V guests have a 32-byte public input and a 32-byte public output. The Specification fixes it for native rollups as the root of EIP-8025’s PublicInput, but the EIP needs a general rule.
  3. Recursive proving in the mempool. Every participating mempool node produces a new recursive STARK over its pending transactions once per second, and aggregates are wrapped repeatedly with no bound on recursion depth. It is an open question whether ordinary mempool nodes can realistically do this, rather than only the builder.
  4. Wrapper capacity. MAX_LEANSTARK_DEPS_PER_WRAPPER = 1, yet each node is expected to broadcast one wrapper covering all of its active transactions. As written, two native-rollup transactions cannot share a wrapper.
  5. Frame placement. EIP-8288’s examples put the dependency frame before VERIFY, while EIP-8141’s public mempool only recognizes four validation prefixes. The layout above places it after the prefix; neither EIP specifies this yet.
  6. Compact validation. EIP-8288 assumes validators extract dependencies from the full transactions. How its dependency hash and recursive STARK enter the compact payload header and the mandatory L1 proof is not specified.
  7. Unfinished parameters. AGGREGATED_VK is still to be defined, with no mechanism for later changes to the verifier relation. Neither the dependency-list hash nor the hash behind verification_key_hash is named, although BLAKE3 is the leading choice.