System model: how Cubane is intended to work for its users
Development status: Overview — This section gives a user-level model of who takes part, what moves through the system and what can be relied on, and each block carries its own label: transaction submission, execution and recorded state have an experimental implementation used internally; the finality status query exists but reports nothing as final; confidential jobs are being explored; and the external roles are planned. No view of the internal design is published, and nothing is publicly available for live use.
Before you read: What Cubane is designed to do.
Who takes part in Cubane, what moves through it and what could an application rely on? This section answers from the point of view of the developers, users and organisations who would use the platform, and says plainly what can and cannot be relied on today.
What this section covers
The section builds a user-level model in six parts: participants and roles; transactions; confidential jobs; agreement and finality status; service levels; and fees. Together they describe what a developer or user would submit, observe, get back and be able to rely on.
The model describes what users and developers would experience, not how the system is built. No view of the internal design is published in this documentation, and nothing in this section should be read as one.
Stage names such as “submitted”, “executed” and “final” are documentation terms, defined once on Lifecycle stages used in this documentation. They keep lifecycle descriptions consistent from page to page; they are not protocol status values or interface fields.
Who takes part
Status of this section: Planned — the roles below are intended and may change; no role is open to the public today.
The planned design names external roles in three groups:
- Roles that build on and use the platform. Application developers would build applications and tools that submit work and present results. Users — people and systems — would act through applications and wallets. Organisations would set their own policies, such as which sensitive actions need several approvers, how the keys behind their funds are held and who may see which data.
- Roles that run the network. Node operators would run the nodes that process transactions and keep state. Validators would take part in the network’s agreement on results. For confidential computation, the design being explored includes the use of specialised hardware workers for encrypted computation; this documentation calls that role specialised compute workers.
- Roles that oversee and govern. Auditors could be given time-limited access to selected data by the owners of that data. Governance participants would propose, vote on and carry out protocol decisions through auditable steps.
Some capabilities behind these roles, such as organisation policies, auditor access and governance, are being explored rather than planned. Participants and roles labels each role and sets out its intended responsibilities, and Trust assumptions and responsibilities by participant covers the trust others would place in each.
No role is open to the public today: there is no public network on which to run a node, validate or take part in governance, and no eligibility rules or requirements are published.
What moves through the system
Transactions
Status of this block: Experimental implementation exists — internal prototype only; not released.
A transaction is an ordinary request to change recorded state, such as a transfer. In the internal prototype, transactions can be submitted, given initial checks, executed deterministically and recorded in state, and their status can be queried through an experimental interface used for internal testing. Passing the initial checks is not an assurance about who sent a transaction or a protection against it being replayed. Transaction lifecycle: from submission to result describes the stages a developer would observe and the limits of each.
Confidential jobs
Status of this block: Being explored — the design is being explored; its public interface and support are not settled.
A confidential job is a long-running confidential computation that an application would follow over time rather than wait on as a single step. The design being explored includes long-running confidential jobs that could be submitted, tracked, cancelled and refunded, with results retrieved later by the parties entitled to them. No confidential job can be run today. Confidential jobs: tracking, cancelling and retrieving results describes the intended experience.
Recorded state
Status of this block: Experimental implementation exists — internal prototype only; not released.
The effects of executed transactions are kept as recorded state. In the internal prototype, a node’s state is committed under a cryptographic root, and an inclusion proof can show that a particular value is part of that committed state. An inclusion proof shows membership in recorded state; it does not show that the state is final. Data and state: how information is recorded and retrieved explains these concepts.
What can be relied on today, and what cannot
Nothing in this section is publicly available, and the experimental implementation is an internal prototype. Within that prototype:
- Finality: an experimental finality status query exists, but it reports nothing as final because finality is not connected. No result should be treated as final. See Agreement and finality status.
- Confidentiality: confidentiality features are simulated in the experimental implementation, which provides no confidentiality protection. See Privacy and confidentiality: intent and current limits.
- Fees: no fees are charged anywhere. An experimental fee calculator exists, but it charges nothing. See Fees and cost estimates.
- Service levels: none are offered. Experimental admission control and backpressure exist only in an internal prototype. See Service levels and admission control.
For your own planning, assume that no result is final, no data is kept confidential, and no cost or service level has been set.
Reading order for this section
- Participants and roles
- Transaction lifecycle: from submission to result
- Confidential jobs: tracking, cancelling and retrieving results
- Agreement and finality status
- Service levels and admission control
- Fees and cost estimates
Then continue to Security model, trust and limitations for the assumptions behind this model, and to Data and state: how information is recorded and retrieved for how recorded state would be read and checked. Developers preparing applications, tools or wallets can follow the complete path on Choose your path.
Assumptions, trust and limitations
- The model is user-level and intentionally omits internal structure. It is not a specification of how the network works.
- Maturity differs by block, and each label applies only to its own block. Experimental work on transactions is not evidence that confidential jobs or any of the roles exist.
- Trust assumptions and limitations are covered on Security model, trust and limitations, and the full list of prototype limitations is on Known limitations of the experimental prototype.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once a supported release exists, each stage described in this section would link to versioned reference for that release. If reviewed public material about the platform’s design is approved for publication, this section would link to it.
Related pages
- Participants and roles — who takes part and what each is expected to do.
- Transaction lifecycle: from submission to result — the stages of an ordinary transaction.
- Confidential jobs: tracking, cancelling and retrieving results — the intended asynchronous job experience.
- Agreement and finality status — when a result could be treated as final.
- Security model, trust and limitations — trust assumptions and limitations behind the model.
- Lifecycle stages used in this documentation — definitions of the stage terms used here.
- Fees and cost estimates — fee concepts and current status.
Glossary
References
No approved public references yet.
