blobarchive.net

docs / guide · updated 2026-08-01

BlobArchive for L2s

BlobArchive is for anyone responsible for an L2 node’s blob access: a home hobbyist, a professional RPC provider, an L2 owner running chain infrastructure, or an operator anywhere between those scales.

An L2 node operator can use a local BlobArchive endpoint as the node’s primary beacon blob API during normal operation. The same endpoint retains historical blobs beyond Ethereum’s ordinary blob-retention window, so rebuilding or recovering the L2 does not require switching to a separate archival service.

BlobArchive implements the beacon blob retrieval route needed by L2 clients; it is not a general-purpose consensus beacon node. A BlobArchive follower/replica operator runs it inside the local infrastructure boundary so the primary HTTP dependency is local. That operator is often the same person or organization as the L2 node operator, but the role is distinct from the writer that publishes the archive.

The L2 chain owner controls or announces canonical posting-mechanism changes. The BlobArchive writer operator for that L2 tracks those changes, maintains the source schedule, derives the filtered head from Ethereum, and signs its publication. A public deployment relays that signed state through a separate read-only edge, keeping archive mutation and signing authority off the Internet-facing process. See the operational-role overview before assigning responsibilities.

Why not just use an ordinary beacon node?

You can use a beacon endpoint when it can return the complete blobs your L2 asks for. Do not assume that every healthy post-Fusaka consensus node has that capability.

PeerDAS lets an ordinary node validate availability while downloading and custodying only a subset of the 128 data columns. At least half of the columns are required to reconstruct a complete blob. Client-specific semi-supernode or supernode modes can provide that current-window retrieval, but long-term retention is a separate setting and does not retroactively acquire blobs the node never stored. The Lighthouse data-column guide shows these as distinct serving, retention, and fresh-backfill controls.

A local BlobArchive follower or replica gives the L2 node one primary beacon-compatible blob endpoint for both live operation and historical recovery. The follower/replica operator does not need to run an Ethereum execution client, consensus client, validator, semi-supernode, or supernode. The selected writer operator bears the specialized acquisition cost once. Its read-only public edge publishes the authenticated result to the swarm without holding the writer’s signer or mutation credentials.

Use your chain’s live view

The recommended production choice for an L2 node operator is that chain’s live profile:

ethereum-mainnet-arb1-live-a
ethereum-mainnet-robinhood-live-a
ethereum-mainnet-base-live-a

Each profile exposes one local live view that joins:

This is near-live rather than per-slot real-time delivery. Writers publish authenticated generations in batches, and the shipped followers poll once per minute. In normal steady state, an L2 node should expect its local view to learn about new blobs roughly one to two minutes after the source sees them. Public DHT conditions and bounded retries can occasionally extend that delay to several minutes. These are healthy-path expectations, not a ceiling. A publication outage can keep returning a valid but frozen generation for much longer, so alert on the age of the last accepted generation rather than on request errors. Initial synchronization and catch-up after downtime are separate and can take much longer.

All L2 live profiles use the same physical unfinalized set. The chain-specific view filters requests against its finalized head and requires exact versioned hashes for provisional blobs. The L2 client therefore uses one endpoint through the finalized-to-live handoff instead of switching heads itself.

The other profiles are deliberate alternatives:

The all profiles require substantially more disk but reduce dependence on any one L2 filter having been complete. Every profile name identifies an explicit writer authority; there is no bare alias that silently moves between writers.

Use it as the primary blob endpoint

The public network service is Bitswap, not a hosted beacon API. How BlobArchive uses IPFS explains how discovery, peer connections, and block transfer produce the local endpoint. Run either:

Point the L2 client at that node’s loopback or private-network beacon endpoint. For Nitro, configure the local live view directly:

--parent-chain.blob-client.beacon-url=http://127.0.0.1:8550/live

Nitro then uses BlobArchive for ordinary blob fetches as well as historical recovery. A fallback is optional rather than required; if the L2 node operator chooses one, keep the policy explicit instead of hiding endpoint selection in DNS.

Understand the assurance boundary

BlobArchive verifies:

It does not prove that the writer’s filter schedule included every legitimate posting source. For a filtered head, completeness is relative to the published manifest.

This makes an unhandled posting change a liveness failure, not an integrity failure. If the L2 chain owner changes its allowed poster and the BlobArchive writer operator does not update the source schedule, the filtered head can omit the new poster’s blobs even while its coverage number advances. An L2 node asking for one of those exact versioned hashes remains unable to progress, but Bloar does not substitute or authenticate a different blob: CID, KZG, and versioned-hash verification still fail closed.

The BlobArchive writer operator for that L2 is responsible for monitoring the chain owner’s posting mechanism and updating the published source schedule. That operator must test end-to-end blob inclusion, not coverage alone. A follower/replica operator can verify the writer’s signed claims and report that a requested blob is missing, but cannot infer an allowed poster that the writer omitted from its own schedule.

Trust writers explicitly—or run one

Each writer publishes under its own signer, DNSLink/IPNS authority, and versioned follow profile. A follower/replica operator chooses that authority explicitly and pins its signer; the node does not silently trust whichever writer is newest, merge claims from several writers, or use a majority vote.

This makes the completeness trust visible and replaceable. L2 chain owners, L2 node operators, infrastructure providers, and community operators can run independent writers, derive the same head directly from Ethereum inputs, and publish under their own keys and names. Comparing equal roots at equal coverage is a deterministic check only when the second writer performed that independent derivation rather than copying the first writer’s claims.

Run a writer if your L2 depends on this assurance. Independent writers add both operational redundancy and an external check on source-schedule completeness. If your L2 is not in the project’s defaults, do not wait: publish under your own domain and signer, distribute a local follow profile, and point your followers at it. No project review is required.

Running a follower decentralizes storage, serving, and local availability. Running an independently deriving writer also decentralizes completeness assurance. A second writer that merely copies the first adds another replica, not an independent check.

Review applies only if you also want a name under blobarchive.net or inclusion in the follow profiles shipped by the project. See discovery and trust for the verification boundary and contact the project for that optional curation path.

Posting-mechanism changes

An L2 chain owner may move posting from a contract event stream to blob transactions sent by an allowlisted EOA, rotate that EOA, or replace the contract. The chain owner should announce the authoritative transition block; the BlobArchive writer operator applies it to the archive schedule.

BlobArchive represents this as an append-only source schedule:

Past covered history cannot be silently reinterpreted. If a transition was missed, recovery is explicit: backdate the source transition to the exact L1 block, have the writer operator truncate the writer to before the missed range, publish the correct successor schedule, then deterministically rescan. Followers keep serving their last accepted generation and do not roll backward with the writer; they adopt the repaired generation after it advances beyond their accepted coverage and passes the existing trust floors.

See the missed-source recovery runbook before performing such a repair.

Production checks

The role-based monitoring reference lists the exported signals and starting alert conditions for embedded followers, Kubo replicas, and writer deployments.

The BlobArchive writer operator should alert on:

The BlobArchive follower/replica operator—and usually the colocated L2 node operator—should alert on:

Keep one non-empty historical blob as a byte-exact regression anchor. A successful HTTP status alone is not an archive-integrity test.

Failure behavior to preserve

Correctness is fail closed:

That behavior is the main reason to operate the archive locally: the L2 node operator owns local availability policy, while the selected BlobArchive writer operator remains accountable for source-schedule completeness.