Confidential jobs: tracking, cancelling and retrieving results
Development status: Being explored — The design being explored includes long-running confidential jobs that could be submitted, tracked, cancelled and refunded, with results retrieved later, and the use of specialised hardware workers for encrypted computation. An experimental implementation of encrypted-computation interfaces exists internally but only simulates the behaviour; no job interface or SDK is available. Nothing is publicly available for live use.
Before you read: Transaction lifecycle: from submission to result.
How would a long-running confidential computation be submitted, tracked, cancelled or refunded, and how would its result be retrieved? This is the primary page for confidential jobs. It describes the intended asynchronous job experience from submission to result, the role of specialised compute workers at a user level, how job costs relate to the fee concepts, what the experimental implementation simulates and what does not exist, and how applications would be designed around jobs.
Why jobs differ from transactions
Confidential computations can take much longer than an ordinary transaction. Rather than wait for one to finish, an application would submit the work, carry on with other tasks and come back for the result later. That asynchronous pattern is the main difference a developer would notice.
A confidential job is the unit an application would track from submission to result. Each job would have its own progress, could be stopped while it is still running and would end either with a result for the parties entitled to it or without one. Ordinary transactions, which move from submission to a recorded result, are covered on Transaction lifecycle: from submission to result.
The stage words in italics below — submitted, in progress, completed, retrieved, cancelled and failed — are documentation terms for jobs, defined on Lifecycle stages used in this documentation. They are not states of any implementation, and apart from submitted, which means the same hand-over in both sets, transaction stage terms are not used for jobs.
The intended job experience
Status of this section: Being explored — the design is being explored; its public interface and support are not settled.
The design being explored would give an application five actions over a job:
- Submit. An application would submit a job through planned language SDKs; the job is then submitted. Planned: the planned developer experience would allow applications to submit confidential jobs and retrieve results through language SDKs; no SDK is publicly available.
- Track. The application could check a job’s progress while it is in progress, and see when it has completed, been cancelled or failed.
- Cancel. The application could cancel a job it no longer needs before it completes; the job is then cancelled.
- Refund. A cancelled job could be refunded. The conditions and amounts of any refund are not described.
- Retrieve. Once a job has completed, the application would retrieve the result, and the job is then retrieved. Results are intended to be available only to the parties entitled to them; see Sharing selected results with auditors and partners.
A job could also end without producing a result, in which case it has failed; the failure categories are on What can go wrong: failure and error concepts. Result formats are not described.
Specialised compute workers
Status of this section: Being explored — no specialised compute worker is available.
The design being explored includes the use of specialised hardware workers for encrypted computation. This documentation calls that role specialised compute workers; Participants and roles places it among the other roles.
How jobs would be processed or assigned is not described. No specialised workers are available, and no hardware requirements are published.
Costs of jobs
Status of this section: Being explored — no fees are charged anywhere today.
The design being explored would meter encrypted computation according to the amount of cryptographic work performed. No units, formulas or prices are published. How the cost of a job would relate to the fee concepts, and what is known about fees today, is described on Fees and cost estimates.
No fees are charged anywhere today, so no job has a cost that an application could observe or plan around.
What exists today
Status of this section: Experimental implementation exists — internal prototype only; simulated.
- An experimental implementation of encrypted-computation interfaces exists in an internal prototype. It simulates the behaviour and performs no real encrypted computation, so it provides no confidentiality protection. Confidential computation describes it.
- No job lifecycle is available: there is no SDK, no job interface and no environment in which to submit a job.
- Experimental behaviour is not evidence of future job duration, cost or confidentiality.
The job experience at a glance
The table below lists each action an application would take, what it would provide, what it would see in general terms and the status today.
Illustrative local demo — not a released Cubane API, protocol schema or live-network result.
Table: actions on a confidential job, as illustrative documentation text only.
| Action | What the application would provide | What it would see, in general terms | Status today |
|---|---|---|---|
| Submit a job | The work to be done, through a planned language SDK | That the job has been submitted | Not available; no SDK exists; encrypted processing is simulated internally |
| Check progress | A reference to the job it submitted | Whether the job is in progress, has completed, has been cancelled or has failed | Not available |
| Cancel | A request to stop a job it no longer needs | That the job has been cancelled | Not available |
| Receive a refund after cancellation | Nothing further is described | That a refund could follow; conditions and amounts are not described | Not available; no fees are charged anywhere |
| Retrieve the result | A request from a party entitled to the result | The result of a completed job, after which the job is retrieved; formats are not described | Not available; encrypted processing is simulated internally |
The table is hardcoded documentation text written for this page, not output from any system. It demonstrates the actions an application would take over a confidential job and what it would see in general terms. No job was submitted, processed, cancelled, refunded or delivered; no worker was involved; nothing was encrypted or decrypted; and no authorisation, proof or agreement between nodes took place. The stage words are documentation terms, not states of any implementation, and the column names are not interface fields. An illustrative walkthrough of an application using confidential jobs is on Submitting work and retrieving results.
Designing for jobs
Once this capability is implemented, enabled and publicly released, developers are expected to design applications around jobs as follows:
- Treat jobs as asynchronous. Keep a reference to each job you submit and check its progress, rather than waiting for it to finish.
- Handle every ending explicitly. Plan for cancellation, failure and results that arrive late, and tell users what happened in each case; the failure categories are on What can go wrong: failure and error concepts.
- Make no timing assumptions. Do not assume when a result will become available.
- Decide entitlement in advance. Decide who in your organisation is entitled to receive each kind of result before you submit work.
Assumptions, trust and limitations
- Confidentiality of jobs is a design goal; the experimental implementation provides none.
- How job results would be made checkable is not described.
- The trust placed in the parties that would process jobs is not yet specified publicly; see Trust assumptions and responsibilities by participant.
- Open questions about very long-running work are recorded on Design note: operating under partial failure and evolving participation.
Not yet available, and how this page will grow
SDKs, interfaces, job status values and result formats are not yet available. Once released, this page would link to versioned job reference and to Submitting work and retrieving results. Further technical reference is not yet available.
What this page does not claim
This page does not claim that a job interface exists, that any specialised compute worker is available, any job duration, cost or refund terms, or that any confidentiality protection exists today. Anything not stated here as available should be treated as unavailable.
Related pages
- Submitting work and retrieving results — the planned developer experience, with an illustrative walkthrough.
- Lifecycle stages used in this documentation — definitions of the stage terms used in the table.
- Confidential computation — the capability jobs rely on, and its simulation status.
- Fees and cost estimates — metering of confidential computation and fee status.
- What can go wrong: failure and error concepts — failure categories to design for.
- Transaction lifecycle: from submission to result — the lifecycle for ordinary transactions.
- Design note: operating under partial failure and evolving participation — open questions about very long-running work.
Glossary
References
No approved public references yet.
