Data Availability

The consensus layer stores only message metadata (~100–500 bytes per message). Actual file content — blobs, trees, and full commit messages — lives in a separate data availability (DA) layer.

Architecture

Developer                Makechain Consensus          DA Layer
   │                           │                        │
   ├─ Upload blobs ───────────────────────────────────► │
   │                           │                        │
   ├─ COMMIT_BUNDLE ──────────►│                        │
   │   (da_reference = hash)   │                        │
   │                           ├─ DA sampling ─────────►│
   │                           │   (confirm availability)│
   │                           │◄──────────────────────┘│
   │                           │                        │
   │                           ├─ Include in block      │
   │                           │                        │
   Consumer                    │                        │
   │                           │                        │
   ├─ Read commit metadata ◄──┤                        │
   ├─ Fetch blobs ───────────────────────────────────► │
   │                           │                        │

DA Reference

Each COMMIT_BUNDLE includes a da_reference — a 32-byte hash identifying the erasure-coded blob data in the DA layer. This hash is opaque to the consensus layer; its interpretation depends on the DA backend.

The DA reference links consensus-layer metadata to the full data:

Consensus Layer (validators)	DA Layer (storage)
Commit hash, title, author, parents	Full commit message text
Tree root hash	Tree objects (directory listing)
DA reference	Blob objects (file content)

Blob Lifecycle

Upload: Developer uploads tree and blob data to the DA layer, receiving a da_reference hash
Submit: Developer submits a COMMIT_BUNDLE with the da_reference and commit metadata
Validate: Validators confirm the data is available via DA sampling before including the bundle in a block
Store: Consensus stores only the metadata; the DA layer retains the full data
Retrieve: Consumers read metadata from consensus and fetch full data from the DA layer

Recovery from Pruning

When consensus-layer commit metadata is pruned (see Storage Limits), the full commit data remains recoverable from the DA layer:

Pruned CommitMeta entries lose their hash, title, and parent links from validator state
The DA layer retains the complete blob data indefinitely (subject to DA-layer retention policies)
A node syncing from scratch can reconstruct pruned commit history by walking the DA layer

This separation ensures that storage limits on validators don't cause permanent data loss.

DA Sampling

Validators use DA sampling to confirm that blob data is actually available before including a COMMIT_BUNDLE in a block. This prevents a scenario where a developer submits metadata referencing data that doesn't exist.

The sampling mechanism integrates with the CertifiableAutomaton trait from commonware-consensus:

certify(digest) → bool

The default implementation returns true (no sampling). When DA sampling is enabled, certify() will check that all da_reference values in the proposed block are available in the DA layer before voting to finalize.

DA Backend Options

The DA backend is pluggable. Options under consideration:

Backend	Tradeoffs
Commonware `coding`	Erasure coding with availability sampling, native integration
Validator-operated storage	Content-addressed blob store run by the validator set
External DA (Celestia, EigenDA)	External trust assumption, may add latency
IPFS	Decentralized, but no availability guarantees

The initial implementation uses a simple content-addressed blob store. The da_reference is the BLAKE3 hash of the uploaded data.