Data and state: how information is recorded and retrieved

Development status: Overview — Committed state with inclusion proofs, saving node state across restarts, deterministic execution of transaction batches, and interfaces for querying state and browsing blocks and transactions exist in an experimental implementation used internally; storage that application logic could use directly, a SQL-style way to query confidential data and keeping encrypted data retrievable are being explored and do not exist. Data in the experimental implementation is not kept confidential, and nothing recorded there is reported as final. Nothing in this section is publicly available for live use.

Before you read: System model: how Cubane is intended to work for its users.

How is application and network data intended to be recorded, proven, kept and queried? This section answers in six topics whose maturity differs, so each summary below carries its own status label. This page defines no terms of its own: concepts link to the Glossary, and each topic links to the page that answers the next question.

What this section covers

Recording and proving state

Status: Experimental implementation exists — internal prototype only; not publicly available.

The network keeps a shared record of state. An experimental implementation commits node state under a cryptographic root and can return proofs that a value is part of that state. Such a proof shows that a value is included in recorded state; it does not show that the state is final. See Committed state and inclusion proofs.

Keeping state across restarts

Status: Experimental implementation exists — internal prototype only; not publicly available.

An experimental implementation saves node state to disk and restores it when a node restarts. Its crash safety has not been established, and which state is kept and restored is not documented. See State persistence, snapshots and recovery.

Running application logic

Status: Experimental implementation exists for deterministic execution; storage for application logic is being explored. Neither is publicly available.

An experimental deterministic execution environment runs transaction batches in an internal prototype. Storage operations that application logic could use directly are being explored and do not exist, and how application logic would be written and deployed is not yet documented. See Application logic, execution and storage.

Reading data

Status: Experimental implementation exists — internal testing only; not publicly available.

Experimental interfaces for querying node state and for browsing blocks and transactions exist for internal testing. Richer explorers are being explored. See Querying network data and browsing activity.

Querying confidential data

Status: Being explored — nothing is available.

A familiar, SQL-style way to declare and query confidential data is being explored. No syntax is published, and nothing can be queried this way today. See Querying confidential data.

Keeping encrypted data retrievable

Status: Being explored — not available in the experimental prototype.

Storing encrypted data off the main chain, with checks that it remains retrievable, is a goal being explored. It is not available. See Keeping encrypted data available.

Status at a glance

The table repeats what the topic pages say and adds nothing new. Status is stated in words.

Table: status of each data topic.

Topic	Status label	What exists today	What is intended
Committed state and inclusion proofs	Experimental implementation exists	Node state committed under a cryptographic root, with proofs that a value is part of it, in an internal prototype. Not publicly available.	Applications and reviewers checking that a value they rely on is part of recorded state, against a root they trust.
State persistence, snapshots and recovery	Experimental implementation exists	Node state saved to disk and restored on restart, in an internal prototype; crash safety not established. Not publicly available.	Documented persistence behaviour in released node software, which operators would plan around.
Application logic, execution and storage	Experimental implementation exists for execution; Being explored for application storage	Deterministic execution of transaction batches, in an internal prototype; no storage for application logic. Not publicly available.	A documented, versioned way to write and run application logic; application storage is being explored.
Querying network data and browsing activity	Experimental implementation exists	Interfaces for querying node state and browsing blocks and transactions, for internal testing. Not publicly available.	Documented, versioned interfaces for reading state, looking up transactions and following activity; richer explorers are being explored.
Querying confidential data	Being explored	Nothing. Not publicly available.	A familiar, SQL-style way to declare and query confidential data.
Keeping encrypted data available	Being explored	Nothing. Not publicly available.	Encrypted data stored off the main chain, with checks that it remains retrievable.

Concepts used across the section

These terms recur throughout the section. Each is defined once, in the glossary; the pointers below only say where each concept is explained.

• State — what the network records as transactions are executed; introduced on this page.
• Committed state, state root and inclusion proof — summarising state compactly, and checking a value against that summary: Committed state and inclusion proofs.
• Persistence and snapshot — keeping state across restarts, and a node’s own saved copy of its state: State persistence, snapshots and recovery.
• Deterministic execution — the same input is intended to give the same result on every node: Application logic, execution and storage.
• Explorer and SQL-style query — reading recorded data, compared with the intended way of querying confidential data: Querying network data and browsing activity and Querying confidential data.
• Data availability — whether data that should be retrievable can actually be retrieved: Keeping encrypted data available.

How data topics connect to the rest of the documentation

• Where recorded state comes from: the recorded-state stage on Transaction lifecycle: from submission to result.
• Whether a recorded result is final: an experimental finality status query exists, but it reports nothing as final, because the finality component is not yet connected. See Agreement and finality status.
• Whether data is kept confidential: confidentiality and proving features are simulated or switched off in the experimental implementation, which provides no confidentiality protection. See Privacy and confidentiality: intent and current limits.
• Keeping nodes running and recoverable: Deployment, backup and recovery: what operators would plan for.
• Which interfaces exist experimentally: Interfaces and their status.

Suggested reading paths

• Preparing an eventual application: Committed state and inclusion proofs, then Application logic, execution and storage, Querying network data and browsing activity, Querying confidential data and Interfaces and their status.
• Research: Committed state and inclusion proofs, then Keeping encrypted data available, What remains observable and Research: problems, properties and open questions.
• Organisations and integrators: Querying confidential data, then Keeping encrypted data available and Visibility controls and selective disclosure.
• Prospective operators: State persistence, snapshots and recovery, then Operating a node: intended roles and what exists today.

Assumptions, trust and limitations

• The experimental implementation is used internally for protocol development. It is an early prototype, not a release, and must not be relied on for security or production use.
• Data in the experimental implementation is not kept confidential: confidentiality and proving features are simulated or switched off.
• Recorded results are not final: the finality component is not yet connected, so nothing is reported as final.
• No durability, availability, performance or capacity property is claimed for any topic in this section.

Not yet available, and how this section will grow

The programming model, the data model and formats available to applications, and interface reference are not yet documented. Further technical reference is not yet available. A topic page’s status label would change only with evidence of implementation and release, recorded in the Documentation change log, and versioned reference would be linked from each topic page once a supported release exists.

What this page does not claim

This page does not describe or promise any data model, storage design, query language, data format, interface or performance figure, and it does not claim compatibility with other platforms. It does not claim that any data is kept confidential, that any result is final, or that anything in this section is publicly available. Anything not stated here as available should be treated as unavailable.

Related pages

• Committed state and inclusion proofs — how state is summarised under a root and how inclusion can be checked.
• State persistence, snapshots and recovery — whether node state survives restarts and how far that can be relied on.
• Application logic, execution and storage — deterministic execution today and application storage being explored.
• Querying network data and browsing activity — reading state, looking up transactions and following activity.
• Querying confidential data — the intended SQL-style experience for confidential data.
• Keeping encrypted data available — the goal of keeping encrypted data retrievable.
• System model: how Cubane is intended to work for its users — the prerequisite overview of roles, stages and boundaries.

Glossary

• State
• Committed state
• State root
• Inclusion proof
• Persistence
• Snapshot
• Deterministic execution
• Explorer
• SQL-style query
• Data availability

References

No approved public references yet.