← All Labs
IDEA #44 · DISTRIBUTED SYSTEMS — CONSENSUS

Consensus algorithms: how strangers agree without a boss

Thousands of computers that have never met, some of them lying, need to agree on one shared history — which transactions happened, in what order — with no referee anyone trusts. That is the real problem money on a blockchain solves; the coins are almost a side effect. Three tabs below let you run the three great answers live: Proof of Work burns electricity to make history expensive to rewrite, Proof of Stake bonds money that gets destroyed if you cheat, and Byzantine Fault Tolerant voting reaches agreement by supermajority even with liars in the room. Every counter is computed by a running simulator — flip a node to dishonest or offline and watch each protocol either route around it or stall.

TAB 1 · NAKAMOTO, 2008
Proof of Work
Miners burn hashes racing to find one below a target. Difficulty tunes block time; the longest chain wins. Give an attacker <50% and watch their fork lose.
TAB 2 · STAKE-WEIGHTED
Proof of Stake
Validators are chosen to propose in proportion to bonded stake. Double-sign and get slashed — cheating burns your own money.
TAB 3 · BFT / TENDERMINT
Byzantine Voting
A validator set votes in rounds and commits on a ⅔ supermajority — tolerating up to ⌊(n−1)/3⌋ liars. Add one too many and it stalls.
01

Drive it — mine a block

Each miner hammers a real hash function, changing a nonce until the output falls below the target. The first to find one wins the block and the chain grows. Raise difficulty and the target shrinks; add an attacker and watch two chains race — only the longest survives.
DRIVE IT
initialising…
DIFFICULTY (leading zero bits)18
HONEST MINERS4
ATTACKER HASHPOWER SHARE0%
TARGET
hash must be below
EXP. ATTEMPTS
per block, 2^d
BLOCK TIME
honest, live avg
The hash is a real 32-bit avalanche mix computed in your browser — not a fake number. A "found" block means a nonce whose hash genuinely landed below the target.
02

Walkthrough

Feel why work buys security.
WALKTHROUGH
1
Start with difficulty low. Watch the miners' best-hash readouts tick down and a block land almost instantly. Each attempt is a fresh nonce fed through the hash — pure trial and error, no shortcut.
2
Drag difficulty up two notches. The target shrinks by 4× each notch, so the expected attempts double per bit and block time stretches. This is the only knob a real network turns to keep block time steady as hashpower grows.
3
Now give an attacker 30% of the hashpower. A second (red) chain appears, mining privately. It grows — but slower. The honest chain pulls ahead and the attacker's fork is orphaned: the longest chain wins.
4
Push the attacker past 50%. Now the red chain out-paces honest miners and can rewrite history at will — the 51% attack. Security was never magic; it was just "honest majority owns more hashpower."
AHA
Proof of Work doesn't make cheating impossible — it makes rewriting history cost the same electricity all over again, faster than everyone else combined. Trust is replaced by a bill you can't afford.
03

Explanation

Hash puzzles, difficulty, and the longest-chain rule.
EXPLANATION

A cryptographic hash turns any input into a fixed-length number that behaves like a random draw: change the input by one bit and the output scrambles completely, and there is no way to run it backwards. Mining exploits exactly that. A miner assembles a candidate block (the pending transactions plus a link to the previous block) and appends a nonce — a throwaway counter. It hashes the whole thing, and if the result is a number below a target, the block is valid. If not, it bumps the nonce and tries again.

Because the output is effectively random, the only strategy is brute force. If the target admits a fraction 1 / 2^d of all possible hashes, you expect to try about 2^d nonces before you strike gold. That is the "work." The network watches how fast blocks appear and retargets d up or down to hold the average block time constant — Bitcoin aims for ten minutes.

The link to the previous block is what makes history expensive to change. Each block's hash feeds into the next, so tampering with an old block invalidates every block after it — you'd have to re-mine the entire suffix. Meanwhile honest miners keep extending the real chain. The agreed rule is dead simple: follow the chain with the most cumulative work.

An attacker who wants to erase a transaction must secretly build a longer chain than the honest network. With less than half the hashpower, the honest chain grows faster in expectation and the attacker falls further behind every block — the race is lost with overwhelming probability. Cross 50% and the arithmetic flips: the attacker now wins races and can rewrite recent history. Security rests entirely on honest hashpower staying in the majority, and on rewriting being as costly as the original mining.

