Source-linked AI summary
DFINITY Technology Overview Series, Consensus System
Timo Hanke, Mahnush Movahedi, Dominic Williams
TL;DR
DFINITY addresses the challenge of building a secure, performant, flexible consensus mechanism with cryptographic randomness and rapid finality. It combines a decentralized threshold-signature VRF with beacon-driven leader ranking, weighted-chain selection, and notarization. Under normal operation, transactions become final after two confirmations plus 2∆, while some group registrations can be denied by an adversary controlling at least one-third of a group.
Problem
DFINITY seeks a consensus mechanism that provides rapid finality, predictable performance, scalability, cryptographic randomness, and decentralization.
Method
DFINITY combines a four-layer consensus design with a jointly produced threshold-signature VRF, beacon-driven leader ranking, weighted-chain fork resolution, and notarization.
Results
Under normal operation, transactions are final after two confirmations plus the maximum network roundtrip time 2∆.
Takeaways & Limitations
The random beacon drives consensus and is also available to applications, while notarization provides fast finality guarantees to clients and external observers.
Takeaways & Limitations
An adversary controlling at least one-third of a group can deny its super-majority registration signature, causing that registration to fail.
Abstract
from arXiv · showhide
The DFINITY blockchain computer provides a secure, performant and flexible consensus mechanism. At its core, DFINITY contains a decentralized randomness beacon which acts as a verifiable random function (VRF) that produces a stream of outputs over time. The novel technique behind the beacon relies on the existence of a unique-deterministic, non-interactive, DKG-friendly threshold signatures scheme. The only known examples of such a scheme are pairing-based and derived from BLS. The DFINITY blockchain is layered on top of the DFINITY beacon and uses the beacon as its source of randomness for leader selection and leader ranking. A "weight" is attributed to a chain based on the ranks of the leaders who propose the blocks in the chain, and that weight is used to select between competing chains. The DFINITY blockchain is layered on top of the DFINITY beacon and uses the beacon as its source of randomness for leader selection and leader ranking blockchain is further hardened by a notarization process which dramatically improves the time to finality and eliminates the nothing-at-stake and selfish mining attacks. DFINITY consensus algorithm is made to scale through continuous quorum selections driven by the random beacon. In practice, DFINITY achieves block times of a few seconds and transaction finality after only two confirmations. The system gracefully handles temporary losses of network synchrony including network splits, while it is provably secure under synchrony.
1 PROLOGUE
DFINITY aims to provide a fast, predictable, scalable virtual blockchain computer secured by consensus and cryptographic randomness. Its built-in VRF supports consensus and higher-level applications.
- DFINITY seeks fast finalization, predictable performance, unbounded computational and storage scaling, cryptographic randomness, and decentralization at large scale.The design targets short block times, few confirmations, approximately constant confirmation intervals, and growth to millions of nodes.
- The document focuses on DFINITY’s consensus backbone and cryptographic randomness.
- An unbiasable, verifiable random function is built into the protocol’s core and drives consensus.The VRF is also available to smart contracts and the virtual machine.
2 INTRODUCTION
DFINITY organizes consensus into four layers: identities, a decentralized random beacon, a beacon-driven blockchain, and notarization for near-instant finality. Registered clients use permanent pseudonymous identities and can join through stake deposits.
- DFINITY’s four consensus layers provide identities, randomness, beacon-driven blockchain construction, and notarization-based finality.The notary supplies timestamping and publication guarantees and is responsible for near-instant finality.
- Clients have registered permanent pseudonymous identities, and new clients can join through stake deposits with lock-up periods.Registration can impose larger penalties for misbehavior than forfeiting a proof-of-work block reward.
1st layer: Identities and Registry.
The identity layer maintains registered client identities, while the random beacon uses jointly produced threshold-signature VRF outputs that remain unpredictable until release.
- The identity layer provides a registry for all clients.
- New clients can register through stake deposits with a lock-up period.
- The random beacon is an unbiasable, verifiable random function jointly produced by registered clients.Its construction relies on a unique, non-interactive threshold signature scheme, with BLS identified as the only practical scheme providing these features.
2nd layer: Random Beacon.
The probabilistic slot protocol ranks clients deterministically from unbiased random-beacon output and uses proposer rank to weight blocks and resolve forks.
- The probabilistic slot protocol ranks clients for each chain height using the unbiased random-beacon output for that height.
- Blocks proposed by higher-ranked clients receive greater weight, and forks favor the chain with the greatest accumulated block weight.
3rd layer: Blockchain and fork resolution.
The probabilistic slot protocol ranks clients deterministically from beacon outputs, weights proposals by rank, and resolves forks by accumulated chain weight. Notarization accelerates finality while tolerating occasional multiple notarizations.
- Instantaneous ranking supports predictable, constant block times and avoids bursty bandwidth use caused by races between clients.
- RSA-based alternatives exist, but setting up their threshold keys without a trusted dealer is impractical.
- Notarization speeds finality, but more than one block may be notarized at a height because notarization is not full consensus.This design is presented as the reason DFINITY can maintain high speed and short block times.
4th layer: Notarization and near-instant finality.
Notarization acts as a timestamp and proof of publication that supports fast finality and prevents secret chains of linked notarized blocks. Committee delegation and conservative split handling extend the design toward scalable, fault-tolerant operation.
- Notarization prevents adversaries from building and sustaining a secret chain of linked notarized blocks, avoiding selfish mining and nothing-at-stake problems.
- Randomly sampled committees safely and efficiently perform beacon and notarization protocols, enabling consensus designed for millions of clients.
- Threshold Relay transfers protocol execution from one pre-configured committee to another after temporary execution on behalf of all clients.
- During an approximately even network split, the random beacon pauses within a few blocks and resumes after reconnection; a significantly larger component may continue.
- If two client implementations are evenly widespread and disagree, both pause; if one is isolated, the broader network likely continues while it pauses.
- The document presents consensus, system models, protocol details, Threshold Relay, open participation, and security analysis as successive parts of the overview.
3 A HIGH-LEVEL VIEW OF THE CONSENSUS PROTOCOL
DFINITY consensus proceeds in rounds: beacon randomness ranks participants, clients propose blocks, a notary selects and signs a preferred block, and the beacon advances after notarization. The beacon’s unique threshold signatures make output agreement automatic, while the notary handles live block inputs through decentralized operation.
- Clients participate in the random beacon, decentralized notary, block proposal, and observation of the finalized chain.
- Committees improve scalability by sampling a smaller, changing participant set whose size is configured from a failure-probability calculation.
- At round r, beacon output ξr deterministically ranks clients, giving higher-priority proposers a greater chance of notarization and continuation.
- After receiving valid randomness, clients propose transaction blocks; the notary waits BlockTime, selects the highest-ranked proposal, and broadcasts its signature.
- The beacon advances to round r + 1 after clients receive a notarized block and extend their blockchain copies.
- Unique threshold signatures make agreement on each beacon output automatic, avoiding Byzantine agreement for every output.
- Unlike the beacon, the notary must agree on live block input rather than on a pseudorandom number, requiring a different consensus role.
4 MODELS AND PRELIMINARIES
This section defines DFINITY’s replica, group, network, adversary, cryptographic, and blockchain models. It also gives probabilistic committee-sizing results and formalizes authenticated chains and their computational uniqueness.
- System model: Replicas use agreed public keys, sign protocol messages, and accept messages only from recognized replica identities.
- Groups and adversary: A committee is the active group that drives progress and consensus, with all groups sharing a configured size n.
- Network model: The practical model is semi-synchronous with known message-delay distribution, while formal security proofs assume a known upper bound Δ.
- Network model: BlockTime controls liveness and T controls safety through locally triggered timers without global time or synchronized clocks.
- Network model: Rounds advance from local events and are not expected to be synchronized across replicas.
- Groups and adversary: A Byzantine replica may behave arbitrarily, including refusing participation or coordinating attacks with other replicas.
- Groups and adversary: A group is honest when n > 2f(G), and the protocols assume every group used by the system is honest.
- Committee sizing: Under an honest universe, each committee is a random sample whose probability of honesty can be calculated using the hypergeometric distribution.
5 PROBABILISTIC SLOT PROTOCOL AND NOTARIZATION
The probabilistic slot protocol uses beacon-derived rankings and accumulated block weights to guide fork choice, while notarization enforces timely publication and supports liveness and consensus under stated conditions.
- Probabilistic slot protocol: The PSP uses each round’s beacon output to rank clients and guide replicas toward the chain with greater accumulated block weight.Block weights decrease with proposer rank, instantiated as w(x) = 2^-x.
- Round protocol: Each round advances through beacon generation, block proposal, notarization, and formation of the next beacon output.The beacon and block protocol advance in lockstep across rounds.
- Notarization: Notarization acts as both a timestamp and proof of publication, preventing late proposals and secret conflicting chains from being sustained.Only timely published block proposals can get notarized.
- Notarization: Notarization guarantees at least one proposed chain head is notarized, but it does not itself imply consensus or require choosing a winning chain.Final chain selection is handled separately from notarization.
- Properties: The protocol cannot deadlock because replicas continue signing the highest-priority proposal until observing a notarization, after which they advance to the next round.This guarantee depends on the quorum condition |U| > 2f(U) and propagation assumptions.
- Properties: If the highest-priority proposer is honest and BlockTime is sufficiently large, exactly one block is notarized; correctness holds when BlockTime ≥ 3∆.Here ∆ bounds network traversal time.
6 FINALIZATION
The finalization protocol collects notarized blocks by round and outputs their longest common prefix once no further referenceable notarizations can arrive. Under its correctness assumption, finalized output is append-only, with timing guarantees tied to network traversal.
- Finalization procedure: Observers bucket notarized blocks by round and finalize a round when its bucket contains all chain tips that can still survive.Finalization outputs the longest common prefix of that bucket.
- Correctness assumption: The correctness assumption requires that, when Finalize(h) runs, the bucket N_h contains every round-h block that can get referenced.This assumption is stated as condition (6.1).
- Properties of finalization: When the correctness assumption holds, the finalized chain is append-only and can therefore be treated as finalized.Successive finalization outputs cannot retract earlier finalized content.
- Properties of finalization: The finalization view excludes blocks that can no longer become part of any surviving chain once the relevant reference window has closed.Figure 7 illustrates this by marking excluded blocks as DEAD and the common prefix as FINAL.
- Timing guarantees: If network traversal time is bounded by ∆, condition (6.1) holds when T ≥ 2∆, independently of the notaries’ BlockTime.This separates the observer’s finalization parameter T from the protocol’s BlockTime.
7 DECENTRALIZED RANDOMNESS BEACON
The decentralized random beacon produces fast, verifiable randomness through unique, non-interactive threshold signatures, with DKG establishing reusable secret shares and public verification information.
- Beacon properties: The beacon lets replicas agree on a verifiable random function whose outputs are unpredictable from prior outputs and publicly verifiable.Each round produces a new output, and the protocol’s unbiasability depends on the threshold-signature construction.
- Threshold signatures: The protocol uses unique t-of-n threshold signatures: t shares create a group signature, while fewer than t shares cannot predict its outcome.The same threshold conditions also determine whether an adversary can prevent signature creation.
- Threshold signatures: Non-interactive signing produces a group signature after one communication round from each participating party, without further interaction.This supports fast repeated beacon outputs after the initial setup.
- Setup: DKG allows parties to establish a group public key and individual secret shares without a trusted party, with shares reusable for unlimited group signatures.DFINITY uses Joint-Feldman DKG for this setup.
- BLS construction: Pairing-based schemes derived from BLS are identified as the only known schemes combining unique, non-interactive threshold signatures with practical DKG.The paper uses the original BLS scheme and its threshold version, TBLS.
- BLS construction: In TBLS, Recover combines t signature shares into a group signature whose output is independent of which t parties supplied the shares.The resulting signature can be verified using the group public key.
8 SCALABILITY
DFINITY scales beacon and notarization operations through randomly sampled committees and threshold relay, while an epoch-based registration process supports changing participation under explicit failure conditions.
- Committee scalability: Randomly sampled committees keep beacon and notarization message complexity bounded as the total replica population grows.Committee size is selected through failure-probability analysis so groups are honest with acceptable probability.
- Committee scalability: Threshold relay uses beacon outputs to select successive committees, which jointly produce the next randomness output before activity moves onward.The same committee can serve notarization and beacon protocols in a round.
- Committee setup: Groups are formed from a seed, run DKG to create group keys, and store those keys in the genesis block.The mechanism creates m groups using the Group(ξ, j) procedure.
- Open participation: Open participation is organized into fixed-length epochs, with registry blocks summarizing registrations and de-registrations from the preceding epoch.New replicas submit registration or de-registration transactions for inclusion in the chain.
- Open participation: A candidate group registers only when its DKG succeeds, it obtains a super-majority signature, and its registration transaction enters the blockchain during the relevant epoch.The first-round beacon output defines candidate groups, bounded by mmax.
- Open participation: An adversary can block some group registrations by preventing DKG or super-majority signatures, but variance means this affects only some candidates.With a 2/3 super-majority, control of at least 1/3 of a group can deny its signature; an adversary controlling less than 1/3 of the whole population controls less than 1/3 in at least half of groups.
- Open participation: Groups are automatically de-registered after expiring for a fixed number of epochs, while l is chosen above the minimum to reduce light-client load.The parameter limits the rate at which key frames are produced.
- Open participation: Newly registered entities become active in epoch e + 2, creating at least l rounds between registration and first activity.The gap ensures registrations are finalized before entities can influence the random beacon.
9 SECURITY ANALYSIS
The security analysis derives a robust, fast ledger abstraction from network, timing, relay, and notarization properties. Under stated timing conditions, replicas make continuous progress while preserving ledger guarantees.
- Ledger properties: The analysis establishes persistence and liveness as the ledger’s fundamental properties.Persistence follows from chain consistency and growth; liveness follows from chain quality and growth.
- Network assumptions: Notarizations and notarized blocks are relayed for any round, whereas proposals and signatures are relayed only for the current round.This relay policy supports the network-saturation arguments used in the security proofs.
- Network assumptions: A valid artifact processed by an honest replica eventually saturates the network, and an honestly signed block causes its notarized predecessor to saturate.These properties do not extend to artifacts relayed under the alternate policy, individual signatures, or the block itself.
- Timing model: The timing analysis assumes bounded message delay ∆ and zero processing time, while allowing multiple notarizations in a round.Replica entry times are defined from received notarizations, and the protocol is shown to make continuous progress.
- Progress: BlockTime ≥ 3∆ guarantees normal operation when the highest-priority replica is honest and ensures finite entry times for every honest replica.With BlockTime ≥ ∆, honest replicas’ round numbers differ by at most one.
9.3 Near-Instant Finality
Near-instant finality is obtained by finalizing notarized blocks after a short confirmation window under normal operation. The analysis also derives persistence, liveness, chain growth, consistency, and quality guarantees.
- Finalization correctness: Finalization is correct when T ≥ 2∆ because all notarizations that could still be referenced have already been received.This prevents an honest replica from finalizing before a potentially relevant notarization arrives.
- Near-Instant Finality: Under normal operation, every transaction in a round-r block is final after two confirmations plus 2∆.The observer finalizes round r after seeing a notarized successor and waiting T = 2∆.
- Chain properties: With BlockTime ≥ 3∆, chain growth holds with failure probability ρ using parameter k = ⌈−log_β ρ⌉.Under normal operation, the proof obtains the stronger local bound k = 1.
- Chain properties: Chain consistency holds when T ≥ 2∆, so finalized chains produced by honest replicas are prefixes of one another.Persistence then follows from consistency and growth, while liveness follows from chain quality and growth.
- Chain properties: In an (ϵ,η)-typical execution, chain quality holds with µ = (1 − 1/β)(1 − ϵ) and l = η.The result relies on honest highest-priority proposers producing the sole notarization in normal-operation rounds.