Design note: operating under partial failure and evolving participation
Development status: Research — This note records goals, assumptions and open questions; nothing here is an assurance or a released feature. Graceful degradation under partial failure, and admitting alternative approaches to agreement and validator sets with protection against fake identities, are design-stage goals being explored; questions about very long-running work are recorded with them. None of these goals is implemented in the experimental implementation or on any network, and nothing is publicly available for live use.
Before you read: Problem statement and intended properties.
How is the design meant to behave under partial failures, and how might it admit new participants or alternative agreement approaches? This note records three design-stage goals — graceful degradation, admitting alternative approaches to agreement, and admitting validator sets with protection against fake identities — together with the assumptions they would rest on and the questions they leave open, including questions about very long-running work. None of the goals is implemented. How the network agrees on results is not described in this documentation, and this note does not describe it.
Motivation
Shared networks face partial failure. Some participants become unavailable, slow or faulty while others carry on, and a network run by many parties has to expect this as a normal condition rather than an exception.
Participation also changes over time. Participants join and leave, and different uses may call for different approaches to agreement.
A design that works only when everything is healthy, or that cannot admit new participants safely, would serve poorly the organisations that rely on its results. Those organisations need to know what would happen when part of the network is in trouble, not only what happens when all is well.
Long-running work adds to the concern. A confidential job can last much longer than an ordinary transaction, which leaves it more exposed to failures and changes that occur while it is in progress. The intended job experience is described on Confidential jobs: tracking, cancelling and retrieving results.
Goal: graceful degradation under partial failure (design stage; not implemented)
- The design is being explored so that the network would degrade gracefully when part of the validator set is unavailable, rather than failing abruptly.
- In general terms, graceful degradation means continuing to provide what can still be provided safely, rather than failing all at once.
- How partial failure would be recognised, how the network’s behaviour would change and how recovery would happen are not described.
- No availability or uptime figure is stated or implied.
Goal: admitting alternative approaches to agreement (design stage; not implemented)
- The design is being explored for admitting alternative approaches to agreement after they pass a validation process.
- The intention is flexibility for different uses without weakening what applications would rely on.
- What the validation process would check, how an approach would be introduced and how it would relate to the network’s own agreement are not described.
- The experimental implementation offers no choice of agreement approach, and nothing of this kind is available.
Goal: admitting validator sets with protection against fake identities (design stage; not implemented)
- The design is being explored for admitting validator sets with protection against fake identities — that is, against one party presenting many identities to gain disproportionate influence.
- How identities would be established, what admission would require and how validator sets would change over time are not described.
- No claim is made that such protection would be effective, or that such attacks would be impractical.
Long-running work
How very long-running work would be handled over time, and how it would be affected by partial failure or by changes in participation, is not described in this documentation. The intended job experience — submit, track, cancel, refund and retrieve — is described on Confidential jobs: tracking, cancelling and retrieving results. The questions this raises are listed under Open questions below.
Assumptions the goals would rest on
- Failure and misbehaviour. Each goal would rest on assumptions about how many participants could fail or misbehave, and in which ways. These are not published. See Threat model and misbehaviour defences.
- Recognising failure. Graceful degradation would depend on recognising partial failure; how that would be done is not described.
- Trustworthy admission. Admitting new approaches or validator sets would rest on a trustworthy validation process and on whoever governs admission. See Governance proposals and decisions.
- Identity. Protection against fake identities would rest on assumptions about identity that are not described.
Limitations, and what this means today
- None of these goals is implemented in the experimental implementation or on any network.
- In the experimental implementation, several features of how the network agrees on results are simulated or not connected, and no result is reported as final. See Agreement and finality status.
- No availability, recovery or resilience measurements are published. See Security assurance status and reporting problems.
- For prospective node operators, there is nothing to prepare for. No admission requirements or procedures are published, and no public network exists. Rules from other networks should not be assumed to apply, and any future rules would be published with the network and software version they apply to. See Operating a node: intended roles and what exists today.
Open questions
- How would the network behave, and what would applications observe, when part of it is unavailable? How would recovery be recognised?
- How could alternative approaches to agreement be admitted without weakening what applications rely on?
- How could validator sets change over time while resisting fake identities, and under which assumptions?
- How would very long-running work be handled over time, and how would partial failure affect work still in progress?
- How would these goals be evaluated? See Evaluation methodology and published results.
These questions also appear in the consolidated list on Assumptions and open questions. No answer is published, and none should be inferred from the way a question is phrased.
Assumptions, trust and limitations
- These are design-stage goals; they may change, be deferred or be withdrawn.
- The goals are described in plain words because their terminology is not settled; the terms used here may change.
- Nothing in this note is an availability, resilience or security assurance.
Not yet available, and how this page will grow
- Further technical reference is not yet available.
- If reviewed design material is approved for publication, this note would describe the goals more precisely, with its date, and the change would be recorded in the Documentation change log.
- If this note is superseded, it would remain at this address with a “not current” banner linking to its replacement.
What this note does not claim
This note does not claim:
- any availability, uptime or fault-tolerance figure;
- any admission requirements;
- that protection against fake identities would be effective;
- any choice of agreement approach;
- any implemented feature.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Agreement and finality status — what the experimental status query reports, and why nothing is final.
- Assumptions and open questions — these questions in the consolidated list.
- Confidential jobs: tracking, cancelling and retrieving results — the intended experience for long-running jobs.
- Threat model and misbehaviour defences — intended defences and the fault assumptions that are not yet published.
Glossary
References
No approved public references yet.
