Consensus families and finality

A payment that vanishes

Kofi sells phones in Douala. A customer sends him 500 units on a blockchain (fictitious figures). A few minutes later the payment shows in Kofi's wallet, inside a brand-new block. He hands over the phone. An hour later the payment is gone from the chain: the block containing it was abandoned by the network. There was no bug. Kofi took "seen in a block" for "final". They are two different things.

The words, one by one

• Block: a batch of transactions that the network accepts together. Each block contains the hash of its parent (workshop 104), which forms a chain.
• Fork: two different blocks naming the same parent. A common, honest cause: two proposers produce a block almost at the same time, and network latency (workshop 107) stops each from seeing the other in time.
• Fork-choice rule: the rule each node applies to name the "tip" of the chain it follows. Every node applies the same rule, but they do not necessarily see the same blocks at the same instant.
• Reorganisation (reorg): a node abandons its current branch for another one its rule judges better. The abandoned blocks become stale blocks (often called "orphans" in everyday usage). Their transactions go back to waiting, unless the new branch already contains them (you will meet that waiting queue, the mempool, in workshop 110).
• Finality: the point after which a block will no longer be reverted, under stated assumptions.

Two kinds of finality

Probabilistic finality: the more blocks are stacked on top of yours, the less likely a competing branch replaces it. The probability falls with each block, but it is never exactly zero. This is Bitcoin's case.

Deterministic finality: the protocol contains an explicit step that declares a block finalised. After that step, reverting the block requires breaking the protocol's security assumption (for example "more than one third of validators act maliciously"). This is the case of BFT protocols such as Tendermint/CometBFT.

Worked example: counting confirmations

A transaction enters the block at height 800. While block 800 is the tip, it has 1 confirmation. When the tip is block 805, it has 6 (block 800 and the five after it). A confirmation is simply the number of blocks, its own included, at the end of the branch that contains the transaction. The number "6" used for Bitcoin is a widespread habit, not a protocol rule: each receiver picks a threshold according to the value at stake.

What this does NOT guarantee

• Deterministic finality is not unconditional: if the assumption (for example "fewer than one third faulty") is false, the guarantee falls.
• "Finalised" says nothing about the real world: a finalised payment is still a payment sent to the wrong address if you made a mistake.
• The word "finalised" shown by a node reflects what that node has seen. An eclipsed node (workshop 107) can show you a false version of the chain.

Recap

A block is a proposal; finality is a judgement about the risk of it being replaced. Probabilistic: the risk decays. Deterministic: the protocol reduces it to a stated assumption.

Who proposes the next block?

In an open network anyone can show up. You cannot choose "node number 3": an attacker would create a thousand free identities. Bitcoin, described in Satoshi Nakamoto's paper (Bitcoin: A Peer-to-Peer Electronic Cash System), answers with a lottery: for a block to be valid, the hash of its header must be below a target. Finding a nonce that achieves this takes repeated tries (try it with the miner tool below this text; hashes come from workshop 104). The proposer is whoever wins the lottery; their chance is proportional to their share of the total hash power. The cost is hardware and electricity, not an identity.

Fork-choice rule: cumulative work

Nodes follow the valid branch with the most cumulative work, meaning the sum of the work (the inverse of the target) of all its blocks since genesis. In the simple case where difficulty does not change, this amounts to the longest branch; but the real rule is "most work", not "most blocks".

Reorganisation condition in proof of work: a node reorganises as soon as it receives a valid branch whose cumulative work exceeds that of its current branch. No vote, no permission message: it is a plain comparison.

Example: the current chain is G-A-B (work 1 per block: total 2). A miner secretly produces C' on A (G-A-C': total 2), then D' on C' (G-A-C'-D': total 3). As soon as D' is published, every node switches to the C'-D' branch. B becomes stale and its transactions go back to waiting. Try it in the fork-sim tool: add blocks to each branch and watch which tip is selected.

Why finality is probabilistic

Take an attacker controlling a share q of the hash power, against honest miners holding p = 1 − q. First model, heavily simplified (random walk): the probability that the attacker ever catches up from z blocks behind is (q/p)^z if q < p, and 1 otherwise. This model strongly underestimates the risk: it ignores the lead the attacker gains while the honest miners mine their z blocks. It is only for seeing the exponential decay in z, never for setting a threshold.

The calculation in Nakamoto's paper (section 11) accounts for that progress, using a Poisson distribution. Convention used here: z is the number of blocks added after the transaction's block, so c confirmations (lesson 1, own block included) correspond to z = c − 1. The values below are those of the paper's formula, compared with the simplified model:

Reading: with 10% of the power and the paper's formula, you need z = 5 (6 confirmations) to get below 0.1% (about 0.09%); with 30%, six blocks after the transaction still leave a 13% risk; with 45%, they leave roughly a three-in-four chance of reversal. These figures assume the paper's attacker (mining in secret from the block before the transaction, with constant power); later analyses refine the exact formula and the counting conventions, which we do not reproduce. The right number of confirmations depends on the value at stake and on the power an attacker can assemble.

The 51% attack

If q exceeds 50%, (q/p)^z is no longer below 1: the attacker eventually catches up from any deficit. They can then rewrite their own recent payments (double spend) and refuse to include certain transactions (censorship). No number of confirmations then bounds the probability of reversal (it tends to 1): depth only raises the cost of the attack (for example how long the power must be rented), and it is that cost which must exceed the expected gain (see the security exercise). They cannot forge someone else's signature, spend funds that are not theirs, or change the validity rules that full nodes apply: their invalid blocks would simply be rejected.

What this does NOT guarantee

