Consensus decides the authoritative order of record identities, versions, state roots, and mutations. Manifests and availability services carry the larger bodies outside that agreement loop.
The manifold's memory
Versioned data returns
answers with receipts
State is where most systems quietly ask for trust back. Astrea's data layer refuses: records carry stable identities, explicit versions, and authenticated roots, so a read comes back with evidence instead of a server's word. Heavy content — attachments, documents, proof material — moves outside the agreement path, while a small authenticated record called a manifest pins down exactly which bytes belong to it.
01 · the lineage
The database blockchains never had
Chains store bytes under keys, and anything smarter — fields, indexes, queries — gets bolted on as a separate service you have to trust. Building a production database from scratch is hard enough that nobody has ever built one into a blockchain. Astrea did, and it did not start from zero: the data layer is built on three ideas that have carried the web's data for twenty years.
MapReduce Google, 2004
Split a huge job into independent pieces, run them all at once, combine the results. Google published the pattern in 2004; it became Hadoop and the big-data stack behind the web's largest services. Astrea's deterministic summaries are this idea with a receipt attached.
Cassandra storage engine
Cassandra is the distributed database built at Facebook and hardened for over a decade at internet scale: write to a log first, hold recent writes in memory, flush immutable sorted runs, compact in the background. Astrea's storage engine is designed off that architecture.
Documents the MongoDB model
MongoDB taught developers to expect records shaped like documents — named fields, versions, attachments, indexes — instead of bare rows. Astrea keeps that record model (document-shaped, not wire-compatible) and gives every record an authenticated fingerprint.
This is what makes the layer a new generation of data availability. Most designs treat availability as a hope: post the bytes somewhere and assume they stay. Astrea treats it the way the manifold treats everything — state has versions, versions have certified roots, heavy bytes are pinned by manifests, and every answer can carry proof. A web-scale engine underneath, verification on top.
One record carries its context
An Astrea application can treat a profile, message, payment object, or document as one named record with fields, a version, and an authenticated fingerprint. Attachments can live elsewhere while the record says exactly which bytes belong to it.
record_idmessage:8f…
version42
fieldssender · recipient · created_at
bodyreference:2a…
indexesrecipient · created_at
root71d9… · certifies this record at version 42
From a write to a verifiable read
Seven connected layers carry a record from authoritative ordering to an answer the client can check.
A manifest is a small authenticated description of a larger body: its identity, digest, layout, and retrieval requirements. The body can live outside the hot path while the manifest binds what counts as the right bytes.
A journal is an append-only sequence of accepted mutations. Replicas, indexes, and repair services consume it in order to catch up from a known checkpoint.
A log-structured merge tree (LSM) is a local storage pattern: record the write in a log, collect it in memory, flush immutable sorted runs, then compact those runs in the background.
A versioned Authenticated Sparse Tree (AST) turns each named snapshot into one root. Astrea uses a 16-way sparse tree for most authenticated application data and supplies point inclusion and absence proofs.
Registered indexes can update atomically with authoritative state. A derived index carries an index watermark: the latest checkpoint or version it has fully processed, so a reader can see how current its view is.
A proof-backed read returns an answer with evidence that the client checks against a certified root. The server can be fast and convenient without becoming a source of truth.
02 · Local storage
Fast writes, stable authenticated meaning
The local data engine follows the LSM pattern because it turns many small random writes into sequential work. Compaction can reorganize storage files while the canonical record, version, and authenticated root remain unchanged.
Write-ahead log
The engine records the operation before treating it as a visible durable write.
Memtable
An ordered in-memory table serves recent writes while they wait to be flushed.
Sorted table
A flush writes an immutable sorted run that can be scanned and merged predictably.
Compaction
The engine merges runs and removes obsolete physical entries while respecting retained versions.
LOCAL BYTE ORGANIZATION · AUTHENTICATED MEANING
write → verified read
Storage boundary
The application data engine runs locally in each process, while node-local consensus metadata uses a separate RocksDB-backed store. Astrea's service plane connects these focused engines through authenticated replication, availability, and repair.
03 · Deterministic summaries
Large reads reduce to bounded answers
A controlled query path
For a registered query such as “count records by status,” workers can summarize bounded pieces and combine neighboring summaries in a canonical order. The same snapshot and the same reducer rules produce the same final answer.
Each registered query uses a declared reducer with a bounded input shape, deterministic output, and combination law. Workers can split the input flexibly while the reducer keeps the final answer stable.
records
0…99 · 100…199
0…99 · 100…199
→
partial counts
{active: 61} · {active: 58}
{active: 61} · {active: 58}
→
canonical reduction
{active: 119}
{active: 119}
Semantic transaction concurrency governs which state operations may run together. This reducer keeps chunks in canonical interval order even when worker assignments or grouping change. PixelVM proof compression then produces a verifier-facing artifact from proof pieces.
Evidence path
A reducer receipt does not prove state membership by itself. An authoritative answer also needs the registered snapshot root and the proof path that binds the reducer's input to that root.
04 · Authenticated reads
The client checks the answer
This is where replacing trust with proof reaches the reader. A query server can answer quickly; certified state supplies the authority. For a point lookup, the client receives the requested value or an absence result, a tree proof, the snapshot version, and the certified root it expects.
Named key
The client asks for one record or indexed key at a declared snapshot.
Value or absence
The server returns the canonical value, or says that no value occupies that point.
AST path
Sibling commitments let the client recompute the expected root for that point.
Certified root
The answer is accepted only when the recomputed root matches the certified snapshot.
A derived search response also states its index watermark. The watermark names the authoritative prefix the view has processed, so the reader can judge its freshness against the requested version.
Proof boundary
The database adapter supplies canonical point inclusion and point absence proofs. Ordered page and key-range questions use a registered index and evidence design built for that job. Point proofs remain point proofs rather than being relabeled as range evidence.
05 · Versioned authentication
One root for every named snapshot
A tamper-evident history
The AST maps a canonical key digest through sixteen choices at each level. A changed value changes the path above it and therefore changes that version's root. Retained roots let a client ask about an exact historical snapshot.
v40 · 92a1…→
v41 · 06bc…→
v42 · 71d9…
One 16-way level · selected branch 9
0123
4567
89AB
CDEF
Versioned ASTs are Astrea's preferred structure for most authenticated application data. The explicit version belongs to the meaning of the state, while retention policy decides which historical material remains locally available.
MPT compatibility lives at the proof boundary
Where compatibility requires it, “MPT-compatible” fixes the meaning of inclusion, exclusion, and page proofs. Astrea keeps its versioned AST as the storage structure and exposes the proof shapes defined at the applicable boundary. Ethereum keeps its state in a Merkle Patricia trie, which is why this boundary matters for the bridge: a venue's state root arrives through a proof of the beacon chain's finalized checkpoint and is checked in the shape Ethereum defines, and Zcash's note-commitment root arrives through a proof of the Zcash chain itself, which is what a deposit is credited against.
Sui's object-versioning documentation offers a familiar example of explicit versions: an object is referenced by ID and version, and a mutation writes the same ID at a new version. Astrea applies that useful intuition to authenticated application state. The analogy stops at explicit versioning; Astrea's tree and storage engine are its own.
06 · Manifests and availability
Manifests authenticate large bodies
A message body, attachment, archive segment, ciphertext, or proof package can be much larger than the fact consensus needs to order. An authenticated manifest binds the body while consensus carries its compact identity, version, and root relationship.
Root
Choose a snapshot
The named AST version fixes the certified root for this read.
Manifest
Follow the binding
Authenticated state identifies the manifest for the larger object.
Body
Retrieve the bytes
The service plane fetches a candidate body outside consensus.
Check
Match the commitment
The reader accepts the body only when its bytes match the manifest.
AUTHENTICATED MANIFEST · RETRIEVAL · BYTE CHECK
large bodies stay off the hot path
Commitment
The manifest fixes which bytes belong to the object. A different body will not match its digest and declared layout.
Retrieval
Availability policy determines where a body can be fetched and what evidence a reader or maintainer requires before relying on it.
Catch-up and repair
The journal tells a replica what changed after its checkpoint. Manifests identify missing bodies, and the service plane retrieves or repairs them without rewriting consensus history.
Availability boundary
A matching hash proves that retrieved bytes are the committed bytes. The hash alone does not prove that any provider currently holds or will deliver them. Availability requires the declared storage, custody, retrieval, and repair path.
07 · Clean separation
Authenticated data works across three layers
Authenticated meaning Roots
Canonical records, versions, registered mutations, indexes, and proofs define what a state claim means.
Local mechanics Bytes
Logs, memtables, sorted runs, compaction, caching, and retention organize bytes efficiently on one node.
Service distribution Reach
Replicas, indexers, query servers, providers, and repair workers make authenticated data useful at network scale without becoming consensus.