WORM ledger storage architecture
editorial(infrastructure): correct worm-ledger-storage-architecture's proof-serving claim (Track-B follow-up) — found while fixing worm-ledger-design.md: ledger.rs's verify_inclusion/verify_consistency ARE real, implemented, and serving proofs today (confirmed by direct read), contradicting this article's own 'does not yet serve proofs' claim added in the prior commit; the real gap is narrower — proofs are chain-based (segment-length-scaling), not yet true branching-Merkle-tree-based (log-n-scaling); register-clean EN+ES
@@ -25,7 +25,7 @@ The storage architecture **specifies** the **C2SP tlog-tiles** format as its tar * **Atomic Durability (current):** Records are written to a temporary file, synchronised with `fsync`, and renamed atomically to the canonical path. This ensures that partial writes never corrupt the ledger state. * **Plain-Text Transparency (planned):** Under the target tile format, tiles are stored as newline-delimited base64 text, inspectable using standard Unix utilities (`cat`, `base64`, `sha256sum`). * **Merkle-Based Integrity (planned):** The design chains every entry into a Merkle structure to allow inclusion proofs and consistency checks. **This is the intended model — the current `service-fs` build records per-payload digests and does not yet construct a Merkle tree or serve proofs.** * **Chain-Based Integrity (current), Merkle Tree (planned):** Every entry's hash chains into the one before it, and `service-fs` already serves real inclusion and consistency proofs against that chain today — recomputing the relevant chain segment and checking it against a signed checkpoint's recorded root hash. What the design targets and doesn't yet have is a true branching Merkle tree, which would make a proof's size independent of how far back the entry sits rather than scaling with the chain segment length. ## 2. Dual-target runtime envelopes