Keeping encrypted data available
Development status: Being explored — The design is being explored; its public interface and support are not settled. The intended goal is to store encrypted data off the main chain, with checks that it remains retrievable; data availability for encrypted data is not available in the experimental prototype, and no retention period or archival arrangement is published or offered. Nothing is publicly available for live use.
Before you read: Data and state: how information is recorded and retrieved.
How would encrypted data stay retrievable, and what retention applies today? In short: keeping encrypted data retrievable is a goal being explored, and it is not available; today, no retention period or archival arrangement is published or offered for any data. This page explains the underlying problem, the intended outcome, how availability differs from persistence, backup and confidentiality, and the questions that remain open.
The problem: data that must stay retrievable
Confidential applications may need to keep encrypted data that is impractical to hold in the main recorded state. If such data is stored away from the main chain, those who depend on it need confidence that it can still be retrieved when it is needed.
Encryption adds a twist. Because the data is encrypted, whoever stores it cannot simply inspect it to show that it is still complete and intact. Whether it remains retrievable therefore has to be checked in some other way.
In this documentation, data availability means that data which should be retrievable can actually be retrieved. It is a question about retrieval, not about who may read the contents.
The intended capability
Status of this section: Being explored — the design is being explored; its public interface and support are not settled.
The design is being explored for storing encrypted data off the main chain, with checks that it remains retrievable. The intended outcome is that applications and data owners could rely on encrypted data stored this way being retrievable when needed.
How storage, checks, costs and responsibilities would work is not described.
What exists today
- Data availability for encrypted data is not available in the experimental prototype.
- No retention period or archival arrangement is published or offered for any data handled by the experimental prototype.
- Data handled by the experimental prototype is not confidential to begin with: confidentiality features are simulated or switched off, so it provides no confidentiality protection. See Privacy and confidentiality: intent and current limits.
How this relates to other data topics
Data availability is easy to confuse with neighbouring concerns. It is distinct from each of these:
- Persistence. A node keeping its own state across restarts is a different matter; see State persistence, snapshots and recovery.
- Backup and recovery. Protecting a node’s data against loss is an operator concern whose procedures are not yet specified; see Deployment, backup and recovery: what operators would plan for.
- Confidentiality. Encryption is meant to protect contents, but even encrypted data can reveal some information, such as its size and when it is stored or retrieved; see What remains observable.
- Legal and compliance questions. This page makes no legal or compliance claims; see Compliance position and data-protection intent.
Open questions for organisations and researchers
The following questions are open. None is answered today, and this page does not suggest answers.
- What would “retrievable” mean in practice, and for whom?
- How would confidence in retrievability be established, and what would establishing it cost?
- Who would be responsible for storing the data, and what would they be expected to do?
- How would availability interact with confidentiality, and with what remains observable?
Research questions of this kind are collected on Assumptions and open questions.
Assumptions, trust and limitations
- No availability, durability, retention or archival guarantee is offered.
- Any future checks of retrievability would themselves rest on assumptions that are not yet described.
- The intended capability is a design goal, not a commitment to a particular form, scope or release.
Not yet available, and how this page will grow
The capability and its reference are not available. Further technical reference is not yet available. If the capability is implemented and released, this page would describe the supported behaviour, its limits and its status. The status label would change only with evidence of implementation and release.
What this page does not claim
This page does not describe any storage design or check method, and it states no retention period, cost or service level. It makes no legal or compliance claim, and it does not claim that any data is kept available today. Anything not stated here as available should be treated as unavailable.
Related pages
- Data and state: how information is recorded and retrieved — the section overview and the status of each data topic.
- State persistence, snapshots and recovery — how a node keeps its own state, which is a different concern.
- What remains observable — information that encrypted data and activity can still reveal.
- Compliance position and data-protection intent — the documentation’s position on legal and compliance questions.
- Deployment, backup and recovery: what operators would plan for — backup and recovery as an operator concern.
- Assumptions and open questions — where research questions are collected.
Glossary
References
No approved public references yet.
