EIP-8288 on OP Stack: post-quantum transactions shrink to 100 to 129 bytes
Victoria Shinder2 min readA post on Ethereum Research on 2 November, "It's time to scale the trust: EIP-8288 on OP Stack", applies the EIP-8288 design to an L2 and reports measurements from a proof of concept. The starting point is data. Rollups moved execution off the L1, but every transaction's signature still lands there, and post-quantum signatures are 10 to more than 100 times larger than ECDSA. In the author's OP Stack figures, a compressed ECDSA transfer is 118 bytes and about 6,600 fit in a six-blob channel; with an inline leanSPHINCS signature the transaction grows to 5,034 bytes and the same channel holds 155.
EIP-8288 takes signatures and proofs out of transactions: they travel in the mempool and are merged recursively into one aggregate proof. On the L1 that proof sits in a block header field. L2 blocks come too fast for that, so the proof of concept posts one aggregate covering many L2 blocks to the L1 as a new OP Stack batch type, 0x02. A block whose proof never arrives is replaced during derivation by a block that keeps only its deposits.
The reported results: a leanSPHINCS-authenticated transaction compresses to 100 to 129 bytes, close to ECDSA. A 32-core AWS c7a.8xlarge proves up to 170 leanSPHINCS signatures per second on a two-second chain, and at that load the 2,040 transactions arriving per L1 block fit in 2.8 to 3.3 blobs on average, against 79 blobs if the signatures were carried inline.
What it means
The post moves the post-quantum debate from signature size to who pays for verification. If its numbers hold, an L2 does not have to choose between quantum safety and its current throughput, but it does take on a prover that must keep up with the chain and a new failure mode, a block that loses its transactions when the proof does not arrive. Both are concrete things to review rather than open questions.