docs / walkthrough · updated 2026-08-01

How BlobArchive works

BlobArchive preserves EIP-4844 blobs after ordinary beacon nodes stop serving them. It does this without inventing a new blob format: every blob is stored as one raw IPFS block, indexed by an immutable DAG, and distributed over libp2p/Bitswap.

The public deployment has five distinct jobs:

Indexers decide what belongs in a head. A BlobArchive writer operator runs the indexers. The all indexer follows finalized beacon history. A chain indexer follows a published source schedule—for example, Arbitrum One inbox events—and selects only the versioned hashes that chain referenced.
A private writer fetches, commits, and signs. The same writer operator runs bloard, which verifies blob identity, updates the content-addressed heads, applies retention policy, and signs one publication document. The signer and ingest credential stay off the public process.
A public edge verifies and serves. The edge has read-only access to immutable archive blocks. It accepts only a document and IPNS record that satisfy the pinned signer, archive, head, and edge-identity contract, then provides the document before publishing the IPNS record. It cannot sign a replacement document or mutate the archive.
Discovery locates that publication. DNSLink points to an IPNS name. IPNS authenticates an exact document CID. The publication document carries a separate Ed25519 signature and the public edge’s libp2p addresses.
Replicas retain and serve. A BlobArchive follower/replica operator runs an embedded follower or standalone Kubo replica. It authenticates the publication, fetches selected DAGs over Bitswap, applies local retention policy, and can expose a beacon-compatible read endpoint to an L2 node.

If DNSLink, IPNS, the DHT, libp2p, or Bitswap are unfamiliar, read how BlobArchive uses IPFS before the deeper trust and retention sections.

Ethereum execution + beacon data
                 |
                 v
          chain indexers
                 |
                 v
       writer: immutable DAGs
                 |
        signed publication bundle
                 |
                 v
      read-only public edge
       (Bitswap + DHT/IPNS)
                 |
       DNSLink -> IPNS -> CID
                 |
                 v
     libp2p/Bitswap archive swarm
          /                 \
 embedded follower       Kubo replica
          \                 /
             local beacon API
                 |
                 v
          Nitro or another client

Availability validation and complete retrieval are different jobs

PeerDAS made ordinary Ethereum consensus nodes lighter by letting each node sample and custody a subset of 128 data columns. That is enough to validate data availability without requiring every node to download every complete blob. Reconstructing a blob requires at least half of the columns.

Consequently, an ordinary post-Fusaka beacon node may be healthy and fully participating in consensus while being unable to answer a complete blob request. Complete serving is a deliberate higher-custody role; for example, Lighthouse documents separate semi-supernode and supernode modes. Retaining those complete blobs beyond the normal custody window is a further, independent choice.

BlobArchive puts that specialized acquisition work at the writer. Followers and replicas receive the resulting authenticated archive over the swarm. They do not need an Ethereum execution client, consensus client, validator, semi-supernode, or supernode to serve their selected archive locally.

Operational roles, sometimes held by one operator

The architecture separates responsibilities even when one person or organization holds several of them:

Role	Responsibility
L2 chain owner	Defines and announces the chain’s canonical posting mechanism, contracts, and allowed posters.
L2 node operator	Runs the rollup node and configures its primary beacon blob API.
BlobArchive writer operator for that L2	Tracks the chain owner’s posting changes, maintains the append-only source schedule, derives the filtered head from Ethereum, signs it, and keeps mutation authority private.
Public edge operator/process	Serves read-only blocks and relays only verified signed publication state onto public libp2p/DHT/IPNS, without the signer or ingest credential.
BlobArchive follower/replica operator	Selects and pins a writer authority, retains its chosen heads, serves the local blob API, and monitors local availability and integrity.

The L2 node operator and follower/replica operator will commonly be the same person or organization: the archive runs next to the node that consumes it. The writer operator is a separate trust role even when the chain owner or node operator also chooses to run a writer. The public edge is usually operated by that same organization, but it is intentionally a separate compromise domain.

Writers are permissionless; project defaults are curated

Anyone can run a writer, publish its signed document through IPNS, put DNSLink under a domain they control, and distribute a follow profile that pins their signer. Any follower operator can select it. Neither side needs project approval or a blobarchive.net name.

