Ethereum may have a simpler way to ease the computing burden of its growing rollup ecosystem

An Ethereum prototype that divides blob-recovery duties among nodes reported an 11–18× reduction in estimated reconstruction computing work across 1,000-node simulations. The results suggest operators could reduce duplicated work through a smaller change than the full RowDAS networking proposal.

Researcher Csaba Kiraly's Sept. 3 report describes the reduced design as a possible first step toward RowDAS. It assigns recovery duties without introducing the new row-networking channels in the full proposal.

Blobs carry data used by layer-2 rollups. PeerDAS, Ethereum's system for checking that blob data is available, lets nodes download only part of it. High-custody nodes hold at least 64 of the 128 data columns, enough to rebuild missing blob data; supernodes hold all 128.

Many high-custody nodes can repeat the same reconstruction. The reduced design assigns particular blobs to them first, allowing others to receive the recovered data instead of immediately rebuilding it themselves.

What the Ethereum blob-recovery simulations show

In one configuration with four blobs, 10% supernodes and no columns withheld, the estimated network-wide reconstruction cost fell from 48.6 CPU-seconds under the PeerDAS model to 2.75 CPU-seconds under the reduced design. At a 20% supernode share, the corresponding figures were 91 and 6.6 CPU-seconds.

Those totals describe accumulated computing work across the simulated network, rather than elapsed recovery time. The accounting applies a measured 162-millisecond cost per blob recovery on a Ryzen 9 8945HS processor. Transaction speeds and fee savings were outside the reported measurements.

The PeerDAS baseline already includes randomized waiting and checks that suppress duplicate reconstruction. The comparison therefore gives existing client behavior credit for the work those delays save.

Under the reduced variant, assigned nodes share recovered cells through existing column-distribution channels. High-custody nodes retain a delayed recovery role for anything still missing, preserving a PeerDAS-style backstop.

Full RowDAS, specified in draft EIP-8371, would add another recovery route: row channels let smaller nodes pool their data and reconstruct collectively when their combined holdings clear the recovery threshold. The reduced design retains today's dependence on high-custody nodes and cannot provide that additional resilience.

The measurements remain limited to simulated, in-process networks using real cryptography. Kiraly reported no devnet results, and the full design's 128-row-subnet configuration remains an extrapolation from smaller subnet counts. Larger simulations and real-network tests are still ahead.

EIP-8371 leaves blob limits unchanged, and the proposed split between duty assignment and row networking has yet to be incorporated into its draft text. The immediate opportunity is narrower: reducing the processor work needed for recovery, with the broader resilience benefits dependent on a later row layer.