2026-08-01 · Tristan Wilson

Fusaka made ordinary nodes lighter and complete blob retrieval harder

Fusaka changed an assumption that many L2 operators had quietly built into their infrastructure: a normal beacon node no longer necessarily has every complete blob available to serve.

That is not a failure of PeerDAS. It is the point.

EIP-7594 erasure-codes each blob across 128 data columns. An ordinary consensus node can sample and custody a subset of those columns, validate that the data was made available, and avoid downloading the full matrix. Ethereum made ordinary nodes lighter while increasing the blob capacity available to rollups.

But “I can validate that the data was available” and “I can return this complete blob to an L2 node” are now different capabilities.

Complete retrieval is now a heavier role

A node needs at least half of the columns to reconstruct the full data matrix. It may voluntarily custody more, but the minimum ordinary-node role does not promise a complete blob response.

Client documentation makes the operational split concrete. Lighthouse says an ordinary post-Fusaka full node cannot serve complete blobs. A semi-supernode, which custodies half the columns and reconstructs blobs, can; a supernode, which custodies every column, can serve them without reconstruction. Both are deliberately more demanding in bandwidth and storage than an ordinary node.

The Lighthouse data-column guide is one client’s implementation, not a universal flag reference, but the separation is architectural:

1. participating in consensus and validating availability;
2. reconstructing complete blobs inside the custody window; and
3. retaining or acquiring complete blobs beyond that window.

The Ethereum Magicians discussion on post-Fusaka blob retrieval captures the practical concern from an L2 operator’s perspective: a home operator who needs every blob must now run the heavier Ethereum acquisition role alongside the L2 stack. The replies debate the exact bandwidth envelope, but not the underlying change. Complete retrieval is no longer an automatic capability of an ordinary node.

The scale is moving too. The Ethereum Foundation’s January 2026 protocol update recorded a target of 14 blobs per block and a maximum of 21 after the first two Blob Parameter Only forks—2.3 times the pre-Fusaka data space. That makes it easier for ordinary nodes to avoid the full data load, while making the all-blobs role a larger and more specialized job.

There is still a real product gap for L2 operators who want only their own complete blobs: current PeerDAS does not yet provide row topics or row-based request/response for efficient sender-specific retrieval. The discussion suggests future protocol directions, including requesting complete data only for relevant blob transactions. Until then, the practical choices are broader column custody, a specialized retrieval service, or both.

The precise conclusion is therefore not “Fusaka made every node expensive.” Fusaka made the ordinary node cheaper. It made complete blob retrieval a separate role whose cost and behavior must be designed explicitly.

Our “archive” Prysm was not a complete archive

Our Prysm beacon node was configured with effectively infinite blob retention, backfill enabled, and semi-supernode mode. We treated it as an archive node. Then we measured its actual blob endpoint across history.

It had a hard serving frontier at epoch 351,433, around slot 11,245,856 on 12 March 2025. It held beacon blocks back to genesis, but its blob store began at that frontier. The checkpoint sync had obtained only the blob history peers still offered at the time. Telling the running node to retain blobs indefinitely did not retroactively fetch the older blobs it had never received.

The endpoint made the gap more dangerous than a clean error would have. For a pruned slot that the corresponding beacon block proved contained a blob, Prysm could answer 200 with an empty data array. A status-only check would have reported success while measuring absence.

We found the frontier by querying known non-empty slots inside the current custody window, around the claimed retention boundary, and near the beginning of blob history. We compared the returned versioned hashes with the commitments in the corresponding beacon blocks. The node’s mode and retention settings described what it intended to keep; those retrieval probes showed what it actually had.

We changed the archive ingest path around that evidence:

• the never-pruned beacon block is the authority for which versioned hashes must exist at a slot;
• the local beacon node is one possible byte source, never the authority on absence;
• a separately operated historical archive supplied bytes below Prysm’s measured frontier; and
• every fetched blob was KZG-anchored against the commitment in the beacon block before entering BlobArchive.

That combination recovered the complete Dencun-to-present history without asking an empty response to prove that a blob never existed.

What BlobArchive changes

BlobArchive separates specialized acquisition from ordinary consumption.

A writer operator runs the Ethereum-facing indexers, maintains each L2’s posting-source schedule, acquires complete blobs, verifies them, and signs the resulting archive heads. This operator needs a measured complete-blob path: an appropriate consensus-client mode, historical providers, or a combination.

A follower or replica operator authenticates a selected writer and retains the chosen archive over the IPFS swarm. The follower can serve a local beacon-compatible endpoint to an L2 node without running an Ethereum execution client, consensus client, validator, semi-supernode, or supernode.

That does not eliminate the resource cost. It moves the expensive acquisition work to explicit operators and lets many L2 nodes share and independently retain the verified result. It also makes the trust boundary inspectable: followers pin a writer authority, and independent writers can re-derive the same head and compare exact roots at equal coverage.

There is one important common-mode caveat. Two writers that both rely on the same incomplete upstream are not independent evidence of completeness. Meaningful redundancy requires independent derivation and independently measured acquisition paths, not merely two signatures over copied data.

That is the distinction Fusaka makes unavoidable: ordinary validation can be light, but complete retrieval has to be built, measured, and shared deliberately.