Content Storage

The consensus layer stores only message metadata (~100–500 bytes per message). Actual 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: Developer uploads tree and blob data to external storage, receiving a URL and computing a content digest
2. Submit: Developer submits a COMMIT_BUNDLE with content_digest, url, and commit metadata
3. Finalize: Validators include the bundle in a block — metadata is stored 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

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

Storage Backend Options

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