Distributed blob reconstruction: sharing the recovery work concentrated on supernodes

Strawmap I* (2028) · distributed blob reconstruction

This splits the blob recovery work that supernodes alone shoulder in PeerDAS into row-level gossip topics so that every node in the network shares it. It creates a path to recover data even without supernodes.

Why it is needed

PeerDAS (EIP-7594) is designed so that blob data in a block is extended with erasure coding and split into 128 columns, and a node that receives at least 64 of them can reconstruct the whole. In practice, though, this recovery work falls almost entirely on supernodes, which subscribe to all 128 columns. As the number of blobs grows, the load on each supernode grows with it, and every supernode redoes the same work by reconstructing all the missing blobs. There is also no way to share this work within the network. The EIP text itself treats reliance on supernodes as a concentrated weakness that leaves network resilience below a desirable level. RowDAS is a proposal to build a faster, lighter-on-CPU and more robust recovery structure by having each node first reconstruct a different part of the blob space. It was accepted as a Hegotá candidate on the ACDC call 184 in August 2026, but it was dropped from consideration on call 189 in October because client support was low and current blob demand is small, so it is not urgent. The EIP is still at the Draft stage. The Strawmap places it in the 2028 I* fork slot, but that is only an estimate and not confirmed.

How it works

  1. Splitting into columns and spreading them out PeerDAS extends blob data with erasure coding, splits it into 128 columns and distributes them. A node that receives at least 64 columns can compute the rest and reconstruct the whole.
  2. Row subnet assignment It adds 128 new row subnets named data_row_{subnet_id}. Blobs are mapped to subnets by a pseudo-random permutation that changes every slot, and each node's responsible subnet is set by a hash of its node_id. Both can be computed without chain state.
  3. Reconstructing in shares A row reconstructor that subscribes to 64 or more columns must subscribe to its assigned row subnet and reconstruct the blobs in that row first. Other nodes that support cell-level transmission are also encouraged to subscribe, but they have no obligation to store data.
  4. Returning the reconstructed pieces Recovered cells are sent to neighbors on the column topics the node subscribes to, and are also handed by fanout to peers on column subnets it does not subscribe to. A node can announce only a randomly chosen subset of columns or delay transmission so that it does not overlap with existing subscribers.

Related EIPs

← Roadmap