Problem statement and intended properties

Development status: Research — This note records goals, assumptions and open questions; nothing here is an assurance or a released feature. Cubane is a blockchain platform under development that aims to let organisations process sensitive data while producing results others can verify; the design is being explored, and an experimental implementation exists for internal protocol development only. In that implementation the encrypted-computation interfaces only simulate the behaviour, and confidentiality and proving features are simulated or switched off, so none of the intended properties is demonstrated and nothing is publicly available for live use.

Before you read: Research: problems, properties and open questions.

Which problem is Cubane trying to solve, and which properties is the design intended to have? This note states the problem in neutral terms, restates the intended aim only to frame it, and lists each intended property as a goal, with its status and the page where it is discussed. It then explains what “intended” means here, what the experimental implementation does and does not show, and what the note deliberately leaves out. It contains no constructions, security arguments, novelty claims or comparisons.

The problem

Many applications must compute over records that are commercially or personally sensitive, while other parties need to rely on the results of that computation.

Checking a result usually involves seeing the inputs that produced it. A business partner who wants to confirm a figure recomputes it from the underlying records; a member of the public asked to accept a published outcome has little to go on unless the inputs can be examined. Keeping the inputs confidential usually means the opposite: those who rely on the result must simply trust whoever computed it.

On a shared network the tension is sharper. The participants that process and record activity would ordinarily see the data they handle. A network run by many parties therefore widens the circle of those who could see sensitive inputs, at the same time as it is meant to give more parties confidence in what is recorded.

The problem therefore has two sides: confidentiality for the data, and confidence for whoever relies on the results. Serving one side at the expense of the other does not meet the intended uses. Disclosing everything so that results can be checked fails the data owner; asking others to accept results they cannot check fails the parties who rely on them.

This note makes no claim about how other systems address the problem.

Who has this problem

• Organisations and developers that need confidential data processing with verifiable, auditable results. Being explored.
• Data owners — parties that provide or control sensitive data and want to decide who can see it.
• Relying parties — people or organisations that depend on a result and need confidence in it, such as business partners or the public.

Example scenarios are described in What you could build: intended application patterns; this note does not repeat them.

The intended aim

Cubane is a blockchain platform under development that aims to let organisations process sensitive data while producing results others can verify. Being explored.

The aim says what is intended, not how it would be achieved; design detail is not described in this documentation. The primary page for the aim is What Cubane is designed to do. This note restates the aim only to frame the properties below.

Intended properties (each a goal, not an assurance)

Each property below is a goal of a design that is planned or being explored. Its status is given beside it, and each property links to the note or page where its assumptions and open questions are discussed.

Confidential processing

Status: Being explored — the experimental implementation only simulates encrypted computation.

Selected data could be processed while it remains encrypted, so that it is not exposed to the participants that process it. This is the goal behind confidential computation. Discussed in Design note: confidential computation with verifiable results.

Results others can verify

Status: Being explored.

Parties relying on a result would be able to check it rather than take it on trust, while who may see the data is kept separate from who may rely on the result. Which results could be checked, by whom and under which assumptions is not yet specified publicly, and how a result would be made checkable is not described in this documentation. See verifiable result. Discussed in Design note: confidential computation with verifiable results.

Owner-controlled visibility and selective disclosure

Status: Being explored — the step that would reveal results is only simulated in the experimental prototype.

Data owners would decide who can see which data, including time-limited access for auditors to the data itself. Selected results could be disclosed to authorised parties — selective disclosure — and who may see data would be controlled separately from who may act on it. Discussed in Design note: selective disclosure and audit records.

Tamper-evident records

Status: Planned — tamper-evident audit logging is part of the planned design, and an experimental library exists for internal development only.

Alterations to records of significant actions could be detected when the records are checked. A tamper-evident log makes changes detectable, not impossible; it is not tamper-proof. Discussed in Design note: selective disclosure and audit records.

Accountability for misbehaviour

Status: Being explored — nothing is enforced on any network.

Misbehaviour by participants who run the network would be made costly and contestable through layered defences, penalties and governed disputes. Discussed in Design note: accountability for misbehaviour.

An acknowledged boundary on what remains observable

Status: Being explored.

