Summary
Blob Streaming (QED, fradamt, Julian, Feb 2026) proposes adding a ticket-based ahead-of-time (AOT) blob lane alongside the existing critical-path just-in-time (JIT) blob lane. Tickets purchased on-chain rate-limit pre-propagation, enable data-availability sampling over the full slot (not just the critical path), alleviate the free-option problem, and provide end-to-end censorship resistance for blob transactions. It is an alternative to EIP-8070 (Sparse Blobpool) that achieves higher throughput while also providing stronger guarantees.
Key Concepts
JIT vs AOT Blobs
- JIT (Just-In-Time): blob propagated in the critical path of the slot requiring it. Mandatory for synchronous composability (based rollups + L1). Today’s blob lane is JIT.
- AOT (Ahead-of-Time): blob propagated before the critical path, spread over earlier parts of the slot or previous slots. All current rollup usage is effectively AOT (via the blobpool).
The blobpool already enables AOT in practice, but without:
- Global DoS resistance (no rate-limiting of pre-propagation)
- Data-availability sampling (sampling can’t be safely applied without ticket-based admission)
- Censorship resistance guarantees
Why AOT Throughput Is Higher
JIT blobs must propagate within a narrow window, creating bandwidth spikes and leaving the rest of the slot underutilized. AOT blobs spread propagation over the whole slot (or ahead of it), smoothing bandwidth and allowing 2–3× higher throughput than a pure JIT design.
Design
Blob Tickets
A user purchases a ticket by sending a transaction to a designated on-chain ticket contract. Each ticket grants:
- CL propagation right: right to pre-propagate one blob via CL data-availability sampling infrastructure
- EL propagation rights: right to propagate up to 16 blob transactions in the EL mempool
Ticket pricing: bfAOT, adjusted via EIP-1559-style controller targeting AOT_target tickets/slot. JIT blobs pay the same basefee as AOT tickets (bfJIT = bfAOT).
Two-Lane Architecture
Three capacity parameters:
- B1 (JIT max): maximum JIT blobs/slot — bounded by how long the critical path can extend
- B2 (total max): maximum total blobs/slot — bounded by total slot bandwidth
- R ≤ B1 (reserved JIT): minimum JIT capacity, protected from AOT ticket sales
Rules per slot:
- AOT tickets sold ≤
B2 - Rfor future slots - JIT blobs ≤
min(B1, B2 - AOT_scheduled)— expands when AOT demand is low
DA Contract
To enable censorship resistance for blob transactions, availability must be recorded on-chain independently of blob tx inclusion:
- Payloads can include versioned hashes for blobs not yet referenced by blob txs
- A DA contract records available blobs at block start (via system call)
- Ring buffer of 128 blocks; O(1) proof-free queries within the window
- Blob txs can propagate freely once availability is recorded (no ticket needed for resubmission)
Censorship Resistance Flow
- PTC (Payload Timeliness Committee) members observe which blobs propagated before a deadline and form a local availability view
- Members share lists of observed versioned hashes
- Majority vote → proposer must include specific versioned hashes in the payload
- Attesters only vote for blocks including PTC-required hashes
- Once recorded in DA contract, corresponding blob txs gain FOCIL-level censorship resistance
Comparison to Alternatives
| Property | Today’s blobpool | EIP-8070 (Sparse Blobpool) | Blob Streaming |
|---|---|---|---|
| DoS resistance | Weak (no rate-limit) | Moderate | Strong (tickets) |
| DAS on pre-propagated blobs | No | Possible | Yes |
| Censorship resistance | No | No | Yes (AOT lane) |
| AOT throughput scaling | Limited | Moderate | 2–3× JIT |
| Protocol complexity | Low | Medium | Higher |
Implications for Rollups
- Externally sequenced rollups (OP Stack, etc.): benefit directly — buy tickets in advance, get censorship resistance for their blob submissions
- Based rollups with preconfs: hybrid — AOT for pre-confirmed batches, JIT for synchronous composability window
- Pure based rollups + L1 usage: still needs JIT lane for block/blob co-creation
Open Questions
- How far in advance should tickets be sold? (1 slot, 10 slots, 1 epoch?)
- How does
R(reserved JIT capacity) get set and adjusted over time? - Interaction with Block-in-Blobs (EIP-8142): BiB repurposes blobs for execution data — does blob streaming apply?
- Centralizes JIT blobs to builder-controlled private channels — does this worsen PBS dynamics?
Related Pages
- Data Availability: Blobs, PeerDAS, and Block-in-Blobs — Current blob lane; PeerDAS; Block-in-Blobs
- ePBS: Enshrined Proposer-Builder Separation (EIP-7732) — ePBS provides the block pipelining needed for safe JIT blob propagation
- FOCIL: Fork-Choice Enforced Inclusion Lists (EIP-7805) — FOCIL provides censorship resistance for ticket-buying txs and blob txs after recording
Key Sources
- Scaling the DA layer with Blob Streaming (QED, fradamt, Julian Ma, Feb 2026) — full design; JIT/AOT definitions; ticket mechanism; DA contract; censorship resistance story