blobarchive.net

docs / walkthrough · updated 2026-08-01

Discovery and trust

BlobArchive discovery is a chain of separately authenticated statements:

DNS TXT
  _dnslink.<name> = dnslink=/ipns/<ipns-name>
             |
             v
signed IPNS record -> /ipfs/<publication-document-cid>
             |
             v
exact publication bytes
             |
             v
Ed25519 document signature + local durable floors

No single layer is asked to prove everything.

For a plain-language explanation of the network components beneath this trust chain, start with how BlobArchive uses IPFS.

Publishing does not require permission

There is no writer registry in the protocol. Any operator can:

  1. run a writer and derive heads from Ethereum;
  2. sign a publication document and IPNS record, then relay both through a read-only public edge;
  3. set DNSLink under a domain it controls; and
  4. distribute a follow profile naming that DNSLink and signer.

A follower operator authorizes that writer by deliberately selecting the profile. The writer does not need a blobarchive.net record or inclusion in the built-in catalog.

The project-controlled namespace and shipped profiles are curated defaults. Adding a writer there is human-reviewed because it associates the project with that exact identity and policy. It does not make the writer more valid at the protocol layer, and omission does not make an independently published writer less functional. An L2 without a project-hosted default can publish and follow its own writer immediately.

DNSLink is one TXT lookup. Its value names an IPNS key; it does not point directly at an archive root or a server.

The record’s TTL is a cache lifetime, not an expiry. Deleting or revoking the credential that edited the record does not delete the record. DNS authority is therefore production trust infrastructure and must have an explicit rotation and removal procedure.

The default resolver does not itself authenticate DNSSEC. The shipped profiles limit the consequence by independently pinning the publication signer.

IPNS authenticates an exact document CID

The IPNS record is signed by its own key and sequence-numbered. It points to the CID of the exact publication document bytes. A higher IPNS sequence is a newer transport statement, not permission to regress the archive claim inside it.

The private writer constructs and signs both the publication document and its IPNS record. A separate public edge verifies their signer, network, archive, head policy, sequence, revision, document CID, and advertised edge identity. It then provides the exact document CID before putting the signed IPNS record into the DHT. The edge has no publication signing key and read-only access to immutable archive blocks, so compromising it cannot mint a replacement claim or mutate the archive.

The writer operator periodically sends unchanged signed state through that edge to refresh validity and can send a new revision immediately after a head update. Provider records and IPNS records have finite lifetimes, so a sleeping writer or edge can disappear from discovery while the durable archive remains intact.

The publication document identifies the archive state

One signed document describes the archive’s network, logical archive ID, revision, public-edge libp2p addresses, and every physical head. A head entry includes its root and coverage. Filtered finalized heads may also carry the CID of their append-only source manifest.

The document is signed with Ed25519 over canonical JSON. The signature authenticates that writer operator’s statement. It does not make an omitted blob appear or establish that the writer operator’s source schedule was complete.

Writer acquisition remains a trust boundary

A writer must first obtain complete blob bytes. Post-Fusaka, a healthy ordinary consensus node may custody too few data columns to reconstruct them, and a node configured for future retention may still lack history it never acquired. A writer operator therefore measures its actual serving frontier and anchors every accepted blob against Ethereum’s commitments instead of trusting an HTTP status or an “archive” label.

This is also a common-mode boundary between writers. Two independently signed heads do not provide independent completeness evidence if both writers copy the same first writer or depend on the same incomplete upstream. A meaningful cross-check re-derives the head from Ethereum inputs and independently verifies the acquisition path. Exact roots at equal coverage are then strong evidence of agreement; they are not a substitute for that independence.

Decentralization does not remove trust

Running more followers and replicas distributes storage, serving capacity, and failure domains. Any connected peer holding a requested CID can supply the same authenticated bytes, and an L2 operator can keep its primary blob endpoint local instead of depending on one hosted service.

That is availability decentralization. It does not independently check the writer’s decision about what belongs in a filtered head. One hundred replicas of one writer still inherit that writer’s source schedule and acquisition assumptions.

Completeness assurance becomes more decentralized only when another writer independently derives the head from Ethereum inputs, uses an independently verified acquisition path, and publishes under its own signer. Equal roots at equal coverage then corroborate the result; disagreement becomes visible instead of being copied through the replica fleet.

Trust has not vanished. It has become explicit, scoped, replaceable, and locally enforced:

The shipped default pins the signer

Follow profiles support two trust modes:

Production profiles ship in dnslink+signer-pin mode. The initial signer fingerprint is:

6698f6c8767529ffb725ce5201a86602106cc87ed7c9129a649428ca0ea6d7b5

Signer changes therefore require a new reviewed and versioned follow profile. Changing DNS alone is insufficient.

Durable floors make rollback local

A follower/replica operator’s node persists the facts it has already accepted. Among them are:

A valid old document is still old. Restarting the process, restoring DNS, or changing transport does not lower these floors. An equal revision with different bytes is equivocation; an unexpected signer, manifest predecessor, coverage regression, or incompatible root is refused rather than hidden.

updated_at is diagnostic for revisioned publications. It changes after a successful poll even when a followed head does not move, so whole-response byte identity is not a valid continuity test across a successful poll.

Discovery is not availability

A DHT provider result, relay reservation, DNS response, or signed IPNS record can locate a peer without proving a usable data path. Every fetched byte still has to pass the content, signature, replay, and coverage checks.

The field tests observed exactly this boundary: cellular observers repeatedly resolved signed records while direct archive transfer remained unavailable. The follower/replica operator should monitor and report discovery separately from reachability and fetch success.

For the exact wire rules, read specification §8 and the versioned follow-profile contract.