LibraryConsensus2018Design paperCorpus record
DFINITY Consensus System
Internet Computer. Timo Hanke, Mahnush Movahedi, Dominic Williams.
The DFINITY consensus overview: a randomness beacon, a ranking of block proposers, and notarisation so that a chain can come to agreement quickly among a large set. The Internet Computer is the later network built by the DFINITY foundation on this line of research.
The DFINITY consensus paper uses a random beacon and a threshold group to pick a block maker and notarize a chain quickly, aiming at a public chain whose 'final' confirmation is seconds away under its assumptions.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 7
Code
Source, repository, and what is actually hosted
- Internet Computer white papershttps://internetcomputer.org/whitepapers
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
A beacon picks the maker
Each round, a verifiable random output ranks who may propose. The randomness is produced by a threshold signature scheme so no single party computes it alone.
Claim 02 · Paper model
Notarization is a soft agreement
A group of replicas signs that a block is valid and timely. Several blocks in a round can be notarized. Notarization is not yet the final confirmation the paper also defines.
Claim 03 · Paper model
Finality is a later cut
The paper specifies when a notarized chain becomes uniquely extendable, so an application can treat it as final. Mixing up notarized and final is the usual misreading.
Claim 04 · Paper model
The Internet Computer is a larger ambition
Around this consensus sits a plan for canisters, subnets and hosting software rather than only recording balances. The consensus paper does not by itself prove that hosting story.
Claim 05 · Paper model
Threshold cryptography is the trust core
If the threshold key is biased or the committee is captured, the beacon is captured, and the beacon picks the leaders. The cryptography is not a module you can swap for a hash of the previous block without changing the proof.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 A beacon picks the maker
Observation
What the study says
Each round, a verifiable random output ranks who may propose. The randomness is produced by a threshold signature scheme so no single party computes it alone.
Model
What has to hold
The threshold ceremony produced a key no minority can reconstruct or bias.
Falsifier
What would retire it
Who holds the threshold key shares, and how are they reshared?
02 Notarization is a soft agreement
Observation
What the study says
A group of replicas signs that a block is valid and timely. Several blocks in a round can be notarized. Notarization is not yet the final confirmation the paper also defines.
Model
What has to hold
Enough replicas are online to complete the beacon and the notarization each round.
Falsifier
What would retire it
What is the round time under the delay the paper assumes?
03 Finality is a later cut
Observation
What the study says
The paper specifies when a notarized chain becomes uniquely extendable, so an application can treat it as final. Mixing up notarized and final is the usual misreading.
Model
What has to hold
Clocks and network delay fit the round time. A slow network creates notarized forks the finality rule must clean up.
04 The Internet Computer is a larger ambition
Observation
What the study says
Around this consensus sits a plan for canisters, subnets and hosting software rather than only recording balances. The consensus paper does not by itself prove that hosting story.
Falsifier
What would retire it
Which claims belong to consensus, and which belong to canisters, governance, or the cycles market?
05 Threshold cryptography is the trust core
Observation
What the study says
If the threshold key is biased or the committee is captured, the beacon is captured, and the beacon picks the leaders. The cryptography is not a module you can swap for a hash of the previous block without changing the proof.
Model
What has to hold
The threshold ceremony produced a key no minority can reconstruct or bias.
Falsifier
What would retire it
Who holds the threshold key shares, and how are they reshared?
03 Sequence
One action, as an operating tape
- 01Replicas share a threshold key setup for the beacon.
- 02At the start of a round they produce a random output. The ranking of proposers follows from that output.
- 03The selected proposer publishes a block extending a notarized parent.
- 04The notarization committee signs one or more timely valid blocks.
- 05Subsequent rounds apply the paper's rule for when one chain is final and alternatives can no longer win.
04 Load-bearing
The argument, and where a pitch drops it
Speed comes from a prepared committee
The cut
Threshold signing is fast when the set is ready and the network is calm. The paper's second-scale language belongs to that setting. A committee that has to be rebuilt, or a network that delays the beacon, loses the number first.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Threshold cryptography concentrates trust in the ceremony and the key-sharing assumption. That has to be read, not skipped.
Notarization on purpose allows more than one block
The cut
The protocol would be slower if it forced a unique block before anyone could proceed. It proceeds, then finalises. Applications that act on the first notarization are acting early. The paper gives them a later signal. They should wait for it if they need finality.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A later client, parameter or reward formula is a different object from this paragraph.
Hosting software raises problems consensus does not see
The cut
A canister that serves a web page needs data availability, upgrade policy and a story about who pays for cycles. Those questions sit beside the beacon. A study of DFINITY that only retells the random ranking has done half the work, but it should not pretend the beacon answered the other half.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A later client, parameter or reward formula is a different object from this paragraph.
05 Register
What has to be true
Stake and threshold · Not re-measured
The threshold ceremony produced a key no minority can reconstruct or bias.
Network · Not re-measured
Enough replicas are online to complete the beacon and the notarization each round.
Network · Not re-measured
Clocks and network delay fit the round time. A slow network creates notarized forks the finality rule must clean up.
Cryptography · Not re-measured
Clients can tell a notarization from a finality proof.
06 Divergence
What happened after the paper
The Internet Computer launched with subnets running this family of consensus, plus a governance system and a cycles market for computation. Those mechanisms are later and adjacent. The 2018 consensus paper remains the place to learn why notarized and final are different words.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
Large committees are slow if every round is a full Byzantine agreement from scratch, and they are unsafe if the next leader is known early enough to attack. The overview's answer is a random beacon that ranks potential proposers and a notary that signs the block it sees first among the admissible ones.
What the design proposes
- A threshold relay produces randomness that subsequent rounds depend on.
- Notarisation is not the same step as finality. The paper separates them.
- The goal stated in the series is a blockchain that can host software, not only balances.
How the mechanism is specified
- Threshold signatures keep the beacon unpredictable to any small coalition.
- A block that is notarised can still be excluded later if a higher-ranked alternative appears, until the finality rule says otherwise.
- Canisters, cycles and the later Internet Computer specification are not this 2018 overview.
What this page does not treat as proven
- The consensus overview is not the Internet Computer interface spec.
- Threshold cryptography concentrates trust in the ceremony and the key-sharing assumption. That has to be read, not skipped.
- This page does not evaluate the foundation's governance or token distribution.
Why the desk still reads it
Relevant when a venture wants 'the network hosts the app, not just the settlement'. The prior question from this paper is narrower: where does the randomness come from, and is notarisation being sold as finality.
09 Lexicon
Terms, opened into the record
- Random beacon
- A per-round random output, produced by threshold signatures, that ranks who may propose.
- Notarization
- A threshold signature that a block was valid and timely. More than one block in a round may receive it.
- Finality
- The later condition under which one notarized chain is the only one that can continue.
- Threshold signature
- A signature that any large-enough subset of key holders can produce, and a smaller subset cannot.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.