Don't want to trade it yourself?
Our desk runs DEX portfolios on profit share.
Currencies39058
Market Cap$ 2.80T+0.10%
24h Spot Volume$ 33.19B+8.65%
DominanceBTC57.09%-0.36%ETH10.93%+0.51%
ETH Gas0.09 Gwei
FeaturedEthereumTechnologyResearchEthereum Foundation
Sep 7, 2026
2min read
byLiam ‘Akiba’ Wright
forCryptoSlate
A Sept. 3 prototype implementing a reduced RowDAS-style duty assignment for Ethereum blob recovery cut simulated <a href="https://xpertsstudio.com/liquid-network-320m-hack-halts-transactions/” title=”Liquid Network $320M Hack Halts Transactions”>network-wide reconstruction CPU work by roughly 11–18× in 1,000-node tests, falling from 48.6 to 2.75 CPU-seconds at 10% supernodes and from 91 to 6.6 at 20% (measured as 162 ms per blob on a Ryzen 9 8945HS). The design avoids new row-networking channels and preserves PeerDAS backstops with high-custody nodes holding 64 of 128 columns, suggesting a practical protocol upgrade path to lower processor load for rollups and broader crypto/DeFi adoption, but results are limited to simulations with no devnet tests and do not yet deliver full EIP-8371 row-layer resilience.
See what traders are focused on
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.
Source: cryptorank.io