If an L2 is not yet represented in the project’s built-in profiles, its owner, infrastructure providers, or community operators should launch writers now rather than wait. They can publish under their own domains and serve fully functional followers immediately.

The project reviews only what it controls: names under blobarchive.net, profiles embedded in released binaries, and writers presented as project defaults. That curation is a recommendation and distribution policy, not admission to the protocol. The follower operator remains the final authority by choosing exactly which DNSLink and signer to trust.

Where decentralization lives

BlobArchive decentralizes publication, storage, and serving without pretending trust disappears: anyone may publish, anyone may replicate, any connected peer may serve authenticated bytes it retains, and every follower chooses which writer to trust.

Different layers decentralize different things:

Layer	What is decentralized	What authority remains
Publication	Any operator can derive heads, sign a document, publish through IPNS, and distribute a profile.	Each writer remains authoritative only for claims under its own signer.
Discovery	IPNS and bounded provider/rendezvous records travel through the DHT.	A DNSLink domain owner controls that human-readable name.
Storage and serving	Read-only public edges, embedded followers, and Kubo replicas can retain and serve the same CID-addressed blocks.	Each node operator chooses retention, exposure, and availability policy.
Verification and trust selection	Every follower verifies locally and chooses its own signer pins and replay floors.	Trust is explicit rather than eliminated: the selected writer still claims which blobs belong in a filtered head.
Derivation	Independent writers can reproduce a head from Ethereum inputs and compare roots at equal coverage.	Replicas that merely copy one writer share its completeness assumptions and upstream failure modes.
Project defaults	A follower can ignore, replace, or extend every shipped default locally.	The project deliberately curates `*.blobarchive.net`, its embedded catalog, and its recommendations.
Consumption	Every L2 operator can serve its own local beacon endpoint.	That operator owns local uptime instead of delegating it to one hosted project API.

The important distinction is: replicas decentralize availability; independently deriving writers decentralize completeness assurance. More copies of one writer make its bytes harder to lose, but they do not independently prove that its source schedule selected every blob it should have selected.

blobarchive.net is therefore a curated discovery convenience, not a protocol gate or the network itself.

Heads are views, not copies

A head is a deterministic index from (slot, versioned hash) to blob content. The initial production archive publishes:

all, containing every finalized Ethereum mainnet blob;
arbitrum-one, containing blobs selected by Arbitrum One’s published source schedule;
robinhood, another filtered finalized head; and
base, containing blob transactions sent to Base’s batch inbox by the sender authorized in Base SystemConfig; and
unfinalized, one small, bounded mutable snapshot used by local live views.

The same blob bytes have the same CID in every head. If all and arbitrum-one both reference a blob, the store still contains one block. Filtered heads add small index nodes, not another copy of the payload.

Every finalized head advances independently and carries its own coverage frontier. Its root CID commits to the full index below that frontier. The filter schedule is committed separately by an append-only manifest chain, so an independent writer operator can reproduce both the selected data and the rule that selected it.

See heads and retention for the physical layout and storage choices.

Content addressing proves bytes, not completeness

Content addressing gives strong local answers:

a CID commits to exact bytes;
immutable index links cannot be changed without changing the root;
a full verification pass can recompute a blob’s KZG commitment and versioned hash; and
two independently derived roots at equal coverage either match or expose a disagreement.

It cannot prove that a writer included every blob it should have included. A valid DAG can consistently omit data. Completeness therefore depends on the published source schedule and independent re-derivation from Ethereum data. That boundary is explicit rather than hidden behind the word “trustless.”

The public service is the swarm

The initial public service is libp2p/Bitswap plus authenticated publication discovery. BlobArchive does not host a public HTTP beacon endpoint. Follower/replica operators run their own local archive endpoint; L2 node operators point their clients at it.

That division keeps network replication permissionless while giving each follower/replica operator control over:

which writer authority to trust;
which heads to retain;
whether to keep full history or a bounded window;
local HTTP exposure and admission limits; and
independent verification and local monitoring.

Start with the L2 guide if the archive is an L2 node’s primary blob API. To operate the local archive, choose an embedded follower or a Kubo-backed replica.

Normative details live in the design and protocol specification.