Skip to main content
netspecsEthereum networking

4.3.6.Blob streaming

Stage
Future
Validity
Future proposal; not yet reconstructed.
Sources
1 pinned source
Content
Pending reconstruction — no completeness claim is made.

Draft EIP-8256 splits blob data into two delivery classes:

  • Ahead of time (AOT): ticket holders pre-propagate data through new consensus column subnets.
  • Just in time (JIT): builders propagate data on the existing block-time data-column path.

This is a future design, not current behavior. The pinned EIP contains several TBD consensus parameters and refers to companion consensus and Engine API specifications that are not present in the pinned corpus. It does not yet form a deployable wire contract.

Ticket and capacity model

A ticket reserves AOT blob capacity for one target slot. The buyer pays at purchase time and registers:

  • an owner execution address;
  • a BLS public key;
  • a blob count; and
  • a derived target slot.

The target slot is:

slot(selling_block_timestamp) + TICKET_LOOKAHEAD

The ticket contract keeps per-slot buckets in a ring. Ticket fees are non-refundable. Withholding the data therefore costs the same base fee as honest use of the reserved capacity.

AOT and JIT demand feed one blob base fee. The proposal reserves a minimum JIT capacity, caps JIT blobs per block, and caps both classes together. The pinned draft leaves the contract address, both main capacity limits, reserved JIT capacity, lookahead, fee update fraction, target, and ring size as TBD.

Transaction classification

The draft classifies a type-3 transaction by max_fee_per_blob_gas:

  • 0 selects AOT and requires a valid ticket;
  • a value at least the current blob base fee selects JIT; and
  • a non-zero value below the base fee is invalid.

One transaction cannot mix AOT and JIT blobs.

The execution mempool carries transaction bodies without blob sidecars. Public relay is gated by the sender's active ticket allowance. JIT blob data reaches a builder out of protocol. AOT blob data uses the consensus gossip surface below.

The proposal also moves blob-fee state from the execution header into the ticket contract. It removes blob_gas_used and excess_blob_gas from the header, so the change is not backward compatible even though the type-3 transaction and BLOBHASH opcode remain.

AOT gossip

The proposed AOT topic family carries AotDataColumnSidecar. The high-level container includes column cells and KZG proofs, the commitment list, target slot, ticket ID, and a ticket-owner BLS signature.

A receiver checks:

  • the target lies from the current slot through current_slot + AOT_PROPAGATION_WINDOW_SLOTS;
  • the ticket appears in the active set from the execution client;
  • the BLS signature matches the key registered by that ticket;
  • all cells and KZG proofs match the commitments;
  • the column maps to the topic subnet; and
  • this is the first valid sidecar for (ticket_id, column_index).

The draft sets AOT_PROPAGATION_WINDOW_SLOTS to 1. Other values needed to fully bound the surface remain open.

JIT data keeps data_column_sidecar_{subnet_id}. Both classes use the same column indices and custody groups. The data-availability check returns one result covering both classes.

ePBS commitments

The proposal replaces the payload bid's single blob commitment list with:

jit_blob_kzg_commitments
aot_blob_kzg_commitments_root

The execution payload envelope reveals the full aot_blob_kzg_commitments list. Its hash-tree root must equal the root in the bid. JIT commitments remain in the bid because their data still propagates on the critical path.

Proposed Engine API changes

The fork-choice response adds activeTickets when payload status is VALID. Each TicketInfoV1 contains the ticket ID, selling-block timestamp, owner, BLS public key, and blob count. It returns null before activation or while the execution client is syncing.

Payload attributes add availableAotBlobCommitments. A builder should include an AOT transaction only when its commitment is in that set.

Payload submission accepts separate expected JIT and AOT versioned-hash lists. The execution client compares both lists with the payload transactions.

The returned blobs bundle contains only JIT data. aotBlobInfo maps AOT versioned hashes and commitments to ticket IDs so the consensus client can use its pre-propagated cache.

engine_getBlobsV3 does not change shape. It returns null entries for AOT hashes because the proposal removes AOT data from the execution blob pool.

Reorganizations

Ticket validity follows the canonical execution chain. After a reorganization, the consensus client refreshes the active ticket set from forkchoiceUpdated. It ignores cached AOT sidecars whose tickets disappeared. The blob base fee can also change with the new ticket-contract state.

Security boundaries

  • Ticket validation must happen before a node amplifies AOT data.
  • The cache is bounded by the active ticket set, per-ticket blob count, column count, and propagation window.
  • Only the first valid (ticket_id, column_index) receives normal processing; replays do not multiply work.
  • A non-refundable ticket prices capacity griefing but does not force a builder to include the matching transaction.
  • Direct JIT delivery gives builders a larger relay role. The draft does not add a mandatory inclusion path.

Completion gaps

Before this design can move from future research to an in-progress protocol, the pinned evidence must supply:

  • every parameter now marked TBD;
  • the full AotDataColumnSidecar SSZ type and signing root;
  • topic encoding and complete IGNORE/REJECT rules;
  • the companion consensus state-transition changes;
  • final Engine API method schemas and error rules; and
  • an assigned fork or independent deployment plan.