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.
The five-minute read
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.
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.
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.
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.
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.
One action, walked through
- Replicas share a threshold key setup for the beacon.
- At the start of a round they produce a random output. The ranking of proposers follows from that output.
- The selected proposer publishes a block extending a notarized parent.
- The notarization committee signs one or more timely valid blocks.
- Subsequent rounds apply the paper's rule for when one chain is final and alternatives can no longer win.
The argument, unpacked
Speed comes from a prepared committee
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.
Notarization on purpose allows more than one block
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.
Hosting software raises problems consensus does not see
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.
What has to be true
- The threshold ceremony produced a key no minority can reconstruct or bias.
- Enough replicas are online to complete the beacon and the notarization each round.
- Clocks and network delay fit the round time. A slow network creates notarized forks the finality rule must clean up.
- Clients can tell a notarization from a finality proof.
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.
What to check before you use the idea
- Is the application waiting for notarization or for finality?
- Who holds the threshold key shares, and how are they reshared?
- What is the round time under the delay the paper assumes?
- Which claims belong to consensus, and which belong to canisters, governance, or the cycles market?
Terms
- 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.
The problem the paper 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 a venture studio 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.
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.