In one minute
- Goal: All honest nodes end up with the same ledger, even if some participants are offline or malicious.
- Two key properties: Safety (no conflicting histories) and liveness (the system keeps making progress).
- Finality: Some systems have probabilistic finality (confidence grows with confirmations); others have deterministic finality (locked once a quorum signs).
Note: Educational only — not financial advice. Never share your seed phrase. Verify official links and addresses.
How blockchains reach consensus (plain English)
1) Propose
Someone proposes a new block of transactions (a miner, validator, or sequencer).
2) Share
The block is broadcast (gossiped) to the network so other nodes can check it.
3) Verify
Nodes verify signatures, balances, and rules. Invalid blocks are rejected.
4) Decide
Nodes follow a fork-choice rule to decide which valid block becomes part of the canon chain.
If two valid blocks arrive at the same height, a temporary fork can form. The protocol’s rules tell nodes which side to extend.
Major families of consensus
Nakamoto-style (longest/most-work chain)
- Examples: Proof of Work (PoW) and some Proof of Stake (PoS) designs that extend a single chain using a fork-choice rule.
- Finality: Probabilistic — confidence increases with more confirmations.
BFT-style voting
- Examples: Protocols where validators vote in rounds and finalize blocks with a quorum signature.
- Finality: Deterministic once enough votes are collected (exact thresholds depend on the design).
Proof of Work (PoW) — the basics
- How it proposes blocks: Miners compete to solve a puzzle. The winner broadcasts a block.
- Security idea: Attacking requires massive computing power and energy.
- Difficulty: Adjusts so blocks arrive on a steady schedule.
- Pros: Simple, time-tested, easy to verify.
- Trade-offs: Energy-intensive; block space is scarce; finality is probabilistic (wait for confirmations).
Proof of Stake (PoS) — the basics
- How it proposes blocks: Validators lock up (stake) coins and take turns proposing/attesting.
- Security idea: Misbehavior can be punished by slashing (losing stake).
- Randomness and committees: Many PoS designs use randomness to pick proposers and small voting groups.
- Pros: Energy-efficient, fast finality when combined with BFT-style voting.
- Trade-offs: Complex; stake can concentrate; requires careful design to resist long-range and censorship attacks.
Finality: how sure is sure?
Probabilistic finality
Confidence grows as more blocks build on top of yours. People often wait for N confirmations for larger transfers.
Deterministic finality
Once a validator quorum signs, the block is locked. Reverting it would require breaking the quorum’s assumptions.
Wallets and exchanges display “confirmations” or “finalized” to help you gauge risk.
Forks and upgrades
- Temporary forks: Two valid blocks at the same height — usually resolve quickly.
- Protocol upgrades: Networks update rules via software releases. If not everyone updates, the chain can split.
- Soft vs hard fork: A soft fork tightens rules in a backward-compatible way; a hard fork changes rules that older software will not accept.
Common attack ideas (high level)
- Majority attacks: Control enough mining power/stake to rewrite short history or censor transactions.
- Selfish mining / proposer games: Strategic withholding of blocks to gain advantage.
- Nothing-at-stake (PoS): Voting on multiple forks if there is no penalty — mitigated by slashing/finality.
- Long-range attacks (PoS): Old keys try to rewrite very old history — mitigations include checkpoints and finality rules.
- Network-level attacks: Censorship or partitioning of nodes/validators.
- Centralization risks: Few miners/validators, one client, or one sequencer can become choke points.
Reading confirmations like a pro
- Confirmations: How many blocks built on top of yours.
- Finalized: Some explorers show a “finalized” label when a block is locked by the protocol.
- Tip: For large transfers, wait for more confirmations or explicit finality, depending on the chain’s rules.
Simple checklists
As a user
- For big transfers, wait for sufficient confirmations/finality.
- Double-check you are on the right network and address format.
- Prefer wallets/explorers that clearly show status and confirmations.
As a builder
- Handle reorgs: do not assume a transaction is final until the chain says so.
- Use reliable RPCs and consider multiple providers.
- Document safety recommendations (for example, “wait N confirmations”).
Educational content only. Do your own research.
Quick glossary
- Fork-choice rule: How nodes pick which chain to extend.
- Confirmation: A new block built on top of yours.
- Finality: When a transaction is considered irreversible by protocol rules.
- Validator: A participant who proposes/attests to blocks in PoS/BFT systems.
- Slashing: Penalty that burns or locks stake for misbehavior.
- Checkpoint: A reference point in history used to prevent deep rewrites.