Threat model and misbehaviour defences
Development status: Being explored — The design is being explored; its public interface and support are not settled. Layered defences against validator collusion and misbehaviour, including redundancy, bonded evidence and challenge periods, are being explored and none of them is implemented; an experimental penalty library exists internally, but no penalties are enforced on any available network. No detailed threat model, fault assumptions or attack analyses are published, and nothing is publicly available for live use.
Before you read: Security model, trust and limitations.
Which threats is the design meant to resist, and what defences are intended against misbehaving participants? This page explains what a threat model is for, names the broad kinds of misbehaviour the design is meant to resist, describes the intended layered defences at concept level and states plainly that none of them is implemented. It then relates the defences to penalties, disputes, staking and emergency controls, and lists what is not yet described. Values, timing and internal analyses are not given.
What a threat model is for
A threat model states who might act against a system, what they might try, which defences are intended and what those defences assume.
- Why it matters. It lets researchers and assurance readers judge whether defences fit the risks, and lets operators understand what they would be defending against.
- What this page provides. Intended defence categories only. A detailed threat model with explicit fault assumptions is not published.
- What it is not. No defence described here is an assurance.
Kinds of misbehaviour the design is meant to resist
Status of this section: Being explored — broad categories only.
Table: broad kinds of misbehaviour the design is meant to resist, with an example of each and where each is discussed.
| Kind of misbehaviour | Example | Discussed on |
|---|---|---|
| Validator collusion and misbehaviour | Validators colluding to influence results, or an individual validator misbehaving | This page |
| Interface abuse | Excessive or repeated requests to the network’s interfaces | Request abuse and replay protection |
| Message reuse | A message being reused in a context, or at a time, it was not meant for | Request abuse and replay protection |
| Observation of visible information | Observers learning from information that remains visible even when data is protected | What remains observable |
These are broad categories, not an attack analysis. How each would be detected or measured is not described.
Intended layered defences
Status of this section: Being explored — none of these defences is implemented in the experimental implementation or on any network.
Layered means that no single defence is expected to be sufficient on its own; several would work together. Three defence categories are being explored.
Redundancy
Status: Being explored — not implemented.
Redundancy means avoiding dependence on any single participant for important work. The intent is that the failure or misbehaviour of one participant would not, on its own, decide the outcome. How redundancy would be arranged is not described.
Bonded evidence
Status: Being explored — not implemented.
Bonded evidence means that consequences for misbehaviour would rest on evidence and on value that participants have committed in advance. The intent is that consequences follow from something that can be shown, rather than from suspicion alone. How evidence would be produced, assessed or acted on is not described.
Challenge periods
Status: Being explored — not implemented.
A challenge period is a set window of time during which a claim could be contested. What could be contested, and the length and operation of the windows, are not described.
How the defences relate to penalties, disputes, staking and emergency controls
Several neighbouring capabilities are documented on their own pages, each with its own status:
- Penalties. Misbehaviour is intended to be penalised. An experimental penalty library exists, and no penalties are enforced on any available network. See Penalties for misbehaviour.
- Disputes and appeals. How decisions could be contested is covered on Disputes and appeals.
- Staking. Validators are planned to stake to take part, and staking is not available on any network. See Staking and validator participation.
- Emergency controls. Scoped, time-bound controls with multi-party approval are being explored for limiting damage during incidents; none operates on any network. See Emergency controls and protocol safeguards.
How these mechanisms would work together with the defences above is not described.
What exists today
- None of the intended defences is implemented.
- An experimental penalty library exists internally; it enforces no penalties on any available network.
- The experimental implementation must not be relied on for security; see Known limitations of the experimental prototype.
- No attack testing results, resilience measurements or independent audit results are published; see Security assurance status and reporting problems.
What is not described, and open questions
- Fault assumptions — how many participants could misbehave, and in which ways, before the intended properties would fail — are not published. Assumptions from other networks should not be assumed to apply.
- Mechanics — detection methods, evidence, values, timing and internal analyses — are not described.
- Open research questions include which assumptions are acceptable for the intended uses, how the layers would interact and how their effectiveness would be evaluated. See Assumptions and open questions and Evaluation methodology and published results.
- Accountability. Research-level goals and open questions about accountability are discussed in Design note: accountability for misbehaviour.
Assumptions, trust and limitations
- Defence categories are intended and may change; their effectiveness is unproven.
- Every defence would itself rest on assumptions that are not yet stated publicly.
- Layering is a design approach, not evidence that the layers together would be sufficient.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once a reviewed threat model with explicit assumptions is approved for publication, this page would state it with its scope and date. Published evaluations of the defences would be linked from Evaluation methodology and published results, and changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- resistance to any specific attack;
- any tolerance figure;
- any penalty amounts or procedures;
- any assurance that misbehaviour would be detected or penalised.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Trust assumptions and responsibilities by participant — what each participant would be relied on for.
- Penalties for misbehaviour — the status of penalties.
- Disputes and appeals — how decisions could be contested.
- Design note: accountability for misbehaviour — research-level goals and open questions.
- Request abuse and replay protection — interface abuse and message reuse.
- Emergency controls and protocol safeguards — intended limits on emergency action.
- Assumptions and open questions — open questions about assumptions.
Glossary
- Threat model
- Misbehaviour
- Collusion
- Redundancy
- Bonded evidence
- Challenge period
- Validator
- Penalty
- Staking
- Emergency controls
References
No approved public references yet.
