Merkle proofs as a substrate primitive
docs(2g): corpus-wide Doctrine claim vocabulary removal (227 files)
@@ -8,12 +8,12 @@ bcsc_class: no-disclosure-implication last_edited: 2026-04-28 editor: pointsav-engineering cites: - rfc-9162 - doctrine-claim-33 - doctrine-claim-34 - rfc-9162 - doctrine-claim-33 - doctrine-claim-34 --- `system-core` ships two RFC 9162 Merkle proof primitives — inclusion proofs and consistency proofs — as the cryptographic floor of the Capability Ledger Substrate (Doctrine claim #33). Together with the C2SP signed-note checkpoint format they gate ledger apply-side validity and make capability state auditable without requiring consumer good behaviour. `system-core` ships two RFC 9162 Merkle proof primitives — inclusion proofs and consistency proofs — as the cryptographic floor of the Capability Ledger Substrate. Together with the C2SP signed-note checkpoint format they gate ledger apply-side validity and make capability state auditable without requiring consumer good behaviour. ## What Merkle proofs are @@ -41,7 +41,7 @@ The `LedgerConsumer` trait's `apply_witness_record` was promoted in Phase 1A.4 ( ## Why this matters as a substrate primitive The Capability Ledger Substrate (Doctrine claim #33) requires a customer-rooted Merkle log to make capability state auditable. The Two-Bottoms Sovereign Substrate (Doctrine claim #34) requires that a deployment-as-cryptographic-artefact be inheritable across native (seL4) and compat (NetBSD) substrates without re-trusting the runtime. Merkle inclusion and consistency proofs are the cryptographic primitives that make both properties hold without requiring consumer good behaviour. The primitives run in `no_std`-compatible Rust, are kernel-consumption-eligible, and are reused across `system-core` consumers without per-consumer reimplementation. The Capability Ledger Substrate requires a customer-rooted Merkle log to make capability state auditable. The Two-Bottoms Sovereign Substrate requires that a deployment-as-cryptographic-artefact be inheritable across native (seL4) and compat (NetBSD) substrates without re-trusting the runtime. Merkle inclusion and consistency proofs are the cryptographic primitives that make both properties hold without requiring consumer good behaviour. The primitives run in `no_std`-compatible Rust, are kernel-consumption-eligible, and are reused across `system-core` consumers without per-consumer reimplementation. ## See also @@ -52,6 +52,4 @@ The Capability Ledger Substrate (Doctrine claim #33) requires a customer-rooted ## References - **RFC 9162** — Certificate Transparency Version 2.0. IETF, 2021. Defines the Merkle tree hash algorithm, inclusion proof, and consistency proof specifications used verbatim in `system-core`. https://datatracker.ietf.org/doc/html/rfc9162 - **Doctrine claim #33** — The Capability Ledger Substrate. Foundry DOCTRINE.md v0.1.0. - **Doctrine claim #34** — The Two-Bottoms Sovereign Substrate. Foundry DOCTRINE.md v0.1.0. - **`conventions/worm-ledger-design.md`** — WORM ledger design convention; `system-ledger` implements this convention.