04

Research note

The puzzle and the attacker's odds, exactly.
RESEARCH NOTE
A block is valid when its hash clears the target. With a d-bit target the success probability per nonce, and the expected number of hashes, are:
Attempts are geometric, so block-finding times are (approximately) exponential — which is why block intervals are so bursty.
If the attacker controls a fraction q of hashpower (honest p=1−q) and is z blocks behind, the probability they ever catch up is Nakamoto's gambler's-ruin result:
For q<0.5 this decays geometrically in z — a few confirmations make reversal astronomically unlikely. At q≥0.5 catch-up is certain. Source: Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008), §11.
01

Drive it — stake, propose, slash

Each slot, one validator is drawn to propose the next block, weighted by how much it has staked. Over many slots the selection frequency converges to each validator's stake share. Click a validator to make it double-sign; when it's caught, its bond is slashed and its power drops.
DRIVE IT
initialising…
SLOTS PER SECOND6
SLASH PENALTY50%
SLOTS RUN
0
blocks proposed
TOTAL STAKE
bonded ETH-ish
SLASHED
0
stake destroyed
Selection uses stake-weighted random sampling. The bars under each validator show observed proposal share; watch it track the expected share (the thin tick) as slots accumulate.
02

Walkthrough

Skin in the game, made literal.
WALKTHROUGH
1
Let it run. The proposer for each slot lights up. Early on the frequencies look lumpy, but after a few hundred slots each validator's observed share settles onto its stake share — no mining, just weighted dice.
2
Notice the whale (largest stake) proposes most often. Influence is bought, not burned. This is why PoS uses a rounding-error of the energy PoW does — there's no puzzle, only a lottery ticket sized by your bond.
3
Click a validator to mark it dishonest. When it next proposes it double-signs (equivocates — signs two conflicting blocks). Other validators submit the two signatures as proof, and the protocol slashes its bond by the penalty you set.
4
Watch the slashed validator's bar shrink and its future selection odds fall with it. Cheating didn't just fail — it destroyed its own money. Push slash penalty to 100% to see a validator wiped out in a single offence.
AHA
Proof of Stake swaps "burn electricity to be trusted" for "post a bond you'll lose if you lie." The security budget stops being a power bill and becomes the attacker's own capital, held hostage.
03

Explanation

Weighted selection, slashing, and nothing-at-stake.
EXPLANATION

Proof of Stake replaces "one CPU, one vote" with "one coin, one vote." To take part, a validator locks up a deposit — its stake. For each slot the protocol runs a public, verifiable random draw and picks a proposer with probability equal to its fraction of the total stake. A validator with 20% of the bonded coins proposes roughly 20% of the blocks. No puzzle is solved, so almost no energy is spent; the scarce resource being spent is capital committed and put at risk.

The obvious worry is the nothing-at-stake problem: without the cost of mining, why not sign every competing fork and always end up on the winner? The answer is slashing. Rules define provable misbehaviour — most importantly equivocation (signing two different blocks at the same height, or surround-voting). Anyone who observes both signatures can submit them as cryptographic evidence, and the protocol automatically burns part or all of the offender's stake and ejects it.

That single mechanism realigns incentives. Because a validator's own money is on the line, the rational move is to follow the rules: honest validation earns steady rewards, while a detectable attack costs more than it could ever gain. This is called economic finality — reverting a finalised block would require a supermajority of stakers to get themselves slashed, destroying billions in bonded value.

The trade-offs are real. PoS must guard against long-range attacks (rewriting ancient history with old keys) using checkpoints and weak subjectivity, and against stake centralisation, since wealth compounds influence. But the headline win stands: security no longer depends on out-spending the world in electricity, only on the attacker being unwilling to set fire to their own deposit. Ethereum's move to PoS in 2022 cut its energy use by roughly 99.95%.

04

Research note

Selection and the cost of equivocation.
RESEARCH NOTE
Validator i with stake s_i is chosen to propose with probability equal to its stake share; the law of large numbers pins the observed frequency to it:
After N slots the sampling error shrinks like 1/√N — which is exactly why the bars in the sketch stop wobbling.
Honest behaviour is a Nash equilibrium when the expected gain from an attack is dwarfed by the slashed bond. A crude condition:
where σ is the slash fraction. Since σ·s_i can be the validator's entire deposit, cheating is deterred whenever the honest reward stream beats the one-shot theft. Source: Buterin & Griffith, Casper the Friendly Finality Gadget (2017).
01

