Diff: infrastructure/worm-ledger-storage-architecture
From 1c02ec1 to 1c02ec1
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| type: topic | type: topic |
| content_type: topic | content_type: topic |
| slug: worm-ledger-storage-architecture | slug: worm-ledger-storage-architecture |
| short_description: "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." | short_description: "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." |
| title: "WORM ledger storage architecture" | title: "WORM ledger storage architecture" |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: current-fact | bcsc_class: current-fact |
| language: en | language: en |
| paired_with: worm-ledger-storage-architecture.es.md | paired_with: worm-ledger-storage-architecture.es.md |
| category: infrastructure | category: infrastructure |
| status: active | status: active |
| quality: complete | quality: complete |
| last_edited: 2026-05-25 | last_edited: 2026-05-25 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| --- | --- |
| The WORM ledger storage architecture describes how the [[worm-ledger-design|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 [[worm-ledger-architecture|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. | The WORM ledger storage architecture describes how the [[worm-ledger-design|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 [[worm-ledger-architecture|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. |
| ## 1. The tile-based storage engine | ## 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). | 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. | * **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`). | * **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. | * **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. |
| ## 2. Dual-target runtime envelopes | ## 2. Dual-target runtime envelopes |
| The architecture is designed to support two distinct operational environments using the same codebase: | The architecture is designed to support two distinct operational environments using the same codebase: |
| ### Envelope A: Hosted Daemon (Current) | ### 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. | 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. |
| ### Envelope B: seL4 Unikernel (Intended) | ### 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. | 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. |
| ## 3. Cryptographic and compliance alignment | ## 3. Cryptographic and compliance alignment |
| The storage engine is engineered to satisfy strict regulatory requirements: | 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. | * **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. | * **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. | * **SOC 2 Processing Integrity:** Provides verifiable audit trails through a dedicated sub-ledger that records every read event. |
| ## 4. Portability and sovereignty | ## 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. | 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. |
| ## See also | ## See also |
| - [[worm-ledger-architecture]] — the four-layer architectural overview: tile storage, WORM API, wire protocol, anchoring | - [[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 | - [[worm-ledger-design]] — regulatory compliance mapping and customer key sovereignty rationale |
| - [[service-fs-architecture]] — the `service-fs` implementation that applies this storage architecture in production | - [[service-fs-architecture]] — the `service-fs` implementation that applies this storage architecture in production |
| - [[cryptographic-ledgers]] — the broader cryptographic ledger context for the C2SP tlog-tiles format | - [[cryptographic-ledgers]] — the broader cryptographic ledger context for the C2SP tlog-tiles format |