It's time to scale the trust: EIP-8288 on OP Stack

Scaling Trust on OP‑Stack with EIP‑8288

Rollups achieve their massive throughput by moving execution off Ethereum’s L1, but every transaction still carries its authentication data back to L1. In the coming post‑quantum (PQ) era, signatures and zk‑proofs become orders of magnitude larger than today’s ECDSA signatures, turning authentication into the primary data bottleneck. EIP‑8288 proposes a clean solution: extract signatures and proofs from individual transactions, aggregate them into a single leanVM proof, and post that proof to L1 as a separate batch. The result is a lean transaction size (≈100‑130 B) and a predictable, bounded L1 data cost regardless of the number of users.

---

1. The Data Bottleneck

• Current rollup model – Execution is off‑chain, but authentication data (signatures, zk‑proofs) still lands on L1 with every transaction.
• Quantum‑ready signatures – Schemes such as leanSPHINCS or SLH‑DSA are 10‑100× larger than ECDSA (4 KB‑8 KB vs. 65 B). A full‑blobs channel that fits ~6 600 ECDSA‑signed txs drops to ~155 txs when using leanSPHINCS.
• ZK applications – Hash‑based STARK proofs can exceed 400 KB each, making a 6‑blob channel infeasible without compression.
• Result – The L1 data fee per transaction skyrockets, throttling L2 throughput and making privacy‑preserving apps impractical.

---

2. How EIP‑8288 Works on OP‑Stack

1. Dependency frames – Transactions include a list of `(scheme, datahash, verificationkey_hash)` triples instead of the raw signature or proof.
2. Mempool‑only proofs – Signatures and zk‑proofs live only in the mempool; they never appear in blocks.
3. Recursive aggregation – A dedicated `op‑aggregator` merges proofs from many L2 blocks into a single leanVM tree. The root (≈354 KB, ~322 KB compressed) represents thousands of statements.
4. Batch posting – The aggregate is posted to L1 as a new OP‑Stack batch type (`0x02`). The L1 only stores the aggregate and a small reference in each transaction (public key + program ID).
5. Verification cost – During execution a transaction pays a modest gas amount for verification (≈3 000 gas for a signature, 30 000 gas for a STARK) plus a share of the `recursivestarkgas` field. The heavy lifting is done once per aggregate on L1.

Performance snapshot – On a 32‑core AWS c7a.8xlarge, the system can produce ~170 leanSPHINCS signatures per second. With a 2‑second L1 block, the resulting 2 040 transactions fit in 2.8‑3.3 blobs, compared to 79 blobs if signatures were inlined.

---

3. Practical Implications for Developers

• Transaction size – After aggregation, a transaction is 100‑129 B, comparable to today’s ECDSA txs, keeping gas and calldata costs low.
• Compatibility – The PoC builds on existing OP‑Stack components (`op‑reth`, `op‑aggregator`) and uses the AA transaction format from EIP‑8130/EIP‑8430, which is already being adopted by L2s.
• Privacy‑preserving apps – By moving large zk‑proofs into the aggregate, privacy pools and rollup‑based mixers can scale without hitting blob limits.
• Future‑proofing – The design is agnostic to the specific PQ scheme; new signatures or proof systems can be added by defining a new scheme identifier.

---

4. Next Steps and Open Challenges

• Scheme 0x11 (leanSTARK) – Still reserved; full support will require extending the aggregation tree to handle arbitrary proof types.
• Root verification – Current verification requires a pre‑computed class key (~1 KB) and a seal proof; optimizing this step will further reduce L1 verification time.
• Standardization – Aligning EIP‑8288 with the emerging AA standards (EIP‑8130/8430) will smooth integration across L2s.
• Tooling – SDKs for developers to generate dependency frames and interact with `op‑aggregator` are needed to lower adoption friction.

---

Closing Thoughts

EIP‑8288 turns the authentication cost from a per‑transaction liability into a shared, amortized expense. By aggregating signatures and proofs into a single leanVM proof, OP‑Stack rollups can maintain their current scaling advantage even in a post‑quantum world. The approach preserves the core rollup promise—L1 fees that do not grow with transaction count—while opening the door for high‑throughput, privacy‑focused applications. As the ecosystem matures, broader support for additional proof schemes and tighter integration with account abstraction will make this model the default path for secure, scalable L2s.