Consensus Mechanisms Explained
Learning Objectives
Explain why consensus is necessary in distributed systems
Compare major consensus mechanism categories and their trade-offs
Identify which consensus approaches are suitable for CBDCs
Analyze real CBDC consensus choices
Evaluate the relationship between consensus and performance
Imagine three people each keeping a copy of a shared bank ledger. Alice sends money to Bob. All three ledger-keepers need to update their records. But what if one keeper gets a different message? What if one is malicious? What if messages arrive in different orders?
This is the consensus problem: how do distributed parties agree on a single truth?
The answer matters enormously. Different consensus mechanisms trade off speed, fault tolerance, security, and energy consumption. Bitcoin's proof-of-work is famously energy-intensive but highly secure against unknown attackers. Bank settlement systems use simple leader-based consensus that's fast but requires trust. CBDCs need mechanisms that balance these concerns appropriately.
THE FUNDAMENTAL PROBLEM
SCENARIO:
Three nodes maintain copies of a ledger.
A transaction arrives: "Alice pays Bob $100"
What could go wrong?
- Node A receives transaction
- Node B receives transaction
- Node C never receives it
- Node A sees: Alice→Bob, then Carol→Dave
- Node B sees: Carol→Dave, then Alice→Bob
- If order matters, different states result
- Node A processes transaction
- Node B crashes mid-process
- Node C rejects transaction
- Node A reports valid transaction
- Node B (malicious) reports fake transaction
- Node C sees conflict
- Which transactions are valid
- In what order they occurred
- What the current state is
WHAT GOOD CONSENSUS PROVIDES
SAFETY PROPERTIES (Nothing bad happens):
AGREEMENT
VALIDITY
LIVENESS PROPERTIES (Good things happen):
TERMINATION
FAIRNESS
TRADE-OFFS:
Can't optimize all properties simultaneously
Different mechanisms prioritize differently
CBDC needs: High safety, good liveness, fast finality
```
CAP THEOREM: FUNDAMENTAL LIMITS
In distributed systems, pick two of three:
CONSISTENCY (C):
All nodes see same data simultaneously
Every read gets most recent write
AVAILABILITY (A):
Every request gets a response
System always operational
PARTITION TOLERANCE (P):
System works despite network failures
Nodes can be temporarily disconnected
THE THEOREM:
Can only guarantee 2 of 3 fully
Must choose what to sacrifice
- Partition tolerance: Required (networks fail)
- Consistency: Critical (money can't be inconsistent)
- Availability: Important (system must work)
TYPICAL CBDC CHOICE:
Prioritize: Consistency + Partition Tolerance
Trade off: Some availability during partitions
"Better to pause than be inconsistent about money"
---
LEADER-BASED CONSENSUS
CONCEPT:
One designated node leads
Proposes blocks/transactions
Others follow or reject
SIMPLE LEADER (Primary-Backup):
┌────────────┐
│ LEADER │───────────────────────┐
│ (Primary) │ │
└─────┬──────┘ │
│ "Record this transaction" │
▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Follower 1 │ │ Follower 2 │ │ Follower 3 │
│ (Backup) │ │ (Backup) │ │ (Backup) │
└─────────────┘ └─────────────┘ └─────────────┘
- Leader receives transactions
- Leader orders and validates
- Leader broadcasts to followers
- Followers record and acknowledge
- Transaction confirmed
ADVANTAGES:
- Very fast (one round of communication)
- Simple to implement
- Low overhead
- Predictable performance
- Single point of failure
- Trust in leader required
- If leader is malicious, system fails
- Leader election needed if leader fails
FOR CBDC:
Works well when central bank is trusted leader
Essentially centralized with backups
Common in centralized CBDC designs
```
BYZANTINE FAULT TOLERANCE
CONCEPT:
System works correctly even if some nodes
are malicious or faulty (Byzantine)
THE BYZANTINE GENERALS PROBLEM:
Generals surrounding a city must agree on attack/retreat
Some generals may be traitors (send conflicting messages)
How do loyal generals reach consensus?
PRACTICAL BFT (pBFT):
┌─────────────┐
│ CLIENT │──Request───────────────────┐
└─────────────┘ │
▼
┌──────────────────────────────────────────┐
│ REPLICA NODES │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ A │ │ B │ │ C │ │ D │ │ X │ │
│ └───┘ └───┘ └───┘ └───┘ └───┘ │
│ ok ok ok ok (faulty) │
│ │
│ Need 2/3 agreement (3f+1 nodes total) │
└──────────────────────────────────────────┘
- Pre-prepare: Leader proposes
- Prepare: Nodes verify and broadcast
- Commit: Nodes commit if enough agree
- Reply: Client gets confirmed response
BFT GUARANTEE:
Works correctly with up to f faulty nodes
if total nodes n ≥ 3f + 1
Example: 4 nodes → tolerates 1 Byzantine failure
7 nodes → tolerates 2 Byzantine failures
ADVANTAGES:
- Tolerates malicious nodes
- Strong safety guarantees
- Fast finality (no probabilistic waiting)
- Suitable for permissioned networks
- Communication overhead (O(n²) messages)
- Doesn't scale well (usually < 100 nodes)
- Known participants required
- Complex implementation
PROOF-BASED CONSENSUS MECHANISMS
PROOF OF WORK (PoW):
Used by: Bitcoin, Ethereum (formerly)
- Nodes compete to solve cryptographic puzzle
- First solver proposes block
- Others verify and accept
- Energy/computation as "voting power"
- Extremely energy intensive
- Slow (Bitcoin: ~7 TPS, 10 min blocks)
- Probabilistic finality (can be reversed)
- Too slow
- Too energy intensive
- Central bank doesn't need permissionless
──────────────────────────────────────────
PROOF OF STAKE (PoS):
Used by: Ethereum (current), Cardano, Solana
- Validators stake currency as collateral
- Selected to propose blocks based on stake
- Bad behavior → lose stake
- Economic incentive for honesty
- Wealth concentration concerns
- Complex implementation
- Who stakes? (Central bank has all anyway)
- Permissioned alternatives simpler
──────────────────────────────────────────
PROOF OF AUTHORITY (PoA):
Known authorities validate (permissioned)
- Known validators (banks, central bank)
- Fast, efficient
- Essentially permissioned BFT variant
CONSENSUS MECHANISM COMPARISON
LEADER BFT PoW PoS
────────────────────────────────────────────────────
PERFORMANCE
Throughput Very High Low Medium
High
Latency <1s 1-5s 10min+ 2-30s
FAULT TOLERANCE
Crash faults Yes Yes Yes Yes
Byzantine No Yes Yes Yes
Required nodes 1+ 3f+1 Many Many
TRUST MODEL
Known nodes Yes Yes No Varies
Trust needed High Medium None Medium
FINALITY
Type Instant Instant Prob. Varies
Time Fastest Fast Slow Medium
FOR CBDC:
✓ Leader-based: Simple, fast, trusted central bank
✓ BFT variants: Multi-party, wholesale, cross-border
✗ PoW: Too slow, wasteful
✓ PoA: Permissioned, fast, practical
```
WHAT CBDC CONSENSUS NEEDS
- High throughput: 10,000+ TPS for retail
- Low latency: Seconds for confirmation
- Scalability: Millions of users
- Settlement finality: No reversals
- No double-spending: Absolute
- Byzantine tolerance: Depends on model
- Deterministic behavior: Predictable
- Audit capability: Full history
- Geographic distribution: Resilience
- Central bank authority: Clear
- Participant management: Controlled
- Policy implementation: Possible
CONSENSUS BY CBDC TYPE
- "Consensus" is trivial—central bank decides
- Leader-based with backups
- Maximum performance
- Trust in central bank required
- Multiple operating parties
- BFT consensus among validators
- Banks may operate nodes
- Central bank retains special authority
TYPICAL CONFIGURATIONS:
Retail (Centralized):
Central bank operates core
Leader-based, high speed
Banks interface at distribution layer
Wholesale (Distributed):
Banks as validators
BFT among participants
Lower volume, shared verification
Cross-border (Distributed):
Multiple central banks
Each operates node
BFT for agreement
```
TRANSACTION FINALITY FOR CBDC
- Transaction confirmed = final
- No possibility of reversal
- BFT and leader-based provide this
- Required for CBDC
- Security increases with time
- Never absolutely certain
- PoW provides this
- Unsuitable for CBDC
- Money requires certainty
- Both parties must know it's final
- No "probably yours" transactions
- Settlement requires finality
IMPLICATION:
PoW unsuitable for CBDC
BFT or leader-based required
```
CBDC CONSENSUS IN PRACTICE
- Centralized core ledger
- Central bank authority
- Leader-based approach
- Distribution banks interface
- Hyperledger Fabric
- PBFT consensus
- Central bank as orderer
- Banks as peers
- Hyperledger Besu
- IBFT 2.0 (BFT variant)
- Permissioned network
- Multi-central-bank
- Custom DLT with BFT
- Each CB operates node
PATTERN:
Retail → Centralized/Leader
Wholesale → BFT
Cross-border → BFT
```
✅ Leader-based delivers highest performance—when trust exists, no need for distributed verification.
✅ BFT works for permissioned multi-party scenarios—wholesale and cross-border CBDCs use it.
✅ PoW is unsuitable for CBDCs—too slow, energy-intensive, probabilistic finality.
⚠️ Optimal BFT configurations—limited operational experience at scale.
⚠️ Hybrid consensus approaches—still emerging.
📌 Choosing consensus based on hype—"blockchain" doesn't mean better.
📌 Underestimating BFT complexity—hard to implement correctly.
For CBDCs, consensus choice follows from trust model and requirements. Centralized retail CBDCs use leader-based for performance. Wholesale and cross-border use BFT for multi-party verification. PoW is irrelevant for CBDCs.
Assignment: Select and justify a consensus mechanism for a CBDC scenario.
Requirements:
Part 1: Choose scenario: Retail (50M users), Wholesale (15 banks), or Cross-border (4 central banks)
Part 2: Evaluate three consensus options for your scenario
Part 3: Recommend mechanism with justification
Time Investment: 3-4 hours
1. What is consensus's primary purpose?
Answer: B - Enable multiple nodes to agree on same truth
2. BFT with 7 nodes tolerates how many Byzantine failures?
Answer: B - 2 nodes (n ≥ 3f+1, so 7 ≥ 3(2)+1)
3. Why is probabilistic finality unsuitable for CBDC?
Answer: B - CBDCs require immediate, deterministic finality
4. Why do retail CBDCs use leader-based consensus?
Answer: B - Maximum performance, central bank already trusted
5. Why use BFT for cross-border CBDC?
Answer: B - Each central bank needs independent verification
End of Lesson 9
Course 58: CBDC Architecture & Design
Lesson 9 of 20
Key Takeaways
Consensus solves the agreement problem
: How distributed nodes agree on truth.
Leader-based is fastest
: When central bank is trusted, simple approaches work best.
BFT for multi-party verification
: When banks need to verify each other.
PoW unsuitable for CBDC
: Too slow, energy-intensive, probabilistic finality.
Finality must be deterministic
: CBDCs require immediate, absolute finality. ---