Content storage

The consensus layer stores only message metadata (~100–500 bytes per message). File content — blobs, trees, and full commit messages — lives in external storage chosen by the developer.

Architecture#

Developer                Makechain Consensus          Content Storage
   │                           │                        │
   ├─ Upload blobs ───────────────────────────────────► │
   │   (returns URL + digest)  │                        │
   │                           │                        │
   ├─ COMMIT_BUNDLE ──────────►│                        │
   │   (content_digest + url)  │                        │
   │                           ├─ Include in block      │
   │                           │                        │
   Consumer                    │                        │
   │                           │                        │
   ├─ Read commit metadata ◄──┤                        │
   ├─ Fetch blobs via url ──────────────────────────► │
   ├─ Verify content_digest    │                        │
   │                           │                        │

Content digest and URL#

A COMMIT_BUNDLE may include two optional fields:

• content_digest — a 32-byte hash serving as an integrity proof for the referenced content
• url — a content locator string (max 2048 characters) pointing to the uploaded data

Both fields are self-attested by the submitter. Validators do not fetch or verify the referenced content. Clients verify integrity offline by comparing the fetched content's hash against the content_digest.

These fields link consensus-layer metadata to the full data:

Content lifecycle#

1. Upload — the developer uploads tree and blob data to external storage, receiving a URL and computing a content digest
2. Submit — the developer submits a COMMIT_BUNDLE with content_digest, url, and commit metadata
3. Finalize — validators include the bundle in a block, storing metadata in consensus state
4. Retrieve — consumers read metadata from consensus, fetch full data via url, and verify against content_digest

Recovery from pruning#

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

• Pruned CommitMeta entries lose their hash, title, and parent links from validator state
• External storage retains the complete blob data (subject to storage provider retention policies)
• The content_digest allows integrity verification of recovered data

Storage limits on validators do not cause permanent data loss.

Storage backend options#

The content storage backend is chosen by the developer. Options include: