EIP-8371 RowDAS, Distributed Blob Reconstruction (RowDAS - Distributed Blob Reconstruction)
Hegota Declined for Inclusion · Scaling & data · EIP status Draft · created 2026-08-05
In PeerDAS, blob reconstruction work concentrates on supernodes. RowDAS spreads it across the whole network through row-based gossip topics. Every node takes part in reconstruction, which greatly reduces the burden on supernodes and creates a recovery path that works without them.
Why it is needed
PeerDAS (EIP-7594) extends the blob data carried in a block with erasure coding, splits it into 128 columns, and is designed so that a node holding at least 64 of them, half the total, can recover the whole. In practice this reconstruction is done by supernodes that subscribe to all 128 columns. As the blob count grows, the reconstruction burden on each supernode grows by the same amount. Supernodes also duplicate each other's work. Each one recovers every missing blob on its own, and there is no way to divide this work within the network. The original proposal holds that dependence on supernodes is also a point of concentration, so network resilience falls short of a desirable level. RowDAS proposes having each node prioritize recovering a different part of the blob space, building a structure that is faster, uses less CPU and is more robust.
What changes
Today
- Reconstruction is done by supernodes that subscribe to all 128 columns, and the burden grows in step with the blob count
- Each supernode recovers every missing blob separately, so the same work is duplicated
- Only nodes holding at least half of the columns can reconstruct, so dependence on supernodes becomes a point of concentration
After EIP-8371
- Row topics spread the reconstruction work across the whole network and reduce the burden on supernodes
- Each node first recovers its assigned row and cancels the work for rows completed elsewhere
- Ordinary nodes can collect cells from row topics and reconstruct, which creates a recovery path that does not need supernodes
Who is affected
- Supernode operators: In phase 1, a node recovers only the rows assigned to its own row subnet, and full reconstruction in phase 2 becomes a recommendation (SHOULD). Rows completed elsewhere are skipped, which reduces CPU and bandwidth load.
- Client teams: Clients must implement the new gossip topic data_row_{subnet_id}, support for cell-level deltas (EIP-8136), phased reconstruction timers, and discovery logic that uses node IDs to find peers on the same row subnet. The exact wire format is defined separately in consensus-specs.
- Validator and ordinary node operators: Nodes that support cell-level deltas are recommended to subscribe to one row subnet, and there is no obligation to retain data. Staking nodes with 64 or more custody groups become row reconstructors and take on the phase 1 reconstruction duty.
- L2 (rollup) nodes: This does not include a feature for fetching individual blobs directly, but supernodes can run with fewer resources. Because the row subnet can be computed from the slot and blob index, it lays the groundwork for a future blob retrieval extension.
In depth
Definitions and constants
The original proposal distinguishes two roles. A supernode is a node that subscribes to all 128 column subnets. A row reconstructor is a node that subscribes to at least 64 of the 128 column subnets and can therefore recover any row on its own, and every supernode is also a row reconstructor. On mainnet, staking nodes whose validator custody requirement reaches 64 or more custody groups are counted as row reconstructors. The only newly defined constant is ROW_SUBNET_COUNT = 128. This is a fixed constant that is independent of the maximum blob count. The original proposal summarizes the EIP as consisting of a new gossipsub topic, a change to the reconstruction rules, and a small change to the behavior of the existing column topics.
Extending fanout for column topics
EIP-7594 already specifies that columns obtained through reconstruction are exposed as if they had been received from the network. For a subnet the node subscribes to, it must send the reconstructed DataColumnSidecar to its topic mesh neighbors (MUST), and for a subnet it does not subscribe to, it should announce availability during gossip emission (SHOULD). This EIP adds two rules for peers that support cell-level behavior. First, before reconstruction, a node may use advertisements received through gossipsub fanout to collect the cells it needs from peers on column subnets it does not subscribe to (MAY). Second, after reconstruction, it should offer the recovered cells through fanout to peers on column subnets it does not subscribe to (SHOULD). It may advertise only a randomly chosen subset of columns rather than all of them, and it may delay fanout messages so that it does not compete with subscribers of the corresponding column topic.
Row subnets and two mapping functions
The new topic name is data_row_{subnet_id}, which is different from the deprecated blob_sidecar_{subnet_id}. Row subnets must use cell-level deltas (EIP-8136) without eager push, and the GroupID is the block root, as with column subnets. The function that assigns blobs to subnets, get_blob_row_subnet(blob_index, slot), is a per-slot pseudorandom permutation that applies compute_shuffled_index seeded with hash(b"ROW_SUBNET" + uint_to_bytes(uint64(slot))). If the blob count is at most ROW_SUBNET_COUNT, the blobs in a slot receive different subnets. If it is larger, blobs whose remainder after division by ROW_SUBNET_COUNT is the same share a subnet, so each subnet carries at most ceil(blob_count / ROW_SUBNET_COUNT) rows. Because the seed depends only on the slot, it can be computed without chain state. A node's designated row subnet is determined by get_row_subnet(node_id), which is the remainder after dividing bytes [8:16] of hash(uint_to_bytes(uint256(node_id))) by ROW_SUBNET_COUNT. Custody group derivation uses bytes [0:8] of the same hash, so the two assignments are independent of each other at no extra hashing cost. A row reconstructor must subscribe to its designated row subnet (MUST), and other nodes are recommended to subscribe when they support cell-level deltas (SHOULD). Subscribing carries no obligation to retain data.
Row subnet operating rules: partial messages, peer discovery, verification
Row subnets carry only partial messages and do not define a full message form. A node that does not support the Partial Messages Extension must not subscribe to a row subnet (MUST NOT), and mesh peers that do not support the extension may be pruned (MAY). The non-discrimination guidance in EIP-8136 applies to column topics, which have a full-message fallback path, and for nodes without support the column topics and getBlobs remain open as before. Row subnet membership is computed from the node ID alone, so no ENR extension is needed. A node applies get_row_subnet to node IDs it finds through discv5 lookups and similar means to locate peers on the same subnet, and it should secure enough connections to maintain a healthy mesh (SHOULD). This is because subnet members make up only about 1 / ROW_SUBNET_COUNT of all nodes, so they do not appear often enough among random peers. The SSZ containers, bitmap encoding and GroupID derivation are defined in ethereum/consensus-specs following the EIP-8136 approach. The bitmap covers the rows assigned to the subnet in blob_index order, and within a row in cell_index order. Cells received from a row subnet must be verified against the KZG commitment of the corresponding blob before they are forwarded or used (MUST), and a peer that sends an invalid cell is penalized under the same rules as on column subnets. A peer may limit itself to providing only half of the cells of each assigned row (MAY), and this limit applies per row. When a node receives cells through any path, it should send its updated bitmap to peers (SHOULD), and it may debounce this.
Three-phase reconstruction and timer rules
Every reconstruction duty arises only when the node holds at least 64 distinct verified cells of that row. Subscribing alone does not count as holding. Nodes that are not row reconstructors are also recommended to collect at least 64 cells for each row of their designated row subnet and announce this by bitmap (SHOULD). The row subnet pools the custody cells of its members, so the cells need not be in the node's own custody. Phase 1: a row reconstructor must recover the rows assigned to its designated row subnet that have enough cells (MUST) and update its bitmap. This is possible with its own column subscriptions alone, and a short random delay (recommended range TBD) avoids simultaneous execution across nodes. Phase 2: after collecting cells from getBlobs, columns and rows during a somewhat longer random delay (TBD), a supernode should recover all missing rows (SHOULD), and other row reconstructors may do so (MAY). This is because only a supernode subscribed to all column subnets can see rows being completed elsewhere and cancel duplicate work. Phase 3: after a delay longer than in phase 2 (TBD), any node that has joined a row subnet should recover rows that are still incomplete (SHOULD). It runs only when earlier phases fail, so the expected CPU cost is close to zero. All delays are measured from the moment the node first obtains a valid block root for that slot, and the duty attaches to only one block root per slot (the current head branch, or the first valid block root seen). Other block roots in the same slot are OPTIONAL, so double proposals cannot inflate the work. A row completed first through another path must cancel any pending reconstruction (MUST), and delays have a maximum value (TBD) so that recovery is not postponed indefinitely.
Design decision: why a fixed 128 subnets with a per-slot permutation
The subnet count is not tied to the maximum blob count in order to avoid every node's subnet assignment changing at each Blob Parameter Only fork, which would make the row meshes collapse all at once and be rebuilt. With a fixed constant, the assignment of nodes to subnets stays stable across forks, and the blob count affects only the per-slot blob mapping. The value 128 was chosen to keep the expected number of nodes per subnet in a healthy range. As of August 2026, mainnet has about 12K nodes, of which about 2K are supernodes and about 500 hold 64 to 127 columns, so there are about 2.5K row reconstructors. With ROW_SUBNET_COUNT = 128, full participation gives about 94 nodes and about 20 row reconstructors per subnet. This value is larger than the currently planned maximum blob count, so in practice each subnet carries one row per slot, and even with more blobs the per-node load is bounded by ceil(blob_count / ROW_SUBNET_COUNT). The reason for using a per-slot pseudorandom permutation instead of a simple rotation ((blob_index + slot) % ROW_SUBNET_COUNT) is that a rotation keeps one subnet busy for blob_count consecutive slots and then idle for a long stretch, so the load bunches up. With a permutation, two blobs in one slot never land on the same subnet, and compute_shuffled_index is a function that clients have already implemented. Even if the mapping is public, the block builder decides the blob indexes, so hiding it gains almost nothing, and the column topics continue to provide the guarantee against targeted suppression. The original proposal states firmly that this EIP is not FullDAS and does not include cell-level sublinear sampling, column-direction encoding, or retrieval of individual L2 blobs.
Security considerations
This EIP changes DAS networking but leaves PeerDAS custody assignment and its probabilistic guarantees untouched. Row distribution is an additional recovery path and the existing paths stay almost unchanged, so the added cost is limited to the bitmap signaling and, when data is partially withheld, wasted cell requests of at most half a row per assigned row for each row subnet member. Every reconstruction obligation is conditioned on holding 64 verified cells, so unavailable data cannot be used to trigger reconstruction CPU work. The one exception is that phase 2 full reconstruction is deliberately delayed, which implementations already do in practice, and the delay is a single one rather than a delay at every hop. An attack in which a block producer withholds a single cell from one row and releases 64 columns' worth of cells for the remaining rows, causing recovery work on a block that will end up unavailable, is inherited from PeerDAS. In PeerDAS every supernode duplicates this work, but here phase 1 divides it to about one row per row reconstructor and phase 2 skips completed rows, so total work goes down. A supernode sees the bitmaps of all columns, so it can notice unrecoverable rows and skip the work for that block. Row distribution is only an optimization, so a node MUST NOT change its sampling or availability decision rules, or delay a decision, based on row subnet state, and the column topics and request/response remain the authoritative path. Sending a bitmap per cell can make message complexity grow quadratically, so debouncing, rate limiting, and a cap on the number of GroupIDs tracked per peer are recommended. A peer that does not repeatedly deliver cells it has advertised is handled in peer scoring like a peer that sends late messages. Row subnet assignment is a public function of the node ID, so an attacker could grind node IDs to take over or isolate a particular subnet, but phase 2 reconstruction and the column topics cover that row, so the impact is limited to falling back to the current state.
Compatibility, current status, fork discussion
Row topics are limited to peers whose libp2p gossipsub implementation supports cell-level deltas. The source expects a substantial share of peers on mainnet to support this even before Glamsterdam, and a majority to support it after the Glamsterdam fork and EIP-8136. Peers that do not support it still have getBlobs and the column topics available. The recommended delay range for each phase, the maximum delay, and the wire format are still TBD. This EIP is in Draft status, so the specification may still change. In fork discussion, EIP-8371 (RowDAS) was accepted as a Hegotá candidate (PFI) at ACDC #184 on 08.06, with the aim of spreading the PeerDAS reconstruction load across row topics. It was later declined for inclusion (DFI) in Hegotá at ACDC #189 on 10.15, because client support was low and current blob demand is small, so it was not seen as urgent.