Ethereum prototype cuts blob-recovery computing load by 11–18×
In brief
- Ethereum prototype reduced blob-recovery computing work by 11–18× in 1,000-node simulations.
- Reduced design assigns recovery duties without adding new row-networking channels.
- High-custody nodes remain essential; design lacks full RowDAS resilience.
How the reduced design works
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.
The reduced design assigns recovery duties without introducing the new row-networking channels in the full RowDAS proposal. Under the reduced variant, assigned nodes share recovered cells through existing column-distribution channels. This sidesteps the infrastructure lift of full RowDAS while still distributing work more evenly across the network.
Simulation results show material gains. In one configuration with four blobs and 10% supernodes, the estimated network-wide reconstruction cost fell from 48.6 CPU-seconds under PeerDAS to 2.75 CPU-seconds under the reduced design. At a 20% supernode share, the corresponding figures were 91 and 6.6 CPU-seconds. The accounting applies a measured 162-millisecond cost per blob recovery on a Ryzen 9 8945HS processor.
Trade-offs and limitations
The reduced design retains today's dependence on high-custody nodes and cannot provide that additional resilience. Full RowDAS, specified in draft EIP-8371, would add row channels letting smaller nodes pool their data and reconstruct collectively. That full design promises greater decentralization, but requires more infrastructure work.
Kiraly reported no devnet results. The full design's 128-row-subnet configuration remains an extrapolation from smaller subnet counts. EIP-8371 leaves blob limits unchanged, so the reduced approach doesn't unlock higher throughput on its own.
