Skip to content
← Consensus Engineering — Building L1 Consensus on Reth
Consensus Fundamentals
Lesson 2 of 12·CONTENT16 min40 XP
Course
Consensus Engineering — Building L1 Consensus on Reth
Lesson role
CONTENT
Sequence
2 / 12

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. Throughput depends more on block size, execution and hardware than on the consensus family, so per-family tx/s figures mislead. One published data point: Hyperliquid's docs say mainnet "currently supports approximately 200k orders/sec" and "the current bottleneck is execution".
  • Decentralisation differences. PoW = highly decentralised. PoS = moderately (~32 ETH min stake). Classical BFT = less (needs a known validator set, bounded by voting-message cost).
  • 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

FamilyExamplesFinalityThroughputValidator setSacrifices
Nakamoto / PoWBitcoin, ETH 1.0Probabilistic (~6 blocks)Low (1 block / ~10 min on Bitcoin)Permissionless minersEnergy, finality time
Pure BFTTendermint, HotStuff, HyperBFTInstant (1-2 RTT)HighBounded (known set)Validator set bound, liveness on partition
Hybrid PoSEthereum 2.0Eventual (~13 min)MediumLarge (~800k active, 2026-10)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 with a capped block size

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 (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 (HyperBFT, "a variant of HotStuff consensus" per its docs). Tempo (Simplex consensus via Commonware, per its README).

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 ~800k active validators (816,014 on 2026-10-28, counted from a public beacon node's /eth/v1/beacon/states/head/validators?status=active_ongoing). Pure BFT doesn't scale to that (O(n) messages = ~800k 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:

  • Large-scale decentralization: hundreds of thousands of validators
  • Best of both: fast tips + finality
  • Economic security at scale: ~43.8M ETH of effective balance staked (same beacon-node query, 2026-10-28), 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 hundreds of thousands of 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: permissioned validators (threat model), sub-second finality → Pure BFT (Simplex via Commonware, per its README).

For Hyperliquid: stake-weighted validator set (10k HYPE self-delegation to become active, per its staking docs), low latency → HotStuff family (this is exactly what they do — HyperBFT).

For Ethereum: ~800k validators, eventual finality OK. → Hybrid PoS (this is exactly what they do).

6. What Reth gives you

Reth's consensus component slot lets you ship any of these families as a node:

FamilyReth integration
PoWEthBeaconConsensus with proof-of-work configs (legacy)
PoS (hybrid)EthBeaconConsensus — standard Ethereum
BFTCustom Consensus impl + custom block producer

We'll read the actual Consensus trait in Lesson 5 and walk through how Berachain extends it (Lesson 7).

7. Practice

For each chain, identify the family and one specific trade-off:

  1. Solana
  2. Cosmos Hub
  3. Avalanche (subnets)
  4. Berachain
  5. Hyperliquid

(Answers vary; the point is the muscle of identifying trade-offs from publicly known design.)

Final check: in one sentence, why did Tempo pick a pure BFT protocol (Simplex) rather than 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.