Lesson 2 — Three consensus families — PoW, PoS, classical BFT
Question
Production blockchains run one of three consensus families. PoW (Bitcoin), PoS (Ethereum / Cosmos), and classical BFT (HotStuff / HyperBFT / Tendermint). Each makes a different trade-off across speed, energy, and finality.
Principle (minimum model)
- PoW (Proof of Work). Block production = solve a hash puzzle; longest chain wins. Probabilistic finality (more confirmations = safer). Energy-intensive. Bitcoin / pre-Merge Ethereum.
- PoS (Proof of Stake). Block production = staked validator selection; finality via a separate vote layer. Energy-efficient. Slashable for misbehaviour. Post-Merge Ethereum.
- Classical BFT (HotStuff / HyperBFT / Tendermint). Single-leader BFT; instant finality after vote collection. No energy cost; high throughput; less decentralised. Cosmos / Hyperliquid / Aptos.
- Finality differences. PoW = probabilistic (6+ confirmations). PoS = eventual finality (~12 minutes on Ethereum). Classical BFT = instant (one round).
- Throughput differences. PoW = ~10 tx/s (Bitcoin). PoS = ~30 tx/s (Ethereum). Classical BFT = ~1000+ tx/s (Cosmos / Hyperliquid).
- Decentralisation differences. PoW = highly decentralised. PoS = moderately (~32 ETH min stake). Classical BFT = less (need known validator set, typically ~100 validators).
- Hybrid designs. Ethereum PoS = Casper FFG (finality) + LMD-GHOST (fork choice). HotStuff = single-leader BFT but with pipelined voting. Hybrids combine the best of multiple families.
Worked example + steps
Three consensus families — PoW, PoS, classical BFT
Bitcoin, Ethereum, and Hyperliquid all run consensus. None of them picked the same family. Each one made a different trade against the 4-way impossibility from last lesson (safety / liveness / fault tolerance / no synchrony) — and that single choice determined everything else about their chain: throughput, latency, validator count, slashing semantics, even who's allowed to be a validator.
This lesson is the map of those three families and what each one costs you.
1. The three families at a glance
| Family | Examples | Finality | Throughput | Validator set | Sacrifices |
|---|---|---|---|---|---|
| Nakamoto / PoW | Bitcoin, ETH 1.0 | Probabilistic (~6 blocks) | ~7 tps (BTC) | Permissionless miners | Energy, finality time |
| Pure BFT | Tendermint, HotStuff, HyperBFT | Instant (1-2 RTT) | High (>1000 tps) | Bounded (~20-150) | Validator set bound, liveness on partition |
| Hybrid PoS | Ethereum 2.0 | Eventual (~13 min) | Medium | Large (~1M) | Complexity, gadget overhead |
Each family wins on one axis and loses on others. No free lunches. Your job is to pick which losses are acceptable for your chain.
2. Nakamoto / PoW — the original
Mechanism: Miners compete to solve a hash puzzle (find a nonce such that the block's SHA-256 hash starts with N zero bits). Whoever solves first gets to propose the next block. Other miners "vote" by building on top of it. The longest chain wins.
What this buys:
- Permissionless: anyone with hardware can mine
- No validator set: no key management, no slashing infrastructure
- Probabilistic finality: after k blocks, the probability of reorg drops exponentially
- Liveness under partition: each partition keeps producing blocks; they reconcile on heal
What this costs:
- Energy: hash puzzles burn electricity
- No instant finality: ~10 min × 6 confirmations = 1 hour for high-value tx
- No slashing: bad miners just lose hashpower; no economic punishment
- Low throughput: 1 block per 10 min × small block size = 7 tps
Verdict: PoW is for chains where censorship resistance and permissionlessness beat finality time. Almost no new L1 picks PoW in 2026. Tempo wouldn't. Hyperliquid wouldn't. You won't.
3. Classical BFT — the L1 architect's default
Mechanism: A bounded committee of validators (typically 20–150, identities known up front). A leader proposes a block. The committee votes. If 2/3+ vote yes, the block is final — instantly, no waiting for confirmations.
The classical references:
- PBFT (Castro & Liskov, 1999) — the foundational paper. 3-round protocol (pre-prepare, prepare, commit). O(n²) messages per block.
- Tendermint (Buchman, 2014) — added view changes, made it practical. Used by Cosmos, CometBFT.
- HotStuff (Yin et al., 2018) — collapsed the round structure to O(n) messages via threshold signatures. Used by Diem (formerly Libra), HyperBFT.
The key innovation: 2/3+ majority with 3f+1 validators gives you both safety and instant finality, as long as the network is synchronous enough for messages to arrive within timeout.
What this buys:
- Instant finality: 1-2 round trips = seconds
- Slashing: validators sign messages; you can prove double-signing cryptographically and slash their stake
- High throughput: parallel validators, deterministic schedule
- Predictable latency: under good conditions, sub-second
What this costs:
- Bounded validator set: O(n²) or O(n) messages per block limits n to ~100-200 max in practice
- Liveness halt on partition: if you can't get 2/3+ votes, the chain just stops
- Centralization risk: bounded validator set is permissioned (in practice)
Speed of light is ~140 ms around the world. With 2 rounds of voting, that's ~300 ms minimum. Real BFT chains cluster validators in low-latency regions to get under 1 second.
Verdict: classical BFT is the default for new L1s when finality matters more than validator count. Hyperliquid (HotStuff-derived). Tempo (likely Tendermint or HotStuff family). Most app-chains.
4. Hybrid PoS — Ethereum's path
Mechanism: Two protocols layered.
- Fork choice (LMD-GHOST): each block, validators attest to the head. The chain with most attestations (weighted by stake) wins. This part is Nakamoto-ish — probabilistic, no finality.
- Finality gadget (Casper FFG): every 32 slots (epoch), 2/3+ of validators by stake vote to finalize a checkpoint. This part is BFT — instant finality on checkpoints.
Why the hybrid? Ethereum has ~1M validators. Pure BFT doesn't scale to 1M (O(n) messages = 1M signatures per block). Hybrid gets:
- Large validator set (large committee = decentralization)
- Probabilistic head tracking (fast-but-not-final)
- Eventual finality every ~13 min (BFT-like guarantee on older blocks)
What this buys:
- Maximum decentralization: 1M validators is the largest validator set of any L1
- Best of both: fast tips + finality
- Economic security at scale: $50B+ staked, slashing applies
What this costs:
- Complexity: the spec is massive
- Slow finality: 13 minutes minimum (2 epochs)
- Slot-level liveness != finality: a block can be the head and still get reorged before finality
Verdict: hybrid PoS is what you pick if you need both 1M+ validators AND finality. Almost nothing besides Ethereum needs this. Most L1s pick pure BFT.
5. Decision framework — which family for your chain?
Picking consensus
│
┌─────────────────────────┼────────────────────────────┐
│ │ │
Validator count? Finality? Permissioned?
│ │ │
┌───┴───┐ ┌────┴──────┐ ┌────┴────┐
│ │ │ │ │ │
<200 >200 Need instant OK with eventual Yes No
│ │ │ │ │ │
BFT Hybrid PoS BFT Either BFT or PoW BFT-style PoW or
committee PoS
For Tempo: <100 validators, instant finality, permissioned (banks/Paradigm-approved). → Pure BFT (likely Tendermint-style).
For Hyperliquid: ~20 validators, instant finality, permissioned. → HotStuff family (this is exactly what they do — HyperBFT).
For Ethereum: 1M validators, eventual finality OK. → Hybrid PoS (this is exactly what they do).
6. What rethlab gives you
Reth's consensus component slot lets you ship any of these families as a node:
| Family | Reth integration |
|---|---|
| PoW | EthBeaconConsensus with proof-of-work configs (legacy) |
| PoS (hybrid) | EthBeaconConsensus — standard Ethereum |
| BFT | Custom Consensus impl + custom block producer |
We'll read the actual Consensus trait in Lesson 5 and walk through how Berachain swaps it (Lesson 7).
7. Practice
For each chain, identify the family and one specific trade-off:
- Solana
- Cosmos Hub
- Avalanche (subnets)
- Berachain
- Hyperliquid
(Answers vary; the point is the muscle of identifying trade-offs from publicly known design.)
Final check: in one sentence, why does Tempo almost certainly NOT use Ethereum-style hybrid PoS? What about Tempo's design makes hybrid the wrong choice? If your answer doesn't reference "validator count" or "payment finality requirements," re-read §5.
Summary (3 lines)
- Three families: PoW (Bitcoin, probabilistic finality, decentralised, slow) / PoS (Ethereum, eventual finality, slashable) / classical BFT (Cosmos / Hyperliquid, instant finality, high throughput, less decentralised).
- Trade-offs: PoW = decentralised but slow + energy-hungry. PoS = balance. BFT = fast but smaller validator set.
- Hybrid designs combine strengths (Ethereum PoS = Casper + LMD-GHOST). Next: Ethereum PoS in detail.