Consensus

The Agreement Problem

Consensus means that many separate computers reach the same decision about shared data. In a blockchain the decision is which block comes next, and so which transactions happen in which order. In week 1 we said a single bank decides the order. Now thousands of nodes, run by strangers, must decide together.

This is hard for three reasons. Messages travel at different speeds, so nodes see events in different orders. Some nodes may fail or go offline. And some participants may lie on purpose to gain something. Computer scientists call a system that keeps working despite lying participants Byzantine fault tolerant, after a famous thought experiment about generals who must coordinate an attack when some of them may be traitors.

A blockchain consensus protocol must answer four questions. Who may propose the next block? How do others check it? What happens if two valid blocks appear at once? And how costly is it to cheat? Different networks give different answers, and those answers define their security.

Proof Of Work, Revisited

In week 3 we saw Bitcoin's answer. Miners compete to find a nonce that makes the block header hash fall below a target. The winner proposes the next block and collects the reward. Other nodes verify the block with one hash and check every transaction.

Security comes from external cost. Producing blocks requires real hardware and electricity, so rewriting the past requires paying that cost again. Nodes follow the valid chain with the most accumulated work, often called the longest chain. An attacker with a small share of total mining power rarely beats the honest majority in a race.

The trade-offs are clear. Proof of work has a long record of operation and a simple rule. It also consumes a large amount of energy by design, and mining tends to concentrate where electricity is cheap or hardware is available.

Proof Of Stake

Proof of stake replaces computing effort with locked capital. Participants called validators deposit coins as a stake. The protocol picks a validator to propose each block, usually through a random process weighted by stake, and other validators vote on whether the block is valid.

Security comes from the stake itself. A validator who breaks the rules can be punished by slashing, which destroys part or all of their deposit. Honest validators earn rewards. Cheating therefore costs money that is already inside the system, while energy use falls dramatically because no puzzle racing takes place.

Ethereum switched from proof of work to proof of stake in September 2022, an event known as the Merge. On Ethereum a validator deposits 32 ETH. Time is divided into slots of 12 seconds, and 32 slots form an epoch. In each slot one validator is chosen to propose a block, and a committee of other validators attests to it. We cover Ethereum properly in week 5.

• Proof of work: security from hardware and energy spent.
• Proof of stake: security from capital locked and at risk of slashing.
• Both: a rule for choosing who proposes and who may be punished for cheating.

Forks And Orphaned Blocks

Sometimes two miners find valid blocks at nearly the same moment. Different parts of the network see different blocks first, and the chain temporarily splits. This is a fork. Both branches are valid, and nodes keep both for a moment.

The next block resolves the tie. Whichever branch receives the next block becomes the heavier chain, and nodes switch to it. Blocks on the abandoned branch are called orphaned or stale. Their transactions go back to the pool of waiting transactions and are usually included in later blocks.

This explains why a payment with one confirmation can still reverse, although rarely. A confirmation is one block built on top of your transaction's block. Each further confirmation makes reversal less likely, because the attacker would need to outpace the honest network over more blocks.

Resolving A Fork

1. Two blocks appear at once
2. Nodes build on the first they saw
3. One branch gets the next block
4. Nodes switch to the longer chain
5. The losing block becomes an orphan

Honest nodes converge on one chain by following the same rule.

Soft Forks, Hard Forks And Finality

A protocol fork is a different idea: a change to the rules. A soft fork tightens the rules so old nodes still accept the new blocks. A hard fork loosens or changes the rules so that nodes must upgrade. If part of the community refuses to upgrade, the chain can split permanently into two networks with separate histories. Ethereum Classic exists because of such a split in 2016 after the DAO incident.

Finality describes how certain you are that a transaction cannot be reversed. In Bitcoin finality is probabilistic. Each new block makes reversal exponentially less likely, and many services wait for around six confirmations on large payments. No absolute guarantee exists, but the practical risk becomes very small.

Ethereum's proof of stake adds economic finality. A block becomes finalised after validators holding at least two thirds of the staked ETH have voted for it across two consecutive epochs, which takes about 13 minutes. Reverting a finalised block would require at least one third of all stake to break the rules, and the protocol would slash that stake. Reversal is possible in principle, but it would destroy a very large amount of value.

Soft And Hard Forks

Type	Rules change	Example
Soft fork	Stricter; old nodes still accept	Bitcoin SegWit, 2017
Hard fork	Looser; old nodes reject	Ethereum DAO fork, 2016