The design acknowledges that some protocol metadata remains observable even with confidential execution, and ways to bound and reduce it are being explored. This property is a boundary rather than a protection: it states what confidentiality would not cover, so that applications can be designed with it in mind. See observable metadata. Discussed on What remains observable.

Further design-stage goals

Two further goals are recorded in their own design notes: operating under partial failure and evolving participation, in Design note: operating under partial failure and evolving participation; and independently checkable randomness, in Design note: independently checkable randomness.

Summary of intended properties

Table: each intended property, what it would mean for users, its status today and where it is discussed.

Property	What it would mean for users	Status today	Discussed in
Confidential processing	Selected data could be processed without being exposed to the participants that process it	Being explored; encrypted computation only simulated	Design note: confidential computation with verifiable results
Results others can verify	Relying parties could check a result rather than take it on trust	Being explored	Design note: confidential computation with verifiable results
Owner-controlled visibility and selective disclosure	Data owners would decide who sees which data; selected results could be shared with authorised parties	Being explored; reveal step only simulated	Design note: selective disclosure and audit records
Tamper-evident records	Alterations to records of significant actions could be detected when the records are checked	Planned; experimental library, internal only	Design note: selective disclosure and audit records
Accountability for misbehaviour	Misbehaviour by those who run the network would be costly and contestable	Being explored; nothing enforced	Design note: accountability for misbehaviour
Acknowledged boundary on what remains observable	Users would know in advance that some information about activity stays visible	Being explored; no bound published	What remains observable

What “intended” means in this note

• Goals, not assurances. Each property is a goal of a design that is planned or being explored. None is an assurance, and none is demonstrated today.
• Conditional on assumptions. Properties are not stated as guarantees. Each would hold, if at all, only under assumptions that are not yet stated in detail.
• Evidence first. A property would become a supportable claim only once it is implemented, released and backed by published evidence with stated assumptions; see Evaluation methodology and published results.
• Properties pull against each other. In places the goals are in tension — for example, confidentiality against what remains observable, and confidentiality against cost, since confidential computation would be metered by the cryptographic work it performs. These trade-offs are recorded on Assumptions and open questions.

What the experimental implementation shows, and what it does not

• An experimental implementation exists for protocol development and integration work. It is an early prototype and should not be relied on for security or production use.
• Its encrypted-computation interfaces simulate the behaviour and perform no real encrypted computation.
• Its confidentiality and proving features are simulated or switched off, so it provides no confidentiality protection.
• It therefore demonstrates none of the intended properties above. Simulated outputs are not evidence that any of these properties holds. The complete list is on Known limitations of the experimental prototype.

What this note does not cover

• How any property would be achieved: techniques, constructions, parameters and internal components are not described.
• Security arguments or analyses of any property.
• Comparisons with other platforms, or claims of novelty.
• Performance, cost or capacity figures, and any legal or compliance position; see Compliance position and data-protection intent.

Assumptions, trust and limitations

• The properties would rest on assumptions about participants, keys and observers that are not yet stated in detail. The consolidated list is on Assumptions and open questions, and the per-participant view is on Trust assumptions and responsibilities by participant.
• Even if the confidentiality goals were met, some information about activity would remain observable; see What remains observable.
• The list of properties may change as the design settles. Any change would be dated and recorded in the Documentation change log.

Not yet available, and how this page will grow

• If a reviewed, more precise statement of the properties and their assumptions is approved for publication, it would be added here with its date and recorded in the change log.
• Evidence about any property would be linked from Evaluation methodology and published results; none is published.
• Approved references would be listed on Public references; none are listed yet.

What this note does not claim

This note does not claim:

• any assurance of confidentiality, correctness, availability or accountability;
• any confidentiality protection today;
• any performance or cost figure;
• any comparison with other platforms;
• any available feature.

Anything not stated here as available or assured should be treated as neither.

Related pages

• What Cubane is designed to do — the primary page for the platform aim and its boundaries.
• Assumptions and open questions — the assumptions, trade-offs and open questions behind each property.
• Design note: confidential computation with verifiable results — the note on the two central properties.
• Security model, trust and limitations — what is protected today, what is visible and whom you would rely on.

Glossary

• Verifiable result
• Relying party
• Data owner
• Confidential computation
• Selective disclosure
• Time-limited access
• Tamper-evident log
• Observable metadata

References

No approved public references yet.