Ethereum's blob recovery just got 11x cheaper. Here's the fix nobody's talking about.

I've been watching Ethereum's scaling story for a long time now. And there's a pattern that keeps showing up: the network grows, the promises get bigger, and then somebody has to figure out how to clean up the mess in the background. This week that somebody is Csaba Kiraly, and the mess is blob recovery.

Kiraly published a report on September 3rd that's getting nowhere near the attention it deserves. It's about a way to cut the computing burden of Ethereum's rollup-heavy data flow by up to 18 times. That's not a typo. Eighteen times.

The: what the simulations actually show

Let's get technical, but not too technical. Blobs are the data containers layer-2 rollups use to post transactions to Ethereum. They've been central to Ethereum's scaling strategy since Dencun went live in March 2024. But there's a problem: PeerDAS, the system that checks whether blob data is actually available, makes nodes download only part of the data. That's efficient in theory. In practice, it means high-custody nodes, the ones holding at least half of the 128 data columns, end up doing the heavy lifting. A lot of them can end up reconstructing the same data at the same time.

That's wasteful. It's like ten people in an office all photocopying the same document because nobody told them someone else already did it.

Kiraly's fix is called the reduced RowDAS variant, and it does something remarkably simple: it assigns specific blobs to specific high-custody nodes first. That way, when a node needs recovered data, it asks the assigned node instead of immediately rebuilding it from scratch.

The numbers from his 1,000-node simulations are the kind that make you do a double take. In one configuration, with four blobs and 10% supernodes (the nodes holding all 128 columns), the estimated network-wide reconstruction cost dropped from 48.6 CPU-seconds under the current PeerDAS model to 2.75 CPU-seconds. At a 20% supernode share, the figures went from 91 CPU-seconds down to 6.6.

That's an 11 to 18 times reduction. On a single Ryzen 9 8945HS processor, each blob recovery takes about 162 milliseconds. These totals are accumulated computing work across the whole network, not elapsed recovery time. So nobody's pretending this makes transactions instantly faster or fees drastically cheaper. But processor time is processor time, and on a network that's straining under data growth, that's a meaningful chunk of overhead to remove.

What I find interesting is that the current PeerDAS baseline already includes randomized waiting and checks that suppress duplicate reconstruction. In other words, the comparison gives existing client behavior credit for the work those delays save. And this reduced design still beats it by an order of magnitude.

He paused before answering when I asked about that gap. The kind of pause that means the real answer is next. The system isn't just inefficient because nodes don't know what each other is doing. It's inefficient because the architecture assumes no coordination, and then layers randomness on top to prevent the worst collisions. That works, but it's a blunt instrument. What Kiraly's proposing is a scalpel.

There's a tradeoff, of course. The full RowDAS proposal, outlined in draft EIP-8371, would add row channels that let smaller nodes pool their data and reconstruct collectively. That would distribute the resilience burden beyond the high-custody nodes. The reduced variant doesn't do that. It keeps today's dependence on high-custody nodes, just makes them less redundant in their work. And there's no devnet data yet. The measurements come from simulated, in-process networks using real cryptography, which is encouraging but not the same as testing on actual infrastructure.

What this actually means for Ethereum

Here's the thing nobody in the Ethereum foundation chat rooms wants to say out loud: the network has been quietly moving toward a model where the people with the most powerful nodes matter more than everyone else. That's not decentralization in the way the early community envisioned it.

Kiraly's work doesn't solve that problem. What it does is buy time. It reduces the immediate computing burden while the community debates whether to take the bigger step toward full RowDAS. That's the right way to approach protocol upgrades, honestly. Test the smaller change first. Measure it. Then decide if the bigger change is worth the complexity.

The story the pitch deck won't tell you is that scaling decisions are never just about speed and cost. They're about who gets to participate. Making recovery more efficient means today's high-custody nodes can handle more without upgrading their hardware. That's good for the hobbyists with strong machines. But it doesn't bring the people with weaker setups into the fold. That's still the barrier.

Blob limits remain unchanged under EIP-8371. Nothing in this proposal touches the transaction fee market or the compression rollups use. So if you're looking for a headline about cheaper L2 fees, this isn't it. But if you're worried about Ethereum's ability to handle the data surge that's coming, this is genuinely heartening news.

I asked a developer friend who works on rollup infrastructure what he thought. He laughed. He said, the fact that we're surprised coordination can cut work by 18x tells you how little coordination we've been doing.

What to make of all this

So what's the takeaway for someone who isn't running a node and doesn't care about CPU-seconds? Honestly, it's this: keep an eye on Kiraly's work, and more broadly, on the next round of EIP discussions.

Because what's being tested here isn't just a technical tweak. It's a question about how much coordination Ethereum can tolerate. Pure decentralization says every node should verify everything independently. Pure efficiency says assign roles and trust the assignment. Both extremes have problems. The reduced RowDAS variant sits somewhere in the middle, and that's exactly why it's worth paying attention to.

Would I run out and bet your portfolio on this landing in the next hard fork? No. There's no devnet data yet. The full RowDAS proposal is still in draft, and the 128-row-subnet configuration is an extrapolation from smaller subnet counts. Larger simulations and real-network tests are still ahead.

But here's what I can tell you after years of covering protocol research: the proposals that actually ship are usually the ones that show measurable improvements early, with simple mechanisms and clear tradeoffs. Kiraly's reduced design checks all three boxes.

The whitepaper doesn't mention the three months he spent thinking through the failure modes where assigned nodes drop offline, or the edge cases where coordinated recovery breaks down. But that work is in the numbers. A network that can cut its reconstruction cost by 11 to 18 times without new networking infrastructure is a network that found a way to be smarter with what it already has.

And in this industry, that's rarer than you'd think.