Diff: infrastructure/worm-ledger-architecture
From cf72e67 to cf72e67
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| type: topic | type: topic |
| slug: worm-ledger-architecture | slug: worm-ledger-architecture |
| short_description: "The WORM ledger is an immutable, append-only substrate using cryptographic hash-chaining and structural isolation to provide a durable backbone for boundary-ingest services while maintaining tamper-evident records suitable for regulatory compliance." | short_description: "The WORM ledger is an immutable, append-only substrate using cryptographic hash-chaining and structural isolation to provide a durable backbone for boundary-ingest services while maintaining tamper-evident records suitable for regulatory compliance." |
| title: "WORM ledger substrate: four-layer architecture" | title: "WORM ledger substrate: four-layer architecture" |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: current-fact | bcsc_class: current-fact |
| language: en | language: en |
| paired_with: worm-ledger-architecture.es.md | paired_with: worm-ledger-architecture.es.md |
| category: infrastructure | category: infrastructure |
| --- | --- |
| `service-fs` provides the per-tenant Write-Once-Read-Many (WORM) immutable ledger that serves as the durable backbone for all Ring 1 boundary-ingest services. By enforcing a strict append-only invariant through cryptographic hash-chaining and structural isolation, the platform ensures that identity, communications, and document records remain tamper-evident and permanently accessible. | `service-fs` provides the per-tenant Write-Once-Read-Many (WORM) immutable ledger that serves as the durable backbone for all Ring 1 boundary-ingest services. By enforcing a strict append-only invariant through cryptographic hash-chaining and structural isolation, the platform ensures that identity, communications, and document records remain tamper-evident and permanently accessible. |
| ## Architectural Integration | ## Architectural Integration |
| The WORM ledger sits at the critical boundary between the per-tenant data plane and the multi-tenant knowledge plane. Every ingest service—including `service-people` and `service-email`—writes through this substrate, while Ring 2 services access data via cursor-paged MCP queries. | The WORM ledger sits at the critical boundary between the per-tenant data plane and the multi-tenant knowledge plane. Every ingest service—including `service-people` and `service-email`—writes through this substrate, while Ring 2 services access data via cursor-paged MCP queries. |
| * **Current Posture:** Isolation is achieved through separate daemon processes per tenant `moduleId` and rigorous filesystem permissioning. | * **Current Posture:** Isolation is achieved through separate daemon processes per tenant `moduleId` and rigorous filesystem permissioning. |
| * **Intended Trajectory:** Migration to seL4 microkernel-level capability enforcement is planned to provide formally verified tenant isolation. | * **Intended Trajectory:** Migration to seL4 microkernel-level capability enforcement is planned to provide formally verified tenant isolation. |
| ## Multi-Tier Protocol Stack | ## Multi-Tier Protocol Stack |
| The architecture utilizes a layered design to ensure that individual components remain swappable without disrupting the core durability contract. | The architecture utilizes a layered design to ensure that individual components remain swappable without disrupting the core durability contract. |
| ### Layer 4: Cryptographic Anchoring | ### Layer 4: Cryptographic Anchoring |
| Checkpoints are intended to be anchored monthly to the public Sigstore Rekor transparency log (per the fundamental physics of 2030 hyperscaler infrastructure). This provides external verifiability without exposing raw tenant data. | Checkpoints are intended to be anchored monthly to the public Sigstore Rekor transparency log (per the fundamental physics of 2030 hyperscaler infrastructure). This provides external verifiability without exposing raw tenant data. |
| ### Layer 3: Wire-Level Abstraction | ### Layer 3: Wire-Level Abstraction |
| Today, services communicate via axum-based HTTP with mandatory `X-Module-ID` headers. Long-term, this is intended to transition to a native MCP-server interface across both Linux and seL4 targets. | Today, services communicate via axum-based HTTP with mandatory `X-Module-ID` headers. Long-term, this is intended to transition to a native MCP-server interface across both Linux and seL4 targets. |
| ### Layer 2: Core State API | ### Layer 2: Core State API |
| The stable core contract defining methods for `append`, `read_since`, and `checkpoint`. This target-independent layer ensures consistency regardless of the underlying storage engine. | The stable core contract defining methods for `append`, `read_since`, and `checkpoint`. This target-independent layer ensures consistency regardless of the underlying storage engine. |
| ### Layer 1: Storage Primitives | ### Layer 1: Storage Primitives |
| * **Linux/BSD (Current):** POSIX files using atomic write-then-rename discipline. | * **Linux/BSD (Current):** POSIX files using atomic write-then-rename discipline. |
| * **seL4 (Intended):** Capability-addressed objects mediated by `moonshot-database`. | * **seL4 (Intended):** Capability-addressed objects mediated by `moonshot-database`. |
| * **Format:** Standardized **C2SP tlog-tiles** (matching RFC 9162 v2 / Rekor v2) ensure 100-year readability. | * **Format:** Standardized **C2SP tlog-tiles** (matching RFC 9162 v2 / Rekor v2) ensure 100-year readability. |
| ## Regulatory Compliance and Durability | ## Regulatory Compliance and Durability |
| The design is engineered to align with SEC Rule 17a-4(f) WORM requirements and EU eIDAS qualified preservation standards. By adopting the plain-text C2SP tile format, the platform guarantees that a forensic analyst in the year 2126 could decode the storage using only basic Unix utilities and a SHA-256 implementation. | The design is engineered to align with SEC Rule 17a-4(f) WORM requirements and EU eIDAS qualified preservation standards. By adopting the plain-text C2SP tile format, the platform guarantees that a forensic analyst in the year 2126 could decode the storage using only basic Unix utilities and a SHA-256 implementation. |
| ## Cross-Target Synthesis | ## Cross-Target Synthesis |
| The platform’s implementation is unique in its dual-target Rust strategy, allowing the same binary to serve as a Linux daemon today and an seL4 unikernel tomorrow. This ensures that the storage substrate is portable from a virtual machine to a future ToteboxOS hardware appliance without a core rewrite. | The platform’s implementation is unique in its dual-target Rust strategy, allowing the same binary to serve as a Linux daemon today and an seL4 unikernel tomorrow. This ensures that the storage substrate is portable from a virtual machine to a future ToteboxOS hardware appliance without a core rewrite. |
| ## See also | ## See also |
| - [[worm-ledger-design]] | - [[worm-ledger-design]] |
| - [[worm-ledger-storage-architecture]] | - [[worm-ledger-storage-architecture]] |
| - [[cryptographic-ledgers]] | - [[cryptographic-ledgers]] |
| - [[sel4-microkernel-substrate]] | - [[sel4-microkernel-substrate]] |