← Quickstarts
How the Composer Attests a Batch
PRE-MAINNET
STEP 1 OF 3
NEXT: How the deriver rebuilds L2 from L1 →
COMPOSER OPENS THE STREAM
composer
→
rpc Prove(stream ProveChunk)
→
eez-proof-signer
header
block
block
⋯
block
chunk 1 of N — header, then one BlockWitness per window block
ProveHeader
MUST BE FIRST
rollup_id
7
from_block
812,401
posted + 1
to_block
812,450
sync_height
post_batch.abi_calldata
1,412 bytes
post_batch.public_inputs_hash
0x9c1f7a…e0d2
32B, composer's claim
post_batch.l1_block_hash
0x0000…0000
empty — timeless batch
One stream, one job: header first, then every block in the window, in order.
PROTOCOL RESEARCHERS

How the composer attests a batch

"Attests", not "proves", and the distinction is the page. Three mechanisms sit behind that word, and only the first is what the name "prover" suggests.

Stateless re-execution. The prover is handed a BlockWitness and replays the block from it to recompute the hash itself, rather than trusting the composer's claim or reading a state database. That part is real, and step 2 is it.

ECDSA standing in for succinctness. What comes back is not a succinct proof. ECDSAProofSystem is described upstream as a "temporary proof system that uses ECDSA signature recovery instead of a ZK proof", and its verify is one line: ECDSA.recover(publicInputsHash, proof) == signer. So the guarantee today is that a named signer re-executed and agreed — an attestation. It is not yet a proof anyone can check without trusting that signer.

A per-rollup prover swap. Which contract does the checking is a per-rollup choice, not a network-wide one. IProofSystem is any contract that can check (proof, publicInputsHash) — ZK, ECDSA, or otherwise — referenced from that rollup's own vkey map. There is no central registry, and upstream is explicit that each rollup owner vets which proof-system addresses their rollup allows. Swapping ECDSA for a real verifier is therefore a per-rollup upgrade, and until a rollup makes it, "attests" is the honest verb for that rollup.

The mechanics below are the first mechanism. The composer opens one gRPC stream to the proof-signer and sends a ProveHeader first — blocks always follow in order.

That one stream carries the header, the blocks and a signature back.

WHAT YOU'LL LEARN
  • 01 · ONE STREAM, ONE JOBOne gRPC stream to the proof-signer: ProveHeader first, blocks in order.
  • 02 · THE PROVER RE-EXECUTESFor each BlockWitness, the prover decodes PostBatch’s calldata and replays the block to recompute the hash.
  • 03 · SIGN & RETURNThe prover signs the recomputed hash; the composer only trusts it once the signature recovers to the registered attester — an attestation, not a succinct proof.

Verified against eez-rollup0 @ a4b9b2f — pre-mainnet; interfaces may move.