Committed state and inclusion proofs
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. In an internal prototype, node state is committed under a cryptographic root, and the prototype can return proofs that a value is part of that state; a root from the experimental implementation is not final, the state it summarises is not confidential, and the structures, formats and algorithms involved are not described. Nothing is publicly available for live use.
Before you read: Data and state: how information is recorded and retrieved.
How can someone check that a value is part of the network’s recorded state? The intended answer rests on two concepts: a compact cryptographic summary of the state, called a root, and an inclusion proof that ties a particular value to that root. This page explains both, states what the experimental implementation does with them, sets out what a successful check does and does not establish, and describes in conditional terms how the capability is intended to be used once released.
Why commit to state
Parties that work with recorded state often need to refer to “the state at a particular point” without exchanging all of it. A state commitment answers that need: it is a compact cryptographic value that summarises the whole state. This documentation calls it a root.
A root is intended to identify the state at one particular point, so that any change to the state would be expected to give a different root. That makes a root useful as a reference. Applications, reviewers and operators could use the same root to mean the same state — for example, when comparing their records, or when an application wants to say exactly which state a value it displays came from.
How roots are computed, and when they are produced, is not described in this documentation.
What an inclusion proof lets someone check
An inclusion proof is evidence that a particular value is part of the state that a given root summarises. In this documentation the checker is an application, or a reviewer who has been given the value and a root.
Conceptually, a check takes three inputs — a root, the value of interest and a proof — and has one of two outcomes:
- The check succeeds. The value is part of the state that the root summarises. A success shows inclusion relative to that root only, and the checker does not need a copy of the whole state to reach it.
- The check fails. The value could not be confirmed against that root. Possible reasons include a value that differs from the one recorded, a root that summarises the state at a different point, or a damaged proof. A failed check is not, by itself, evidence of anything else.
How proofs are built, their format and size, and how a check is computed are not described.
An inclusion check at a glance
The sketch below restates the inputs and outcomes above in a single table.
Illustrative local demo — not a released Cubane API, protocol schema or live-network result.
Table: an inclusion check described in words, as illustrative documentation text only.
| Part of the check | Illustrative label | What it stands for |
|---|---|---|
| Input | Root A | A root the checker has reason to trust, summarising the state at one point |
| Input | Value V | The value the checker wants to confirm; the checker can see it |
| Input | Proof P | Evidence that Value V is part of the state summarised by Root A |
| Outcome if the check succeeds | Not applicable | Value V is part of the state summarised by Root A |
| Outcome if the check fails | Not applicable | Value V could not be confirmed against Root A |
Even when the check succeeds, it does not establish that Root A is final, that Value V was produced correctly, that anything is confidential, or that Root A deserves trust.
The table is hardcoded documentation text written for this page. Root A, Value V and Proof P are opaque labels, not data, and every cell is descriptive prose. The sketch demonstrates only which inputs an inclusion check takes and which two outcomes it can have. No proof was produced or checked, no cryptographic computation took place, nothing was fetched from any node, and no root shown is final. The labels and column names are illustrative, not an interface commitment.
What exists today
Status of this section: Experimental implementation exists — internal prototype only; not publicly available.
- In an internal prototype, node state is committed under a cryptographic root.
- The prototype can return proofs that a value is part of that state, through an experimental interface used for internal testing. That interface is not documented and is not publicly reachable; the interface families that exist experimentally are listed on Interfaces and their status.
- The state the prototype commits to is held in an experimental state database; how far that state survives restarts is described on State persistence, snapshots and recovery.
- A root from the prototype is not final, because the finality component is not yet connected, and the state it summarises is not confidential.
- The experimental implementation has not been independently reviewed, and no security property is claimed for it.
What a successful check does not establish
A successful inclusion check is deliberately narrow. It does not establish:
- That the root is final or agreed by the network. An inclusion proof shows membership, not finality. The finality component is not connected in the experimental implementation, so nothing is reported as final; see Agreement and finality status.
- How the value came to be. An inclusion proof concerns membership only. It does not show that the value was produced correctly or that the transaction behind it did what an application intended.
- Anything about confidentiality. The state in the experimental implementation is not confidential, and the checker sees the value it checks.
- That the root itself deserves trust. A check is only as meaningful as the checker’s reason to trust the root it uses. A proof checked against an untrustworthy root shows only that the value is part of whatever state that root summarises.
- That any particular tool can check the proof. No compatibility with other platforms’ formats or tools is claimed.
Intended use once released
Status of this section: Planned — described conditionally; no request-and-check experience is available.
Once this capability is implemented, enabled and publicly released, an application would be expected to request a proof for a value it relies on and check it against a root it has reason to trust. Because inclusion is not finality, applications would combine an inclusion check with the finality status of the result before acting on it.
Typical uses would include:
- Confirming a recorded value before relying on it — for example, before displaying a balance or a recorded outcome to a user, or before taking an action that depends on it.
- Referring to one specific state when records are compared — for example, when an application reconciles its own records with recorded network data and wants both sides to point at the same root.
- Assurance review — a reviewer who has been given a value and a root could confirm that the value is part of that recorded state.
How applications would obtain roots, and on what basis they would trust them, is not yet described. Where an inclusion check would fit within a complete application is previewed, in conditional terms, on Integrating an application end to end.
Assumptions, trust and limitations
- Trust in the root is the central assumption. An inclusion check depends on trusting the root it is checked against, and how roots would be distributed and trusted is not described.
- Experimental roots and proofs are internal. They are not final, not confidential and not independently reviewed, and no security property is claimed for them.
- Membership only. The checker sees the value it checks, and an inclusion check confirms the membership of that value and nothing more.
- Categories, not constructions. The cryptographic categories this documentation describes, and the role of trust roots in general, are covered on Cryptographic foundations and trust roots.
Not yet available, and how this page will grow
Proof formats, the interface for requesting proofs and the way checks would be performed are not yet available. Further technical reference is not yet available. Once released, this page would link to versioned reference for requesting and checking proofs and for interpreting failed checks. The status label would change only with evidence of implementation and release.
What this page does not claim
This page does not describe any data structure, hash function, proof format or proof size, and it claims no checking speed, soundness or other security property. It claims no compatibility with other platforms’ formats or tools, and it does not claim that any root or result is final. Anything not stated here as available should be treated as unavailable.
Related pages
- State persistence, snapshots and recovery — where the committed state is kept across restarts, and its limits.
- Querying network data and browsing activity — reading state through experimental interfaces, and why a plain query result is not checkable evidence.
- Cryptographic foundations and trust roots — the categories of cryptography and trust roots this documentation describes.
- Integrating an application end to end — where an inclusion check would fit in an application, described conditionally.
- Agreement and finality status — why a successful inclusion check does not make a result final.
- Data and state: how information is recorded and retrieved — the section overview and the status of each data topic.
Glossary
References
No approved public references yet.
