Consensus

How distributed systems achieve agreement. From Nakamoto consensus to modern oracle networks.

The W3 Protocol architecture draws specific inspiration from these systems.

Bosco (2008)

One-step Byzantine consensus primitive. Optimizes for contention-free scenarios.

One-Step Byzantine Consensus

PROPOSE → DECIDE: ONE STEP WHEN CONTENTION-FREE
The Problem with Traditional BFT
Most Byzantine consensus requires 2+ communication steps even when everyone agrees. Bosco shows you can do it in 1 step when there's no contention.
Contention-Free: All Propose Same Value → Decide in 1 Step
Round 1
P1
v=A
P2
v=A
P3
v=A
P4
v=A
P5
v=A
P6
v=A
P7
v=A
all propose A
A
A
A
A
A
A
A
decide A immediately!
Contention: Mixed Values → Fall Back to Multi-Round
Round 1
P1
v=A
P2
v=A
P3
v=B
P4
v=A
P5
v=B
P6
v=A
P7
v=A
contention!
Round 2+
→ invoke fallback consensus protocol...
Strongly One-Step
n > 7t processors
Decide in 1 step even with t Byzantine failures (if correct processors unanimous)
Weakly One-Step
n > 5t processors
Decide in 1 step only when failure-free AND contention-free

Key insight: Traditional BFT assumes contention is common, so always pays the multi-round cost. Bosco inverts this: optimize for the common case (no contention), fall back when needed. For replicated state machines where clients rarely conflict, operations complete in just 2 message latencies (client → all replicas → client) — same as an unreplicated RPC!

  • Ordering: Implicit. Processors propose values; unanimous proposals decide immediately. No leader required for one-step path.
  • Participation: n processors, up to t Byzantine. Strongly one-step requires n > 7t; weakly requires n > 5t.
  • Finality: Immediate when contention-free. Falls back to standard BFT rounds otherwise.
  • Throughput: Optimized for low-contention workloads. One-step = one message latency to decision.
  • Security: Byzantine fault tolerant. Strong network adversary model (can reorder messages arbitrarily).

Foundational primitive: Bosco is not a complete blockchain — it's a consensus building block. Higher-level protocols can invoke it to agree on specific values (e.g., which replica handles a request, whether a result is valid). The one-step optimization matters for replicated services where operations are typically independent and contention-free.

Bitcoin (2009)

The original blockchain. Nakamoto consensus via Proof of Work.

Nakamoto Consensus

LONGEST CHAIN WINS

0
1
2
3
4
5
?
0
1
2
3
4
← orphaned
  • Ordering: Longest chain rule. Miners compete to extend chain; forks resolve by cumulative work.
  • Participation: Permissionless PoW mining. Hash rate = voting power. Anyone can join.
  • Finality: Probabilistic. ~6 blocks (~60 min) for 99.9% confidence. Reorgs exponentially unlikely with depth.
  • Throughput: ~7 tps. 1 MB blocks every 10 min. Intentionally conservative for decentralization.
  • Security: 51% attack requires majority hash rate. Economically expensive at scale.

Revolutionary simplicity: no coordination, no identities, just computational work. Trade-off: slow finality, high energy cost, limited throughput. Forks are natural; consensus emerges organically as miners extend the longest chain.

Ethereum PoW (2015-2022)

Smart contract platform on Proof of Work. Similar to Bitcoin but with faster blocks and EVM execution.

Ethash (PoW)

LONGEST CHAIN (NAKAMOTO CONSENSUS)