• Proof of work does not guarantee immediate agreement: honest forks happen regularly.
• It does not say the selected branch is the "true" one in any moral sense: it is the most costly one to produce.
• The 50% threshold is a landmark that holds when blocks are rare relative to propagation time: with high network delay the tolerated share of power falls. Strategies such as selfish mining can also make a smaller coalition profitable, so 49% is not "safe".

Recap

Proposer: the winner of the hash lottery. Reorganisation: a valid branch with more cumulative work. Finality: probabilistic, growing with depth.

Choosing the proposer without burning electricity

In the stake-based (proof of stake) and BFT families, a known set of validators has deposited a stake (locked tokens). The proposer is no longer whoever computes the most: it is picked by a deterministic or pseudo-random rule, weighted by stake. In Tendermint/CometBFT (paper: The latest gossip on BFT consensus), for example, the proposer rotates in an order weighted by each validator's voting power.

The security model therefore changes nature: in proof of work we assume "less than half the hash power is malicious"; in BFT we assume "less than one third of the voting power is malicious" (workshop 108).

The BFT voting round, with numbers

Recall the calculation from workshop 108. With n = 3f + 1 validators, we tolerate f Byzantine faults and a quorum is 2f + 1 votes. For n = 7: f = 2, quorum = 5. A simplified round:

1. The round's proposer broadcasts a block.
2. Validators send a first vote (prevote) for that block.
3. If a quorum (5 of 7) prevoted, they send a second vote (precommit).
4. If a quorum of precommits is reached, the block is committed for good: this is deterministic finality.

Why two quorums cannot commit two different blocks: two sets of 5 out of 7 must overlap in at least 5 + 5 − 7 = 3 validators, which is f + 1. If at most f = 2 are Byzantine, at least one of the 3 is honest, and an honest validator never votes for two blocks in the same round. So the two quorums cannot name two different blocks. This is safety, here for a simplified round: successive rounds of one height are linked by a locking rule that we omit.

If 3 validators out of 7 are offline, only 4 remain: the quorum of 5 is unreachable. The chain stops: no new block, but no false block either. What is lost is liveness, not safety. Try it in the quorum-sim tool.

Reorganisation condition in BFT

In a BFT protocol with immediate finality there is no normal reorganisation: a committed block is final. For two conflicting blocks to be committed at the same height, more than one third of the voting power must have violated the protocol, typically by signing twice (double signing, or equivocation). A double signature is verifiable evidence and can be punished; not every violation is as easy to prove.

Hybrid chains

Some stake-based chains combine a fork-choice rule (the chain keeps growing even if finalisation lags) with a voting-based finality layer. On Ethereum, the Casper FFG mechanism marks checkpoints as "justified" then "finalised" with a two-thirds vote of the total stake (the exact convention, strict or inclusive, is discussed in workshop 108). Before finalisation, reorganisations are possible; afterwards, reverting one requires that at least one third of the stake be destroyable under the slashing rules. Order of magnitude: finalisation there takes roughly ten minutes, against a few seconds for Tendermint. Polkadot also follows a hybrid scheme: one layer produces blocks and a separate layer finalises them, so its "finalised head" can lag behind its "best head".

The "nothing at stake" problem and slashing

If signing blocks costs nothing, a validator can sign every branch: it always gains something, and forks never resolve. The answer is slashing. Signing two conflicting blocks loses a part of the deposited stake. The stake is therefore not just an entry ticket: it is a hostage.

What this does NOT guarantee

• BFT safety depends on the "fewer than one third" assumption. Beyond it, no guarantee.
• If more than one third is offline, the chain stops: safe but not live.
• Slashing punishes after the fact. It does not return the funds stolen in a successful double spend.
• A validator whose keys are stolen can be punished for a fault they did not commit: stake comes with key hygiene.

Recap

Proposer: chosen by stake. Finality: deterministic, by a quorum of 2f + 1. Reorganisation: only if more than one third violates the protocol (typically by signing twice). Punishment: the stake is the guarantee.

The integrator's question

A shopkeeper, a payment platform or an application developer has to answer a concrete question: how long must I wait before delivering? The answer depends on the consensus family. Here is the workshop's synthesis.

This table is simplified: every real network adds details. Some chains follow none of the three models to the letter.

Example: setting a delivery rule

Kofi receives 500 units on a proof-of-work chain. He estimates that a plausible attacker controls at most 10% of the power. With the "paper's formula" column of lesson 2's table (z = c − 1), two confirmations leave about 5% risk, three about 1.3%, five about 0.35%, six about 0.09%. For a 500-unit sale he sets a risk below 1% and decides to wait for five confirmations. For a 50,000-unit sale he would aim below 0.1% and ask for six or more. On a BFT chain he only waits for the block to be committed: "3 confirmations" makes no sense there, since a committed block is already final.

Reading documentation without being fooled

• "Confirmed" often means included in a block, not final. Check whether the text says "finalised" or "committed by quorum".
• A node reports the state it knows. If you query a single node and it is eclipsed or lagging, you will read a stale truth.
• A fast-finality chain is not "safer": it has a different failure model (halting rather than reorganising) and assumes a known set of validators.

What this does NOT guarantee

• This table does not rank chains from best to worst. The three families buy different things: permissionless openness, finalisation speed, energy cost.
• A confirmation threshold computed for a 10% attacker is wrong if the attacker can rent or buy 40% of the power, and no depth bounds the probability against a majority (it only raises the cost). A threat model is not a measurement.
• No number of confirmations protects against a wrong recipient, a scam or a badly designed contract.

Recap

To decide how long to wait: identify the family, find its reorganisation condition, estimate the strongest plausible attacker, then pick the depth or finalisation that makes the attack unprofitable for the value at stake.