WORM ledger storage architecture
TopicFrom the PointSav Documentation
The storage architecture adopts C2SP tlog-tiles as its fundamental primitive, supporting dual-target deployment from Linux daemons to seL4 microkernels while ensuring structural immutability and long-term readability through plain-text transparency and atomic durability.
The WORM ledger storage architecture describes how the platform’s immutable ledger persists data to disk — and why the specific format and write discipline matter for long-term regulatory compliance. The storage layer adopts the C2SP tlog-tiles specification as its fundamental primitive per the four-layer ledger architecture, producing a tile-based, append-only store that remains verifiable and human-readable with standard Unix utilities for at least a century.
[edit]1. The tile-based storage engine
The platform adopts the C2SP tlog-tiles specification as its fundamental storage primitive. This format, used by Sigstore Rekor and Google’s Certificate Transparency, breaks a Merkle tree into static, append-only files (tiles).
- Atomic Durability: Finalized tiles are written using a write-then-rename discipline followed by a mandatory
fsync. This ensures that partial writes never corrupt the ledger state. - Plain-Text Transparency: Following the DARP principle, tiles are stored as newline-delimited base64 text. This ensures that the storage remains inspectable using standard Unix utilities (
cat,base64,sha256sum). - MERKLE-Based Integrity: Every entry is chained into a Merkle DAG, allowing for efficient inclusion proofs and consistency checks without re-reading the entire ledger.
[edit]2. Dual-target runtime envelopes
The architecture is designed to support two distinct operational environments using the same codebase:
[edit]Envelope A: Hosted Daemon (Current)
Running as a standard Linux/BSD process, service-fs uses POSIX file I/O for storage. Per-tenant isolation is enforced through separate process address spaces and strict filesystem permissions.
[edit]Envelope B: seL4 Unikernel (Intended)
The long-term trajectory involves deploying service-fs as an seL4 Microkit Protection Domain. In this envelope, storage is mediated by moonshot-database (PSDB), where access is governed by formally verified microkernel capabilities.
[edit]3. Cryptographic and compliance alignment
The storage engine is engineered to satisfy strict regulatory requirements:
- SEC 17a-4(f): Satisfies the "WORM path" by structurally denying modification at the storage layer.
- eIDAS Qualified Preservation: Ensures 100-year readability through open-standard plain-text encodings and algorithm-agile hash functions.
- SOC 2 Processing Integrity: Provides verifiable audit trails through a dedicated sub-ledger that records every read event.
[edit]4. Portability and sovereignty
The tile-based logs are portable, open-standard, and self-verifying across any hardware — from a virtual machine running as a Linux daemon today to an seL4-hardened ToteboxOS appliance in a future deployment. No proprietary hardware and no specific cloud vendor is required to verify or restore the ledger.
[edit]See also
- worm-ledger-architecture — the four-layer architectural overview: tile storage, WORM API, wire protocol, anchoring
- worm-ledger-design — regulatory compliance mapping and customer key sovereignty rationale
- service-fs-architecture — the
service-fsimplementation that applies this storage architecture in production - cryptographic-ledgers — the broader cryptographic ledger context for the C2SP tlog-tiles format