Design note: independently checkable randomness
Development status: Research — This note records goals, assumptions and open questions; nothing here is an assurance or a released feature. The design is being explored for deriving randomness from more than one source so that network duties can rely on randomness that others can check independently. This is a goal only: it is not part of any released network, and nothing described here is publicly available for live use.
Before you read: Problem statement and intended properties.
Why would network duties depend on randomness that others can check, and what is intended? This short note explains why randomness that others can check matters, states the intended goal at the level of outcomes, lists what the note does not describe and records the open questions. It names no technique, source or use.
Motivation
Some network duties may depend on randomness.
If whoever produces that randomness could predict or influence it, everyone else would have to trust that producer. That reliance would be a trust assumption in its own right, and an easy one to overlook, because randomness that has been steered can look just like randomness that has not.
Randomness that others can check independently would let participants rely on it without taking any single producer’s word for it.
The goal matters to researchers and assurance readers who want to judge what the network would ask its participants to trust.
The intended goal (being explored)
- The design is being explored for deriving randomness from more than one source, so that network duties can rely on randomness that others can independently check.
- Drawing on more than one source is intended to reduce dependence on any single source. Whether, and how far, it would do so is an open question.
- “Independently checkable” means that participants would not have to take the producer’s word for the randomness. How checking would work is not described.
- This is not part of any released network.
What this note does not describe
- Which sources would be used, or how they would be combined.
- Which network duties would rely on the randomness.
- Any specific technique or standard.
- Any property such as unpredictability or resistance to manipulation; none is claimed.
Assumptions the goal would rest on
- Sources and contributors. Checkable randomness would rest on assumptions about its sources and about the participants that contribute to it. These are not described.
- Cryptographic techniques. The techniques that make checking possible would rest on their own assumptions. The kinds of cryptography relied on are discussed at category level on Cryptographic foundations and trust roots, which also explains trust roots.
- Checkable is not the same as unpredictable. Being checkable after the fact is different from being unpredictable beforehand: randomness could be confirmed afterwards as correctly produced and still have been foreseeable to someone before it was used. This note treats both properties as open questions.
Open questions
- Which properties would the randomness need for the duties that rely on it — being checkable, being unpredictable in advance and resisting influence by any participant — and could they hold together?
- How far would drawing on more than one source reduce dependence on any single source, and under which assumptions?
- How would others check the randomness in practice, and at what cost?
- How would the goal 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
- This is a goal only and is not part of any released network; it may change, be deferred or be withdrawn.
- No analysis of resistance to manipulation is published.
- The goal is described in plain words because its terminology is not settled.
Not yet available, and how this page will grow
- Further technical reference is not yet available.
- If reviewed material is approved for publication, this note would state the goal more precisely, with its date.
- Status changes would be recorded in the Documentation change log.
What this note does not claim
This note does not claim:
- any technique, source or use of the randomness;
- unpredictability, or resistance to manipulation;
- that anything described here is available.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Assumptions and open questions — this note’s questions in the consolidated list.
- Design note: operating under partial failure and evolving participation — another design-stage note.
- Cryptographic foundations and trust roots — the kinds of cryptography relied on, at category level.
Glossary
References
No approved public references yet.
