EIP-8136 Cell-level delta for data column propagation (Cell-Level Deltas for Data Column Broadcast)
No call decision · Networking & nodes · EIP status Last Call · created 2025-01-23
A networking optimization in PeerDAS where, instead of exchanging whole blob data columns, nodes pick out and exchange only the cells they are missing. It can be rolled out gradually client by client without a hard fork.
Why it is needed
Most blobs that a block references are already in each node's mempool (the store of pending transactions). So a node already holds much of the data, yet in the current design, if even one blob is missing from the mempool, the consensus layer must wait until it has received the entire data column from the network before it can pass the data availability check. This wastes bandwidth re-downloading data it already has, and makes the node wait for everything because of one missing piece. This EIP reduces that waste by having peers announce which cells they hold, at the level of cells (the smaller units that columns are divided into), and fetch only the missing cells.
What changes
Today
- Whole data columns are exchanged, so data already in the mempool is downloaded again
- Even one missing blob forces the node to wait for the full column before passing the availability check
- Push, where data is sent out proactively, is the default
After EIP-8136
- Peers exchange cell availability as bitmaps and request only the cells they lack
- The node only waits for cells not in its mempool, so the wait for reception shrinks
- Pull, where the party that needs data fetches it, becomes the default, and proactive pushing is still possible
- With nodes that do not support the extension, full columns are exchanged as they are today
Who is affected
- Consensus client teams: Implementations must support the Partial Messages extension of Gossipsub, and it can be rolled out gradually client by client without a hard fork.
- Node operators and validators: Blob data already in the mempool is not downloaded again, so bandwidth use goes down.
- gossipsub implementers: They must handle implementation caveats such as resistance to Group ID spam and reserving space for mesh peers.
- The whole network: Under the default settings, propagation latency may increase slightly, so latency is monitored as a key metric before and after rollout.
In depth
Behavior based on the Gossipsub Partial Messages extension
This optimization uses the Gossipsub Partial Messages Extension to exchange cell bitmaps and to request and serve cells. To keep a single source of truth, the detailed specification is defined in the ethereum/consensus-specs repository. In the common case where the mempool holds most blobs, a node can skip the cells it already has and receive only the missing ones, which saves bandwidth.
Design principles: minimal semantic change and backward compatibility
The design follows two criteria. First, it minimizes changes to semantics. Second, it preserves backward compatibility without requiring a hard fork. As a result, it extends existing gossipsub behavior instead of creating a new protocol, and the mesh and gossip properties of gossipsub stay unchanged. The biggest change is that the default strategy for cell propagation moves from push to pull. Eager push, which sends data out in advance, is still possible but is not the default behavior.
Three rejected alternative designs
First, shrinking the gossipsub message unit from a column to a single cell. Without bitmaps as a first-class concept, each cell carries message overhead, and IDONTWANT, which announces held cells, always races against pushes from peers. A content-hash-based message ID carries no context about which block a cell belongs to, so a node cannot request or prioritize missing cells. Workarounds that change the meaning of the message ID also need a separate topic and could break the one-to-one assumption between message IDs and messages. Second, adding a new RPC method risks only adding network and compute load, since the RPC would sit on top of the gossipsub work, and fixing that eventually leads to the proposed design. Third, a new protocol separate from gossipsub is worth exploring in the long term, but it is too large a change for this optimization and in particular does not fit the goal of deploying without a hard fork.
Backward compatibility and peer scoring
There are no backward compatibility problems. Nodes build the gossipsub mesh and exchange gossip under the same rules as before. The optimization works only when both nodes in an exchange support the extension, and if either side does not, they exchange full gossipsub messages as before. The gossipsub peer scoring system, which rewards peers that deliver messages on time and penalizes peers that send invalid messages, is also unchanged and must behave the same way whether or not a peer supports the extension.
Security considerations and implementation pitfalls
Under the default settings, cell propagation gains a small delay compared with standard gossipsub push behavior, in exchange for bandwidth efficiency. Over time, the eager cell push policy can be refined so that propagation latency matches or improves on the existing level, and this latency is a key metric monitored during and after rollout. There are three implementation points. Even if meshing with peers that support the extension is more efficient, favoring them risks splitting the network, so unsupported peers SHOULD NOT be discriminated against. Peer scores should be largely the same regardless of Partial Messages support, and a peer that sends cells one at a time must not receive a higher score than a peer that sends them all at once. Implementations must also withstand spam that floods messages with different Group IDs, and SHOULD reserve space for mesh peer messages to guard against hostile non-mesh peers. Deployment proceeds gradually and can be rolled back if needed.
Progress status
This EIP is in Last Call status, and its last-call-deadline is 2026-11-01. Because it is a networking optimization that needs no hard fork, it can be deployed client by client regardless of the fork schedule. It was discussed on the ACDT #91 call on August 10, 2026, but no separate decision was made.