Ethereum prototype cuts blob recovery CPU work in simulations

Researcher Csaba Kiraly published a Sept. 3 report testing a pared-down alternative to the RowDAS proposal. The report describes a reduced design that assigns blob-recovery duties to specific nodes and shares recovered data over existing channels, rather than adding new row-level networking.

Blobs carry data used by layer-2 rollups. Under the current PeerDAS system, nodes download partial blob data. High-custody nodes hold at least 64 of 128 data columns and can reconstruct missing data; supernodes hold all 128 columns. Multiple high-custody nodes can attempt the same reconstruction, which can repeat CPU work across the network.

The reduced design assigns particular blobs to designated high-custody operators or supernodes. When an assigned node reconstructs missing cells, it shares those cells via the existing column-distribution channels so other nodes do not repeat the same reconstruction work.

Kiraly measured accumulated CPU work across simulated networks rather than elapsed recovery time. The accounting applied a 162-millisecond per-blob recovery cost measured on a Ryzen 9 8945HS processor. 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 baseline to 2.75 CPU-seconds under the reduced design. With a 20% supernode share, the totals were 91 CPU-seconds for PeerDAS and 6.6 CPU-seconds for the reduced variant. The report frames those results as an 11–18× reduction in computed reconstruction work in the 1,000-node simulations.

PeerDAS already includes randomized waiting and checks to reduce duplicate reconstructions; the comparison gives existing client behavior credit for savings from those mechanisms. Under the reduced design, assigned nodes share recovered cells through the same column-distribution channels Ethereum nodes already use. High-custody nodes remain a delayed backstop: data still missing after assigned recoveries can be rebuilt with a PeerDAS-style fallback.

Full RowDAS, described in draft EIP-8371, would add row-level networking channels to let smaller nodes pool columns and reconstruct collectively when their combined holdings meet the recovery threshold. The reduced design tested by Kiraly does not implement row channels and therefore does not provide the collective-reconstruction capability that row networking would offer. The report presents the experiment as a possible first step toward the larger RowDAS architecture that separates duty assignment from row networking.

The simulations ran in-process with real cryptography and stopped short of devnet or mainnet tests. The report did not include devnet results, and the full 128-row-subnet configuration envisioned by RowDAS remains an extrapolation from smaller subnet counts used in the experiments. The study did not measure transaction throughput or fee impacts and focused on reducing duplicated processor work during blob recovery.

The report calls for larger simulations and live-network trials to confirm the measured savings and to assess operational and security implications of assigning recovery duties across live Ethereum node operators. EIP-8371 currently does not incorporate the proposed split between duty assignment and row networking, and blob size limits in the draft remain unchanged.