Blocks every ~13 seconds (vs Bitcoin's 10 minutes)

How It Worked

Ethash PoW: memory-hard algorithm resistant to ASICs. Miners competed to find valid blocks. Longest chain wins, just like Bitcoin. Uncle blocks (near-misses) partially rewarded to reduce waste.

Performance

~15 tps. Blocks every ~13 seconds. Probabilistic finality (~25 blocks for safety). Gas limit adjusts dynamically based on network demand.

Why it was replaced: High energy consumption (~100 TWh/year at peak), limited throughput, and slow probabilistic finality. The Merge (Sept 2022) switched to Proof of Stake for 99% energy reduction and deterministic finality.

Solana (2020)

High-performance L1. Consensus tightly coupled with execution.

Tower BFT + Proof of History

PROOF OF HISTORY: HASH CHAIN = CRYPTOGRAPHIC CLOCK
Problem: No Global Clock
Distributed systems have no shared time. How do we agree on transaction order?
Solution: Verifiable Sequential Hashing
Each validator runs: hash(hash(hash(...))) continuously. Sequential work = provable passage of time.
H#1000
H#1001
H#1002
...
Anyone can verify: "This hash proves work happened between timestamps."
Leaders Insert Transactions
Current leader mixes txs INTO the hash chain:
H#1000
TxA
H#1001
TxB
Order is cryptographically locked. Can't reorder without breaking chain!
Leader Slots
Leader offline
Leader offline
Invalid
PoH (always)

Critical: Each validator runs their own PoH generator. When you're the leader, you reference your local PoH to timestamp transactions. Others verify your PoH proofs (hashing is deterministic). Leaders can go offline (gaps in top row), but every validator's PoH keeps running (bottom row continuous). This decoupling enables fault tolerance.

  • Ordering: Proof of History hash chain runs continuously. Leaders insert transactions into the chain. Order is cryptographically locked—no coordination needed.
  • Participation: Staked SOL. Leader schedule pre-computed (deterministic); leaders rotate every ~4 slots (~400ms). No elections, no delays.
  • Finality: Optimistic confirmation in ~1s. Once 2/3 of stake votes on a fork, reorgs become economically impossible (slashing risk).
  • Throughput: ~3,000 tps in practice (65K theoretical). Single global state machine. Parallel transaction execution when accounts don't conflict.
  • Security: Tower BFT fork choice. Validators vote with exponentially increasing lockouts (longer commitment = harder to revert). Slashing for equivocation.

Key innovation: PoH separates time-keeping from consensus. Validators only vote on "which fork?" not "what order?" (already proven by hash chain). This enables massive throughput. Trade-off: monolithic architecture, sequential dependency on hash chain generator, harder to verify independently without replaying history.

Avalanche (2020)

Novel consensus family. Repeated subsampling instead of leader election.

Snowman Consensus

METASTABLE CONVERGENCE: NETWORK FLIPS UNTIL STABLE
Round 1
50/50 split
Round 2
Flipped to B
Flipped to B
55% → B
Round 3
Flipped
Flipped
85% → B
Round 4
100% → ✓
Confidence Counter: β consecutive rounds
1
2
3
4
5
4/5 → need 1 more for finality

How it works: Query k=20 random peers. If α (e.g. 14/20 = 70%) prefer B, adopt B. Repeat. Network cascades toward majority preference (metastable). After β consecutive successful rounds (β=20 typical), finalize. Byzantine validators can't coordinate—random sampling prevents collusion.

  • Ordering: DAG-based. Validators query random k peers (k=20 typical), adopt majority preference, repeat.
  • Participation: Staked AVAX. All validators participate simultaneously (no leader). Subnets allow custom validator sets.
  • Finality: Probabilistic. β consecutive successful samples (β=20 typical) = finalized. ~1-2s in practice.
  • Throughput: ~4,500 tps on C-Chain (EVM). X-Chain (DAG) and P-Chain (Platform) use different consensus variants.
  • Security: Byzantine fault tolerant. Requires honest majority (>50%). Metastable: validators flip preferences until network stabilizes.

Novel approach: no global broadcast or leader election. Each validator independently samples peers; network converges probabilistically. Extremely fast, scalable, but requires tuning (k, α quorum threshold, β confidence). Subnets enable application-specific chains with shared security.

Ethereum PoS (2020)

Proof of Stake with committee-based block production and deterministic finality.

Gasper (PoS)

EPOCHS × SLOTS (32 SLOTS/EPOCH, 12s/SLOT = ~6.4 MIN/EPOCH)
Epoch N-1
Missed slot
✓ FINALIZED
Epoch N
Fork (orphaned)
⚡ Slashing
← justified (2/3)
Epoch N+1
← building
Epoch N+2
← future
Normal
Missed (~1%)
Fork (~1%)
Slashing (~0.01%)

Key insight: Checkpoint = epoch boundary. Finalized when next epoch is justified (2 epochs ≈ 12.8 min). System handles failures gracefully—missed slots and forks don't stop progress. LMD-GHOST resolves conflicts. Slashing (rare) punishes malicious behavior.

How Blocks Get Produced

Validators are randomly selected as block proposers each slot (every 12 seconds). Committee-based: no single leader, everyone takes turns. 32 slots = 1 epoch (~6.4 minutes).

Who Can Validate

Anyone with 32 staked ETH. Currently ~1 million validators. Economic security: validators who misbehave (double-voting, going offline) lose their stake via slashing.

How Finality Works (Two Phases)

Phase 1 - Fork Choice (LMD-GHOST): When multiple blocks compete for the same slot, validators follow the chain with the most recent attestations weighted by stake. This is "Latest Message Driven - Greedy Heaviest Observed SubTree"—basically, pick the fork that the most stake recently voted for.

Phase 2 - Finalization (Casper FFG): Every epoch, validators vote on checkpoints (epoch boundaries). When a checkpoint gets 2/3 votes, it becomes "justified". When the next checkpoint is justified, the previous one becomes "finalized" (irreversible). Takes ~2 epochs (~12.8 minutes).

Throughput & Security

~15 transactions per second on L1. EIP-4844 adds "blob space" for L2 rollups—data availability without execution overhead. Byzantine fault tolerant: system remains secure even if up to 1/3 of validators are malicious or offline.

The trade-off: Staking 32 ETH and running validator infrastructure is more complex than Bitcoin's "anyone can mine". But you get deterministic finality (no probabilistic reorgs), 99% lower energy use, and much faster confirmation times.

EigenLayer (2023)

Restaking infrastructure. Application-specific validation on Ethereum security.

Restaked Security

RESTAKING: REUSE ETH STAKE, MULTIPLY SLASHING RISK
1. ETH Validators Stake on Beacon Chain
V1
32Ξ
V2
32Ξ
V3
32Ξ
V4
32Ξ
V5
32Ξ
Standard Ethereum staking. Validators lock 32 ETH, earn rewards, face slashing for misbehavior.
2. Validators Opt Into AVS (Restake Same 32 ETH)
Oracle AVS
V1, V2, V4
96Ξ security
Bridge AVS
V2, V3, V5
96Ξ security
Rollup AVS
V1, V3, V4, V5
128Ξ security
V2 opted into 2 AVS. Their 32 ETH secures both (capital efficiency!). But also 2× slashing risk.
3. AVS Executes, Posts Proofs to Ethereum
Each AVS runs custom consensus offchain. Validators sign attestations. Results posted to Ethereum contracts.
Oracle posts price
+
Bridge posts proof
+
Rollup posts state
ETH L1
⚠️ The Risk: Cascading Slashing
V2 misbehaves on Bridge AVS → slashed on Ethereum. Loses 32 ETH stake. Now Oracle AVS also loses V2's security!
V2 slashed (-32Ξ)
Oracle: 96Ξ → 64Ξ
Bridge: 96Ξ → 64Ξ

Key insight: Restaking multiplies capital efficiency (1 stake → N services) but also multiplies risk (1 slash → affects all opted-in AVS). Each AVS must trust validators won't get slashed elsewhere. Trade-off: lower barrier to launch services vs coordination complexity and correlated slashing risk.

  • Ordering: AVS-defined. Each AVS implements custom consensus logic. Validators opt-in per AVS.
  • Participation: Restaked ETH. Validators reuse staked ETH across multiple AVS duties. Increases capital efficiency.
  • Finality: AVS posts proofs/attestations to Ethereum. Ethereum contracts verify and enforce slashing conditions.
  • Throughput: Application-dependent. AVS runs offchain; Ethereum handles settlement, not execution.
  • Security: Shared ETH security. Validators face slashing risk across all opted-in AVS. Economic security scales with ETH stake.

Middleware for shared security: applications build custom validation logic (AVS) without bootstrapping validator sets or launching L1s. Validators earn fees across multiple AVS. Ethereum enforces slashing via smart contracts. Trade-off: complexity of coordinating multiple AVS, potential for cascading slashing risks, but vastly lowers barrier to deploying decentralized services.