Why consensus exists
Blockchains are many computers sharing one ledger without a boss. Consensus is the rulebook they use to decide which blocks become official history. Without it, every node could believe a different version of “who paid whom,” and double-spend would be trivial.
The goal isn’t perfection—it’s convergence. Honest nodes should agree on the same chain, and bad edits should be expensive and obvious.
| Two branches appear… | Nodes do this | Result |
|---|---|---|
| Branch A (more work/stake) | Check validity, add to tip, keep building | A becomes canonical |
| Branch B (less work/stake) | Hold temporarily; drop if it stays behind | B is orphaned/reorged |
Key ingredients
Validity rules: Every node checks signatures, balances, block structure, and links. A valid block follows the protocol; an invalid one gets dropped.
Fork choice rule: When two valid chains compete, nodes pick the one with the most work/stake/weight. On Bitcoin, it’s the longest (most cumulative proof-of-work). On many PoS chains, it’s the chain justified and finalized by validators.
Sybil resistance: Proof-of-work burns energy to create blocks; proof-of-stake requires bonded stake that can be slashed. Both make it costly to pretend to be “many honest nodes.”
Proof-of-Work (PoW)
Miners compete to solve a hash puzzle. The winner proposes a block; others verify it. The “longest chain” (most cumulative work) wins. Attacking requires majority hashpower and money for energy/hardware. Benefit: simple, battle-tested. Cost: energy use and slower finality.
Proof-of-Stake (PoS)
Validators bond tokens and take turns proposing blocks. Others attest. Misbehavior can be slashed (stake destroyed). Finality gadgets (like Ethereum’s Casper FFG) let nodes agree that blocks are “final” after enough attestations. Benefit: lower hardware/energy needs, faster finality. Cost: new attack surfaces (long-range attacks, governance capture) and reliance on economic penalties.
| Aspect | Proof-of-Work | Proof-of-Stake |
|---|---|---|
| Sybil cost | Energy + hardware burn | Staked capital (slashable) |
| Finality | Probabilistic (confirmations) | Can be explicit (justified/finalized) |
| Attack requirement | >50% hashpower, ongoing burn | >33–50% stake, slash risk |
| Main risks | Energy arms race, pools | Stake cartels, long-range, governance capture |
“Consensus isn’t about trusting everyone. It’s about making it costly to cheat and easy to spot the cheaters.”
Forks and reorgs
Sometimes two valid blocks land at the same height. Nodes may temporarily diverge (a fork). The fork choice rule resolves it: one branch gains more work/stake and survives; the other gets orphaned. Short reorgs are normal; deep reorgs are rare and alarming.
Protocol upgrades can also create forks (soft/hard). Hard forks require everyone to upgrade; otherwise the network splits. Soft forks tighten rules and can remain compatible if most miners/validators enforce them.
| Depth | Typical use | Rewrite cost |
|---|---|---|
| 1–2 blocks | Small payments | Low; reorgs possible |
| 3–6 blocks | Exchange deposits | Medium; expensive to race |
| 6+ blocks | High-value moves | High; attacker burns a lot |
Finality and confirmations
On PoW, finality is probabilistic: more confirmations make rewrites exponentially harder. On PoS with finality gadgets, blocks can become “finalized” after a few epochs, meaning reverting them would slash large amounts of stake.
Security assumptions
Consensus works if a majority of the weight (hashpower or stake) follows the rules. If attackers control the majority, they can censor or reorder recent history—though signatures and public data make the attack visible.
Clients must also avoid eclipse attacks (being isolated from honest peers) and choose honest checkpoints. Light clients often rely on trusted checkpoints or multiple sources to avoid long-range PoS attacks.
What consensus is not
It’s not a voting poll on “what price should be.” It’s a set of deterministic rules for ordering valid transactions. The network doesn’t care about your feelings; it cares whether the block fits the rules and has enough weight behind it.
How to verify as a user
Run a full node to check every rule yourself. If you can’t, use light clients that verify headers and proofs, and cross-check with multiple peers. Watch for the chain’s finality signals (confirmations or finalized epochs) before trusting large transfers.