EIP-8070 eth/72 sparse blobpool (eth/72 - Sparse Blobpool)
Scheduled for Inclusion · Networking & nodes · EIP status Last Call · created 2025-10-29
Changes the execution layer blobpool, where every node downloads the full blob data, so that a node receives the full data only with 15% probability and otherwise samples only the same assigned pieces as the consensus layer, cutting average bandwidth to about a quarter.
Why it is needed
The data of blob-carrying transactions (type 3 transactions) is currently downloaded in full by every node from the blobpool, the queue of the execution layer (EL). The consensus layer (CL), by contrast, already receives only a portion thanks to sampling. As a result, on Fusaka devnets the average download bandwidth of a full node was observed to be about 4 to 5 times higher for the EL blobpool than for the CL. If throughput keeps growing through BPO forks that only raise the blob count, this full replication approach will hit the limits of the node specifications set by EIP-7870 and compete with block and attestation propagation for bandwidth, which can harm network stability and liveness. This proposal brings the same custody-aligned sampling as the CL to the EL, cutting average bandwidth to about a quarter while keeping the simple, probabilistic nature of the current blobpool instead of a complex sharding structure. It is a design to unlock the next stage of blob throughput with no user-visible change.
What changes
Today
- Every EL node downloads the full data of every blob transaction.
- On Fusaka devnets, the EL blobpool accounts for about 4 to 5 times the full node download bandwidth of the CL.
- As blob throughput grows, blobpool traffic competes with block and attestation propagation.
After EIP-8070
- A node receives the full blob only with 15% probability, and with the other 85% it samples only the same pieces (cells) as its CL custody.
- A validator receives only at least 8 of the 64 cells per blob, so average bandwidth becomes about 0.25 times the current level (about a 4x reduction).
- A block builder always fetches the full data of the blob transactions it plans to include in advance (eager mode).
- During block validation, the CL uses engine_getBlobsV4 to take advantage of cells already spread across the blobpool.
Who is affected
- Node operators and validators: Average blobpool bandwidth drops to about a quarter, so higher blob throughput can be handled on the same hardware baseline (EIP-7870).
- Client teams: The new wire protocol eth/72 and the Engine API extension must be implemented. Implementing this feature is mandatory to take part in Devnet 8.
- L2s and rollups: The EL blobpool bandwidth, the bottleneck for scaling blob throughput, is eased. The transaction format and how to use it do not change.
- Users: There is no directly visible change. Only the networking layer changes, and the consensus rules stay the same.
In depth
eth/72 wire protocol changes
Adds a cell_mask field of type B_16 (uint128) to NewPooledTransactionHashes (0x08). It is interpreted as a bit array of length CELLS_PER_EXT_BLOB, with a 1 set at the index of each column held, across all type 3 transactions announced in the message. It is nil if there are no type 3 transactions. In GetPooledTransactions (0x09) / PooledTransactions (0x0a) responses, the blobs field of type 3 transactions is encoded as an RLP empty list (0xc0) so the blob body is omitted (the empty byte string 0x80 is forbidden). Commitments and cell proofs are still sent. New GetCells (0x14) and Cells (0x15) messages are added for cell-level requests and responses, and a responder may return fewer cells than requested depending on its capacity. A single cell_mask cannot express a different holding state for each transaction, so the design announces fully held transactions and partially held transactions in separate messages.
Provider and sampler roles
When a node receives the hash of an unknown type 3 transaction, it becomes a provider with probability p = 0.15 and a sampler otherwise. This decision can be remembered for some period, and a stateless heuristic that hashes a mix of a time value and stable properties of the transaction is recommended. A provider must (MUST) request the full data from peers that announced full possession using GetPooledTransactions and a GetCells with an all-ones cell_mask, verify it according to EIP-7594, and re-announce with an all-ones cell_mask. A sampler receives only the transaction body, observes at least 2 provider announcements, and then requests custody-aligned cells from peers whose holdings overlap. When requesting from a provider, it must request 1 additional random column, C_extra = 1, beyond its custody. A sampler may drop a transaction for which it has not observed sufficient network saturation within some period, and may re-sample old transactions to recheck availability. Recording each peer's full-request rate and disconnecting peers that exceed a fairness heuristic is left to each implementation's discretion.
Parameter choices and reliability analysis
The key parameters are p = 0.15, a default peer set D = 50, a minimum of SAMPLES_PER_SLOT = 8 columns per node, a reconstruction threshold of 64 cells, a minimum of 2 provider observations before sampling, and C_extra = 1. Average bandwidth is 0.15 + 0.85/8 ≈ 0.25, about a 4x reduction. A binomial analysis (X~Binomial(D, p)) shows that with D = 50, the probability of having 3 or more neighbors with the full payload is 98.6%, and the probability of complete unavailability is 0.03%. If primary reliability fails, secondary reliability applies. This is a path that pools the columns held by samplers and reconstructs them by Reed-Solomon decoding. Even in an adversarial scenario in which all 3 providers fail to respond, 47 samplers supply an expected 124.3 distinct columns, so P(Y ≥ 64) exceeds 99.9%. About 10 samplers are needed to get a reasonable probability (>80%) of reconstruction.
Block builders and supernodes
A local block builder should (SHOULD) operate in eager mode by default. It acts as a p = 1.0 provider for every type 3 transaction it intends to include, obtains the full blob data, and guarantees complete blob data for all transactions in the payload. It may (MAY) stay at p = 0.15 and switch to eager mode 2 to 3 slots before block production, but this is not recommended because it creates a distinct pattern in networking behavior that harms the builder's privacy and raises the risk of DoS attacks. A supernode that wants to receive every blob in full must (MUST) spread its requests across samplers and providers, should (SHOULD) prioritize reconstructing blobs and proofs from 64 columns, and should (SHOULD) maintain a larger peer set so that it does not concentrate load on a few neighbors.
Engine API extension
Adds an optional custodyColumns parameter to engine_forkchoiceUpdatedV4. The 16-byte value is interpreted as a bitarray of length CELLS_PER_EXT_BLOB and tells the EL the CL's current custody column set, or is null if it cannot be provided (timeout 8 seconds). The CL MUST send the value after startup, when custody changes, and after a connection drop or reconnect. When custody expands, the EL MUST issue new sampling requests for the added columns and SHOULD broadcast an updated announcement as a sampler. When custody shrinks, the EL MAY clean up cells only after first sending the updated announcement. An identical value or null is a no-op for the blobpool state. engine_getBlobsV4 takes versioned_blob_hashes and indices_bitarray (uint128) and returns an array of BlobCellsAndProofsV1 with a 500ms timeout. blob_cells is a partial matrix of the requested blobs where missing cells are nil, and proofs is an array of 48-byte KZGProof values as defined in EIP-4844.
Threat model and sampling noise
The threat model assumes a permissionless environment where Sybil attacks are free. There are four main scenarios. A DoS that drains mempool resources with partially disclosed transactions can be detected by nodes that request the full payload. An attack that selectively withholds the transaction data of a specific L2 is mitigated by a large and diverse peer set. Eclipse attacks are mitigated by periodically rotating connections and tracking the full announcement rate of neighbors, and free riders by tracking the request-to-announcement ratio and blocking them. Custody-aligned sampling has a predictable request pattern, so a victim could be attacked by an adversary that stores only the few columns the victim will sample while impersonating a provider. To prevent this, the EIP introduces sampling noise: requests to a provider include at least one additional random column, and failure to serve that column is treated as a strong signal of misbehavior. The overhead per request is negligible at about 12KiB. Normative peer scoring that statistically tracks the request-to-announcement ratio was excluded from standardization because of its rigidity and left to each implementation's local heuristics.
Status and deployment path
This EIP is in Last Call status and the last-call-deadline is 2026-11-01. It does not change consensus rules, so a hard fork is not strictly required, but deploying it in the context of a hard fork is RECOMMENDED. The wire protocol allows multiple versions to coexist, so older clients using eth/71 do not break immediately. On the core developer calls, ACDT #89 on 07.27 agreed to include this EIP's Engine API changes (GetBlobsV4 and the FCU carrying custody columns) in Devnet 8, and to postpone cell-level DAS until bandwidth requires it. ACDC #184 on 08.06 confirmed inclusion in Devnet 8, and ACDT #91 on 08.10 confirmed it as a Devnet 8 requirement without objection, so every client must implement it to take part in Devnet 8. The original text leaves further threat modeling and the impact of RBF (replace-by-fee) as open points, lists Test Cases as TBD, and also notes the limited expressiveness of cell_mask as a TODO.