A hard fork can split the network if some nodes do not upgrade. Source: Bitcoin and Ethereum community records

The 51 Percent Attack

A 51 percent attack happens when one party controls a majority of the mining power (or, in proof of stake, a majority of the stake). With a majority, the attacker can build a private chain faster than the honest network and then publish it, replacing the public history.

Be precise about what this achieves. The attacker can reverse their own recent payments, which enables double spending, and can refuse to include certain transactions. The attacker cannot steal coins from other people's addresses, because that needs their signatures. The attacker also cannot create coins beyond the issuance rule, because full nodes reject such blocks.

Attacks are costly. Controlling a majority of a large network requires buying or renting enormous resources, and a successful attack tends to destroy the value of the very coins the attacker holds. Smaller chains have suffered attacks in practice, which is why a network's total security budget matters. Proof of stake adds a further deterrent: attackers risk slashing of their stake.

Validators, Nodes And Decentralisation

Distinguish three roles. Full nodes verify rules and keep the ledger. Block producers (miners or validators) propose blocks. Users send transactions. In both designs, every full node checks every block independently. Producers can propose, but they cannot force nodes to accept an invalid block.

Decentralisation is a spectrum, not a switch. Useful questions to ask of any network are: How many independent parties produce blocks? How easy is it to run a node on ordinary hardware? Who writes the client software, and how many different clients exist? What happens if a large operator, such as an exchange offering staking, goes offline?

Different answers produce different risks. When you evaluate a chain in later weeks, look for the spread of block producers, the cost of attack and the number of independent software clients, rather than a single headline number.

Comparing The Designs

Proof of work offers a simple, battle-tested rule and security tied to physical resources. Its costs are high energy use and slower, probabilistic finality. Proof of stake offers far lower energy use, faster and stronger finality, and the ability to punish misbehaviour directly. Its costs are greater protocol complexity and questions about how wealth concentration affects control.

Neither is the single correct answer. Each rests on a different assumption about what is costly for an attacker. In the exercise below you simulate both ideas in miniature: a node choosing between competing chains, and a protocol selecting validators in proportion to their stake.

Proof Of Work And Proof Of Stake

Question	Proof of work	Proof of stake
Who proposes blocks	Miners who find a valid hash	Validators chosen by stake
Scarce resource	Energy and hardware	Locked coins
Penalty for cheating	Wasted energy	Stake can be slashed
Example	Bitcoin	Ethereum since 2022

Both make rewriting history expensive, in different currencies. Source: Bitcoin whitepaper; Ethereum developer documentation

Key Terms

Consensus

Agreement among many computers on one shared history.

Byzantine fault tolerance

The ability of a system to keep working correctly even when some participants lie or fail.

Validator

A participant in proof of stake who locks a deposit and proposes or votes on blocks.

Slashing

A penalty that destroys part of a validator's stake after provable rule-breaking.

Fork

A split in the chain, either from two blocks found together or from a rule change.

Orphaned block

A valid block that lost out to a competing branch and is no longer part of the main chain.

Finality

The point after which a transaction cannot realistically be reversed.

51 percent attack

An attempt by a majority holder of power or stake to rewrite recent history.

Epoch

On Ethereum, a group of 32 slots of 12 seconds each.

Exercise: Simulate Fork Choice And Stake-Weighted Selection

1. Create consensus.py and represent a chain as a list of blocks, each with a number and a work value of 1.
2. Build two competing chains from a shared block: chain A with 5 extra blocks and chain B with 3 extra blocks. Write choose(chains) that returns the chain with the highest total work.
3. Add one more block to chain B so it overtakes A, and show that choose switches to B. Print which blocks were orphaned.
4. Create a validator table: Ana 32, Ben 64, Cem 160 ETH. Use random.choices with stake weights to pick a proposer 10,000 times and count each result.
5. Compare the counts with each validator's share of total stake and write two sentences on what you see.
6. Write a short paragraph: what could a 51 percent attacker do to your fork choice code, and what could they not do?

Further Reading

• Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008 (sections 4, 5 and 11)
• The Byzantine Generals Problem, Leslie Lamport, Robert Shostak and Marshall Pease, ACM Transactions on Programming Languages and Systems, 1982
• Proof of Stake: How I Learned to Love Weak Subjectivity, Vitalik Buterin, Ethereum Foundation blog, 2014
• Proof-of-stake (PoS), ethereum.org developer documentation
• Bitcoin and Cryptocurrency Technologies, Arvind Narayanan et al., Princeton University Press, chapter 2