Diff: infrastructure/worm-ledger-storage-architecture
From f76ce0d to f76ce0d
+50 / −0 lines
| Before | After |
|---|---|
| --- | |
| schema: foundry-doc-v1 | |
| type: topic | |
| slug: worm-ledger-storage-architecture | |
| title: WORM Ledger Storage Architecture | |
| audience: vendor-public | |
| bcsc_class: current-fact | |
| language: en | |
| paired_with: worm-ledger-storage-architecture.es.md | |
| --- | |
| Foundry’s storage architecture is built on the principle of structural immutability, ensuring that data archives remain tamper-evident and readable for the long term. This document synthesizes the engineering decisions behind the tile-based storage engine and the transition from hosted environments to verified microkernels. | |
| ## 1. The Tile-Based Storage Engine | |
| Foundry adopts the **C2SP tlog-tiles** specification as its fundamental storage primitive. This format, utilized 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:** In alignment with Doctrine Pillar 1 (DARP), 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. | |
| ## 2. Dual-Target Runtime Envelopes | |
| The architecture is designed to support two distinct operational environments using the same codebase: | |
| ### Envelope A: Hosted Daemon (Current) | |
| Running as a standard Linux/BSD process, `service-fs` utilizes 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) | |
| 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 | |
| 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. | |
| ## 4. Synthesis of Innovation | |
| The primary innovation in Foundry’s storage layer is the integration of high-performance verifiable logs with a "sovereign-first" deployment model. Unlike legacy WORM solutions that require proprietary hardware or specific cloud vendors, Foundry’s tile-based logs are portable, open-standard, and self-verifying across any hardware from a virtual machine to an seL4-hardened Totebox appliance. | |
| ## See Also | |
| - [[worm-ledger-architecture]] | |
| - [[worm-ledger-design]] | |
| - [[service-fs-architecture]] | |
| - [[cryptographic-ledgers]] |