Sparse blobpool: cutting blob bandwidth to a quarter

Strawmap Glamsterdam (Early 2027) · sparse blobpool

This changes the way every node downloads whole blobs in the queue where blob transactions wait before entering a block. Only 15% of nodes download everything, and the rest check only their assigned pieces, which cuts average download volume to about a quarter.

Why it is needed

The large chunks of data that rollups post to Ethereum are called blobs. Transactions carrying blobs wait in the blobpool, the execution layer's queue, before they enter a block. Today every node downloads all of each blob. The consensus layer, by contrast, already downloads only a part thanks to sampling. As a result, on the Fusaka devnet the bandwidth used by the execution layer blobpool was observed at about 4 to 5 times that of the consensus layer. If the number of blobs keeps growing, this approach hits the limit of the node specification baseline (EIP-7870) and can harm network stability by competing with block and attestation propagation for bandwidth. The sparse blobpool brings the same sampling used in the consensus layer to the blobpool and cuts average bandwidth to about a quarter. Only the way nodes communicate changes, not block rules, so users notice no difference. It was confirmed as a required item for Devnet 8 on the August 2026 developer call. The Strawmap places it in the Glamsterdam column, but that is only an expectation, not a commitment.

How it works

  1. Splitting roles A node that hears about a new blob transaction becomes a provider that downloads the whole blob with 15% probability, and otherwise becomes a sampler that checks only pieces.
  2. Providers download everything A provider requests the whole blob from a peer that announced having all of it, verifies it, and then announces that it also holds the whole blob.
  3. Samplers download only their assigned pieces A sampler receives only the transaction body, and once at least two providers have announced they hold the blob, it requests the same pieces as the columns it is responsible for in the consensus layer. It also requests one additional random column from a provider.
  4. In an emergency, pieces are gathered to reconstruct Even if no provider responds, if the pieces held by samplers amount to 64 cells or more, the whole blob can be restored with an error-correcting code (Reed-Solomon).

Related EIPs

← Roadmap