Draft EIP-8136 proposes an independent network upgrade for PeerDAS. A peer sends only the cells that another peer lacks instead of sending a complete data column.
The partial data columns page records the concrete application containers and validation rules. This page records the proposal status, compatibility contract, and rollout boundary.
Current full-column path
The current PeerDAS contract treats one DataColumnSidecar as the gossip
message. If a node already has cells for all but one blob row, it still receives
the whole column. Its local blob pool cannot suppress the duplicate cells at
the wire boundary.
Cell-level deltas keep the same:
data_column_sidecar_{subnet_id}topic;- mesh and fanout peers;
- block and column identity;
- KZG commitment and proof checks;
- custody assignments; and
- peer-scoring meaning.
Only the transfer unit between two capable peers changes.
Proposed exchange
The gossipsub Partial Messages Extension gives each full message a group ID. The application defines:
- metadata that says which parts a peer has and requests;
- partial data that carries selected parts; and
- a reconstruction rule for the full application message.
For PeerDAS, one part is a cell and its proof. Bitmaps describe the blob-row indices. A sender responds with the intersection of the cells it has and the cells the peer requests.
A receiver verifies each cell in the same block, column, commitment, and proof
context as a full sidecar. It combines valid wire cells with valid local
blob-pool cells. When complete, it reconstructs the normal
DataColumnSidecar.
Capability and fallback
Partial transfer applies only between peers that both support it and when the receiver requests it for that topic.
An extension-capable node must still accept a full gossipsub message. A peer that does not negotiate partial transfer gets the full column path. A node that constructs the full sidecar forwards it to those peers.
This compatibility rule permits staged deployment without a hard fork. It does not prove that the feature is deployed. The pinned EIP is Draft, and the pinned libp2p specification labels the extension a Working Draft.
Rollout sequence
The generic extension recommends two steps:
- Deploy nodes that can send partial messages but do not request them. These nodes seed support while all exchanges stay on full messages.
- Gradually enable nodes that request partial messages. Monitor latency, bandwidth, score, and fallback behavior before wider use.
A deployment can stop requesting partial data without changing the topic or fork. The full-message path remains the rollback path.
Scoring
Cell delivery should have the same score meaning as delivery of the full column:
- useful novel cells can count as first delivery;
- clients rate-limit the reward so splitting data creates no score advantage;
- invalid cells or proofs count as invalid delivery; and
- lack of extension support does not lower a peer's score.
Clients must not form an extension-only peer set. Strong preference for capable peers could split the data-column mesh during a mixed rollout.
Resource and denial-of-service controls
Partial transfer adds per-group and per-peer state. Implementations:
- bound tracked group IDs, metadata, and outstanding requests;
- expire state with the gossip acceptance window;
- reserve capacity for mesh peers;
- validate a common header before allocating large cell state where possible;
- rate-limit peers that churn group IDs or metadata; and
- keep eager data bounded.
An application can validate block context better than the gossipsub library. The library therefore passes application-defined metadata and partial data to the application rather than retaining unbounded state itself.
Open specification points
The checked-in sources show active design work but not one settled wire revision. In particular, the Fulu application profile and generic libp2p document use different subscription field names. The EIP also contains stale editor notes that still refer to unmerged pull requests.
The proposal becomes a complete deployable contract only when the EIP, libp2p protobuf, and consensus application profile name the same negotiation fields and revision. Until then, this page makes no deployment or interoperability claim.