Drive it — vote to commit

A validator set runs a round: propose → prevote → precommit → commit. A block commits only when more than of validators vote for it. Toggle nodes to offline or Byzantine (liars). Up to ⌊(n−1)/3⌋ faults and it still commits; one more and the round stalls.
DRIVE IT
initialising…
VALIDATORS (n)7
ROUND SPEED1.0×
FAULT BUDGET f
2
⌊(n−1)/3⌋
QUORUM
5
votes needed
FAULTY NOW
0
offline+Byz
Green ring = honest, amber = offline (silent), red = Byzantine (votes for a conflicting block). The quorum arc must pass the ⅔ line for the block to commit.
02

Walkthrough

Find the exact edge of tolerance.
WALKTHROUGH
1
With all seven honest, watch a round: the proposer broadcasts, everyone prevotes, then precommits, the quorum arc sweeps past the ⅔ line, and the block commits. Fast, boring, correct — which is the point.
2
For n = 7 the fault budget is f = ⌊6/3⌋ = 2. Click two nodes to Byzantine. They vote for a bogus block, but the honest five still clear the quorum of 5. It commits anyway — the liars are simply outvoted.
3
Click a third node faulty. Now only four honest votes remain, below the quorum of five. No block reaches ⅔, so the round stalls and retries forever. You've crossed the 3f+1 boundary.
4
Bump n to 10: the budget jumps to f = 3. Tolerance grows in steps, never smoothly — you always need strictly more than three times the faults you want to survive. Try to break it by mixing offline and Byzantine nodes.
AHA
You can survive traitors and outages — but only up to a hard arithmetic wall: fewer than a third. Cross it and the network doesn't get "a bit wrong," it refuses to agree at all, which is the safe failure.
03

Explanation

The Byzantine Generals, quorums, and why one-third.
EXPLANATION

The Byzantine Generals Problem (Lamport, Shostak & Pease, 1982) frames it as generals surrounding a city who must agree to attack or retreat, communicating only by messenger — while some generals are traitors sending contradictory orders. The classic result is stark: reliable agreement is possible if and only if fewer than one-third of the participants are faulty. Modern BFT protocols — PBFT, Tendermint, HotStuff — are engineered around that exact bound.

They work by voting in rounds with a supermajority. A rotating proposer suggests a block; validators broadcast a prevote, then a precommit. A validator only commits once it has collected precommits from more than two-thirds of the set — a quorum. Two quorums of size > 2n/3 must overlap in more than n/3 members, so they always share at least one honest validator. That overlap is what makes conflicting commits impossible: you can never assemble two ⅔ quorums for two different blocks.

Write n = 3f + 1. Safety needs the two-quorum overlap to contain an honest node, and liveness needs the honest majority to be able to form a quorum on their own even if all f faulty nodes stay silent: n − f = 2f + 1 > 2n/3 holds exactly at this ratio. Push faults to f + 1 and both guarantees break — honest nodes can no longer reach the threshold, so the protocol halts rather than risk a fork.

That choice — stall instead of split — is deliberate. Unlike Nakamoto consensus, which always makes progress but only gives you probabilistic finality (a deep-enough block is almost irreversible), BFT gives instant, absolute finality: once committed, a block can never be reverted while faults stay under the bound. The price is that BFT needs a known validator set and tends to slow down as that set grows, since every node must hear from a supermajority of the others.

04

Research note

The one-third bound and quorum overlap.
RESEARCH NOTE
To tolerate f Byzantine faults a partially-synchronous BFT protocol needs at least 3f+1 validators, with a commit quorum of size:
Both safety (no two conflicting commits) and liveness (honest nodes can always reach quorum) hold simultaneously only when faults stay within this budget.
Safety comes from quorum overlap: any two quorums of size q share at least
members, which exceeds f — so the intersection contains an honest validator that will not vote for two different blocks. Sources: Lamport–Shostak–Pease, The Byzantine Generals Problem (1982); Castro–Liskov, Practical BFT (1999); Buchman, Tendermint (2016).
Idea #44 of the maths-visual-teaching series · Proof of Work · Proof of Stake · Byzantine Fault Tolerance · all simulators run live in your browser, no data faked.