The 11x Compression: RowDAS, Recovery Nodes, and Ethereum's Quiet Bargain with Hierarchy

We assumed the scaling bottleneck was bandwidth — the unbounded appetite of rollups asking Ethereum to remember their lives. Csaba Kiraly's September 3 research report reframes the problem in a colder register: CPU-seconds. Under PeerDAS, the current data availability baseline, a node recovering blob data in a four-blob configuration burns roughly 48.6 CPU-seconds per recovery. Kiraly's simplified RowDAS design compresses that to 2.75. When 20 percent of the network is classified as supernodes, the figures fall from 91 to 6.6 CPU-seconds — an eleven- to fourteen-fold reduction in the arithmetic cost of memory. The proposal exists as EIP-8371, a draft without devnet validation, peer review, or a single real validator having touched it in anger. The efficiency story is convincing. The structural cost it quietly asks Ethereum to absorb is the more important story. The blob is Ethereum's designated compromise. EIP-4844 gave rollups a place to park transaction data in ephemeral containers — large segments of history that consensus nodes do not process but must verify exist. Data availability sampling is how nodes check that the data is present without downloading everything; PeerDAS distributes that verification across peers. The system works until data goes missing, and then someone must reconstruct it. That reconstruction is the hidden tax of the blob economy: recomputing absent pieces from whatever columns survived. RowDAS — row-level data availability sampling — was meant to raise resilience by handling recovery at row granularity. Kiraly's contribution is more surgical: a variant that captures most of the compute savings without redesigning the network's plumbing. Its architecture leans on a set of 'high-hosting nodes,' a term that deserves more scrutiny than it has received. These nodes must hold at least 64 of the 128 blob columns to enable reconstruction; the supernodes among them hold all 128. The PeerDAS assumption that any node might rebuild any slice is quietly replaced by a division of labor in which some nodes are obliged to remember and most are excused from doing so. We built a kingdom of ghosts in the machine — and now we are deciding which ghosts carry the heaviest chains. Kiraly's simplification is routing, not redesign. It assigns specific blobs to specific high-hosting nodes instead of asking the entire sampling network to treat every blob with equal suspicion. Other nodes receive recovery data through the existing column distribution channels — the same lanes PeerDAS already uses — rather than assembling reconstruction from fragments. This eliminates duplicated work. A healthy network no longer has dozens of nodes rebuilding the same blob from partial information; the node that already possesses the relevant columns serves it, the way a library lends books instead of expecting each patron to transcribe them from memory. The design retains the random waiting and suppression mechanisms from PeerDAS that prevent all nodes from requesting recovery at once and creating predictable bursts. What it deliberately does not do is introduce the row network that full RowDAS proposals envision: no new channels, no new topology. Only careful choreography around infrastructure that already exists. The simulation suggests the choreography works. In an environment of 1,000 nodes, recovery computation dropped elevenfold in standard configurations and closer to fourteenfold when one-fifth of nodes were supernodes — a figure the report stretches toward eighteenfold in specific settings. The numbers deserve a pause, because they are already quoted as inevitabilities. These measurements came from an in-process simulation on a Ryzen 9 8945HS, a consumer laptop processor, with per-blob recovery timed at 162 milliseconds. The scenario omitted adversarial peers, latency continents, packet loss, and nodes misrepresenting what they hold. The metric itself — recovery CPU time — excludes the transaction speed and fee savings that will inevitably attach to this improvement's marketing. A cut in CPU-seconds is a cut in node cost, not user cost; the difference is crucial when evaluating the proposal's economic claims. In my work auditing DAO governance mechanisms, I have seen this pattern before: a design that reduces average burden by concentrating existential weight. PeerDAS was built for a network where obligations could be spread widely. Simplified RowDAS is built for a network where a smaller class of participants carries the heavier columns. That is not intrinsically corrupt — but it is exactly the kind of architectural choice the Ethereum community usually subjects to scrutiny when it appears as validator concentration or sequencer centralization. The full RowDAS proposal remains the stated destination; simplified RowDAS is the first ferry. But the ferry only arrives if a subsequent proposal introduces the row channels, and that proposal does not yet exist. Confidence in a sequel is a bet on governance, not a technical guarantee. Intuition sees the pattern before the ledger does — and the pattern here is Ethereum slowly accepting that not all nodes were born equal, only that some are more equal under load. Nothing in the report suggests the savings will reach the end user. The blob market is priced by supply and demand; the fee a rollup pays for blob space is not a function of the CPU-seconds a node spends on recovery. Operators who spend less on compute may keep the margin, pass it into lower fees, or use it to run denser infrastructure. The interval between those outcomes is a governance interval: it matters who has the power to demand the pass-through. This is not a criticism unique to RowDAS; it is the same dynamic that affects every data availability improvement since Proto-Danksharding. But it is a reminder that metrics like an eighteenfold recovery improvement measure a protocol's internal efficiency, not the user's reality. In a sideways market, where attention is scarce and L2 fees are already low, the practical difference between an elevenfold and an eighteenfold improvement may be imperceptible at the application layer. The infrastructural gain is real; the narrative gain is disproportionate. The design's modesty is also its weakness. Compared to the full RowDAS proposal, simplified RowDAS offers no additional resilience beyond PeerDAS's baseline, because it does not create the row network that would let nodes recover from multiple independent directions. If the high-hosting nodes are unavailable — or overextended, because every blob's recovery routes around the same set of columns — the network falls back to the delayed-recovery posture that PeerDAS already had. The proposal's numbers impress; its failure modes are inherited. Yet there is strategic logic to the incrementalism. Shipping a small change to the Ethereum consensus layer is hard; shipping a large new network topology is harder. Full RowDAS will need years of specification, testing, and consensus. Kiraly's simplification can be shepherded through EIP-8371 faster, and once the simpler version is live, the row channels become an extension rather than a revolution. That sequencing is shrewd governance, and a reminder that meaningful decentralization usually emerges from unglamorous intermediate steps rather than one heroic deployment. The deeper uncomfortable reading is that this roadmap is being engineered for a scale problem most rollups do not have. Under current patterns, a rollup posting a handful of blobs per day will not feel the benefit of such a recovery reduction for years. This is infrastructure for a predicted catastrophe: a pre-emptive answer to a question no one has proven will be asked. And each anticipatory layer deepens a de facto hierarchy. The high-hosting nodes are one synchronization failure away from becoming points of dependence. In the simulation they are always available, always honest, always connected; in production they are operated by human beings with incentives, outages, and upgrade schedules that overlap when no one is watching. The code is law, but the humans are the bug — and this proposal multiplies the bug's surface area. Missing peer review, missing devnet validation, and missing adversarial incentive analysis are each acceptable in a draft. Together they form a pattern worth tracking. The questions ahead are not whether EIP-8371 moves forward — it will. The questions are who operates the high-hosting nodes, what they receive for the responsibility, and what happens when they fail. Those questions cannot be answered by a thousand-node simulation on a laptop. They will be answered by governance processes that are slower, messier, and far more consequential than any recovery algorithm. Watch the EIP repository for the row-channel proposal. Watch for devnet results with adversarial components. But most of all, watch who volunteers to hold the columns. To govern the future, we must debug the present — and the present's most stubborn bug is our willingness to accept elegant hierarchies once they are packaged as technical progress. The ghosts we assign to remember for us will one day decide what the rest of us are allowed to forget.