Theory of Faults Slides Theory of Faults
Distributed Systems Theory: CAP & Byzantine Faults
Learning Objectives
Formalize the constraints of the CAP Theorem in distributed database design.
Model the Byzantine Generals Problem and identify the \(n > 3f\) threshold for BFT.
Analyze the impact of network synchrony on consensus safety and liveness.
The Core Paradox
"How can a collection of independent entities reach a singular truth when communication is unreliable and some entities are actively lying?"
Part I: The CAP Theorem (Brewer's Theorem)
In a distributed data store, it is impossible to simultaneously provide more than two out of the following three guarantees:
Consistency (C)
Every read receives the most recent write or an error.
Availability (A)
Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
Partition Tolerance (P)
The system continues to operate despite an arbitrary number of messages being dropped by the network.
Theoretical Frontier: FLP Impossibility
The Fischer-Lynch-Paterson (FLP) result proves that in an asynchronous network where even a single process can fail, it is impossible to reach consensus deterministically. How do blockchains bypass this? (Hint: Timing assumptions and partial synchrony).
The Byzantine Generals Problem
Problem Definition
Coordinating an attack on a city. Multiple generals must agree on a time. Some are traitors. Traitors will send different messages to different generals to prevent consensus.
The Fault Threshold
To reach consensus in a system with \(f\) Byzantine (malicious) nodes, we need at least \(3f + 1\) total nodes.
Total Nodes (n) > 3 * Faulty Nodes (f)
Types of Faults
Fail-Stop / Crash
Node simply stops working or responding.
Byzantine
Node acts arbitrarily, lies, or colludes maliciously.
Visual Logic
G1
G2
T1
Scenario: Traitor T1 sends "ATTACK" to G1 and "RETREAT" to G2. Without a third honest node to break the tie, consensus is impossible.
Seminar Question
Why does Bitcoin (Nakamoto Consensus) seemingly operate with 51% honest nodes instead of the \(3f+1\) (roughly 67%) requirement found in traditional BFT? Discussion: Economic vs. Algorithmic security models.
Fault Simulation Guide Consensus Simulation Facilitator Guide
Lesson 1: Theory of Faults | Byzantine Generals Simulation
Instructional Overview
This simulation models the Byzantine Generals Problem . Students will act as network nodes (Generals) attempting to reach a common decision (Attack/Retreat) despite the presence of malicious nodes (Traitors) and network partitions (Simulated delays).
Duration 45 Minutes
Group Size 4-7 per group
Focus Byzantine Faults
Phase 1: Honest Consensus (The Baseline)
In this round, all nodes are honest but communication is restricted.
Setup: One student is the "Commander," others are "Lieutenants."
Goal: All honest Lieutenants must agree on the same action (Attack/Retreat) as the Commander.
Constraint: Lieutenants can only communicate with each other via written notes passed through a central "buffer" (the teacher).
Teacher Action: Randomly drop 20% of the notes to simulate Network Partition (P in CAP) .
Phase 2: The Byzantine Traitor
Goal: Demonstrate that consensus fails if \(n \leq 3f\).
Scenario A (\(n=3, f=1\))
Assign 1 Traitor. The Commander sends "Attack" to one Lieutenant and "Retreat" to the other. The Traitor Lieutenant will lie to the honest Lieutenant about what they heard.
Observation: The honest node cannot distinguish the honest commander from the traitor lieutenant.
Scenario B (\(n=4, f=1\))
Assign 1 Traitor. Use the Oral Messages (OM) algorithm. Nodes must send their received message to everyone else.
Observation: With 4 nodes, the majority rule (3 vs 1) allows consensus to hold.
Facilitation & Debrief Prompts
1
"When the network dropped your messages, did you prioritize Consistency (everyone same) or Availability (getting an answer fast)?"
2
"As an honest node, how did you verify the source of the truth when two peers gave you conflicting information?"
Distributed Constraints Worksheet Distributed Constraints Analysis
Graduate Seminar: Consensus Mechanisms | Lesson 1
Name: ____________________________
Date: _____________________________
I. The CAP Trade-off
Analyze the following real-world blockchain scenarios. For each, identify which two properties (C, A, or P) are being prioritized and describe the specific system behavior during a network partition.
Scenario A: The High-Frequency Trading Chain
A private consortium chain requires absolute finality. If a network partition occurs, the side with fewer than 67% of validators stops accepting new blocks to prevent double-spending.
Guarantees Prioritized:
User Experience during Partition:
Scenario B: The Global Public Ledger
A public PoW blockchain allows miners to continue producing blocks even if they are cut off from the main network. This results in temporary forks that are eventually resolved using the "longest chain" rule.
Guarantees Prioritized:
User Experience during Partition:
II. Byzantine Thresholds
Recall the requirement \(n > 3f\) for Byzantine Fault Tolerance in a partially synchronous network.
"If we have a network of 10 nodes, what is the maximum number of Byzantine (malicious) nodes the network can tolerate while still reaching consensus?"
Show your work and explain the logic:
III. Synthesis Question
In the classroom simulation, we observed that "consistency" was often sacrificed for "availability" when the teacher (the network) dropped messages. In a financial system, why is this trade-off particularly dangerous? Refer to the **double-spending problem** in your answer.
Nakamoto Consensus Slides Lesson 2
Nakamoto Consensus Deep Dive
Probabilistic Finality and the Game Theory of Mining
Difficulty Adjustment
The algorithmic thermostat of the network.
Longest Chain Rule
Resolving forks through cumulative work.
Attack Vectors
Selfish mining and the 51% threshold.
01 The Poisson Process of Block Production
The Winning Condition
SHA256(BlockHeader + Nonce) < Target
The target is a 256-bit number; as difficulty increases, the target decreases.
Finding a block is a Bernoulli trial with a very low probability of success. In aggregate across the network, this follows a Poisson Distribution .
Technical Insight
Block times follow an exponential distribution. Even if the average is 10 minutes, the probability of a block being found in the next minute is exactly the same as if it had been 20 minutes since the last block (Memoryless property).
Difficulty Adjustment Algorithm
T
Expected Time: 2016 blocks * 10 mins = 2 weeks
A
Actual Time: Recorded by timestamps of the 2016 blocks.
N
New Target = Old Target * (Actual Time / Expected Time)
02 Security Limits & Attack Surface
The 51% Attack
An attacker with more than 50% of the network hashrate can:
Re-organize the chain (double-spend)
Censor transactions by not including them
Cannot steal funds from wallets (requires private keys)
Selfish Mining
Introduced by Eyal & Sirer (2014). An attacker keeps their found blocks private to gain a relative advantage.
Threshold for Profitability:
q > 25% to 33%
Depending on network connectivity (\(\gamma\))
"The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes."
— Satoshi Nakamoto, 2008
Hashrate & Attack Probability Set Mining & Attack Probability
Graduate Problem Set: Quantitative Analysis of Nakamoto Consensus
CS-642: DISTRIBUTED LEDGER TECH
SECTION: 02-B
Name: __________________________
Date: ___________________________
Q1
The Target & Difficulty
The network has just finished an adjustment epoch (2,016 blocks). The target for the previous period was \(T_{old} = 0x000000000000000005ABCD00...00\). The actual time taken to mine these 2,016 blocks was **11.4 days**.
A) Calculate the new target (\(T_{new}\)) relative to the old target. (Standard epoch length: 14 days)
B) Did the hashrate increase or decrease during this epoch? Explain how the algorithm responds to maintain the 10-minute average.
Q2
The Gambler's Ruin
Satoshi modeled the probability of an attacker catching up to the honest chain as a Random Walk. Let \(p\) be the probability an honest node finds the next block, and \(q\) be the probability an attacker finds it.
\[P = \begin{cases} 1 & \text{if } q \ge p \\ (q/p)^z & \text{if } q < p \end{cases}\]
Formula for the probability an attacker can catch up from \(z\) blocks behind.
A) If an attacker controls 20% of the hashrate (\(q=0.2, p=0.8\)), what is the probability they can successfully double-spend if a merchant requires 2 confirmations (\(z=2\))?
B) Calculate the same probability for \(z=6\) confirmations. Why is "6 confirmations" the standard recommendation for high-value transactions?
Q3
Incentive Compatibility
Explain the concept of **Selfish Mining**. How does a private fork help an attacker gain a larger share of rewards than their proportional hashrate should allow?
Hashrate & Attack Probability Key Answer Key & Solutions
Lesson 2: Nakamoto Consensus Deep Dive
Instructor Only
01 Difficulty Adjustment Solution
A) Target Calculation
T_new = T_old * (Actual Time / Expected Time)
T_new = T_old * (11.4 days / 14 days) ≈ T_old * 0.814
The target is multiplied by roughly 0.814, making it smaller . A smaller target makes finding a valid hash harder .
B) Reasoning
The hashrate increased . Because blocks were found faster than 10 minutes (average ~8.1 mins), the network compensates by increasing difficulty to bring the block time back up to the 10-minute target for the next epoch.
02 Attack Probability (Gambler's Ruin)
A) z=2 Case
P = (q/p)^z = (0.2 / 0.8)^2 = (0.25)^2 = 0.0625 or 6.25%
B) z=6 Case
P = (0.25)^6 ≈ 0.000244 or 0.024%
At \(z=6\), the probability of a successful attack by a 20% hashrate entity becomes negligible. This is why 6 confirmations is the "standard" for high confidence in finality. Note that if \(q > 0.5\), the probability is 1 (certainty).
03 Selfish Mining Mechanics
Selfish mining involves a miner finding a block and not broadcasting it. They continue mining on top of their private block. If they find a second private block, they have a "lead." When the honest network eventually finds a block, the selfish miner broadcasts their private chain, which is longer. The honest network's work is "orphaned" (discarded). This forces honest miners to waste hashrate on a chain destined for deletion, effectively increasing the relative reward share of the attacker.
Proof of Stake Slides Lesson 3
Capital Based Security
Proof of Stake, Economic Finality, and Slashing Conditions
The Pivot
Replacing physical infrastructure (ASICs/Electricity) with digital assets (Staked Capital) to secure the state-machine.
Core Mechanisms
Validator Selection (Probabilistic by weight)
Slashing (Economic punishment for equivocation)
Economic Finality (Un-revertible blocks)
X The "Nothing at Stake" Dilemma
In PoW, mining on two forks simultaneously splits your physical hashrate (and doubles your electricity cost). In PoS, signing two forks is computationally trivial.
The Vulnerability
Validators are incentivized to vote on every fork to ensure they receive rewards regardless of which chain wins. This prevents the network from ever reaching consensus.
The Solution: Slashing
Equivocation Check
Validators must not sign two different blocks at the same height/epoch.
Slashable Offense
If evidence of dual-signing is provided, a portion (or all) of the validator's stake is burned.
function verify_attestation(v1, v2) {
if (v1.height == v2.height && v1.hash != v2.hash) {
trigger_slashing(v1.proposer);
}
}
Economic Finality
Casper FFG
The "Friendly Finality Gadget" layers on top of a fork-choice rule to finalize checkpoints every 32 slots (an epoch).
The 2/3 Rule
A block is "justified" when 2/3 of the staked weight votes for it. It is "finalized" when its successor is also justified.
Cost of Reversal
To revert a finalized block, at least 1/3 of the total stake must be burned. This provides a measurable dollar-cost of attack.
The Deterministic Guarantee
Unlike PoW, where finality is always probabilistic (\(P \to 0\) over time), PoS can provide Deterministic Finality . Once a block is finalized, it can never be changed unless the network is fundamentally broken and massive capital is destroyed.
Cost of Corruption Analysis Cost of Corruption Analysis
Graduate Seminar: Consensus Mechanisms | Lesson 3
Student ID: ____________________
Date: _________________________
I. Defining the Metric
The **Cost of Corruption (CoC)** is the economic expenditure required for an attacker to successfully manipulate the consensus mechanism (e.g., execute a double-spend).
PoW Model
CoC is dominated by the acquisition of hashrate (CAPEX) and ongoing electricity (OPEX).
CoC ≈ 0.51 * (Network Hashrate) * (Cost per GH/s)
PoS Model
CoC is dominated by the acquisition and loss of staked capital (Opportunity Cost + Slashing).
CoC ≈ 0.33 * (Total Staked Capital)
II. Comparative Scenario
Consider two hypothetical networks, both with a market capitalization of **$10 Billion**.
Network A (PoW)
Annual security spend (rewards): 5% of market cap ($500M).
Network B (PoS)
Total capital staked: 40% of market cap ($4B).
1. In Network B (PoS), calculate the approximate dollar cost an attacker would lose (slashed) if they attempted to revert a finalized block. (Assume 1/3 threshold).
2. In Network A (PoW), why is it significantly more difficult to calculate a "one-time" cost for a permanent attack compared to the PoS model? Consider the role of hardware recovery.
III. The "Nothing at Stake" Mitigation
Review the following proposed mechanism: "A validator who proposes a block must include the hash of the block they believe is the current head. If they ever propose a block at the same height on a different branch, any other node can submit these two signed blocks as proof to burn the validator's stake."
Does this mechanism fully solve the "Nothing at Stake" problem? What about "Long-range Attacks" (where an attacker uses old private keys to build a separate chain from the genesis)?
Alternative Consensus Slides Lesson 4
Beyond The Chain
DAGs, Federated Consensus, and High-Throughput Architectures
DAGs
Removing the bottleneck of sequential block production.
FBA
Flexible trust and quorum slices for federated networks.
Liveness vs Safety
The fundamental trade-off in classical vs Nakamoto BFT.
DAG-Based Consensus
Conceptual Shift
"In a blockchain, a block references one parent. In a DAG, a vertex can reference multiple parents."
Key Advantages:
Asynchronous: No need for global clock or slot timing.
Parallelism: Multiple transactions can be processed concurrently.
Zero Fees? Often designed to allow users to act as validators (e.g., IOTA Tangle).
Vertices reference multiple previous vertices, forming a 'mesh' rather than a chain.
TANGLE
Federated Byzantine Agreement
How it works (Stellar/Ripple)
Instead of a global validator set, each node chooses a Quorum Slice : a set of nodes it trusts.
Decentralized Control: Anyone can join.
Low Latency: Consensus reached in seconds.
Flexible Trust: No central authority dictates who to trust.
The "Quorum Intersection" Requirement
For the network to reach global consensus, the chosen slices must overlap enough that they form a Quorum . If slices don't intersect, the network can fork into disjoint "islands" of truth.
Safety: Dependent on Quorum Intersection
Liveness: Dependent on Quorum Availability
Trade-off Focus
Traditional BFT (and FBA) favors Safety over Liveness . If the network cannot reach a quorum, it stops (Availability loss) rather than forking (Consistency gain).
SAFETY FIRST
Consensus Architecture Matrix Consensus Architecture Matrix
Graduate Analysis Tool: Comparing Distributed Architectures
CS-642: DISTRIBUTED LEDGER TECH
Objective: Evaluate the trade-offs in scalability, security, and decentralization across primary consensus families. Complete the blank sections of the matrix based on lecture materials and research.
Consensus Family Example Protocol Primary Bottleneck Finality Type Safety/Liveness Nakamoto (PoW) Bitcoin Sequential block propagation; latency bound by network diameter. Probabilistic (P → 1 over time) Favors Liveness (Dynamic Availability) Casper (PoS) Ethereum 2.0 Classical BFT (pBFT) Hyperledger Fabric Communication complexity (O(n²)) for message passing. Deterministic (Instant Finality) Favors Safety (Halt on failure) DAG / Tangle IOTA, Fantom FBA (Federated) Stellar, Ripple
Application: Select the Model
Read the use case requirements and justify which consensus architecture you would select.
Use Case: Global Micro-payments for IoT Devices
Requirements: 100,000+ transactions per second, zero or near-zero fees, low computational overhead for sensors/mobile devices, and no need for absolute instant finality (probabilistic is fine within 60 seconds).
Recommended Architecture:
Justification (Reference the matrix):
Fork Choice Slides Lesson 5
Resolving Network Forks
GHOST, LMD-GHOST, and the Search for Canonical Truth
The Fork Choice Rule
The algorithm a node uses to determine which version of the chain history is "canonical" when multiple valid competing chains exist.
Key Protocols
Longest Chain (Nakamoto)
GHOST (Heaviest Observed Subtree)
LMD-GHOST (Latest Message Driven)
The Problem with Longest Chain
In high-throughput networks (low block times), the "Longest Chain" rule is vulnerable because of high stale rates . Honest blocks that are found nearly simultaneously are "orphaned," reducing the security of the chain.
GHOST Solution
G reedy H eaviest O bserved S ub-T ree.
Instead of just counting the length of the path, we count all blocks in the subtree of a given block, including those that were orphaned. This ensures that even "wasted" work contributes to the security of the main chain.
Visualizing the Weight
BLOCK A (4)
BLOCK B (2)
Uncle Block
Weights are cumulative totals of all descendant blocks.
LMD-GHOST in Ethereum
Latest Message Driven
In Ethereum's PoS, weights aren't determined by PoW hashes, but by Validator Attestations .
Rule: At each fork, follow the branch that has the most total weight from the latest messages sent by validators.
Why it matters: Reorgs
A "Reorg" (Re-organization) occurs when a node receives new information that makes a different fork the canonical one.
Impacts of Deep Reorgs:
Exchanges lose money (Double spend)
User transactions disappear from history
Network instability and latency increase
Seminar Discussion
How does the Gasper protocol (LMD-GHOST + Casper FFG) handle the trade-off between "quick" probabilistic finality and "slow" economic finality?
Chain Reorg Workshop Chain Reorg Workshop
Lesson 5: Fork Choice Logic & Canonical Selection
Name: ____________________________
Score: ________ / 20
Instructions:
Below are three network states. For each, you must determine which block is considered the head of the chain according to two different rules: Longest Chain (Nakamoto) and GHOST (Greedy Heaviest Observed Subtree).
1 Scenario A: The Deep Fork
G
B1
B2a
B3a
B2b
B3b
B4b
Note: Branch 'a' has higher latency but is geographically closer to the major miner pool. Branch 'b' is longer but has fewer 'uncles'.
Rule: Longest Chain
Winning Block: _______________
Rule: GHOST
Winning Block: _______________
2 Scenario B: The Attestation Weight (LMD-GHOST)
In a PoS system, Block A has 10 attestations, Block B has 8 attestations, but Block B has 3 child blocks, while Block A has 1 child block. (Assume each attestation has weight = 1).
Which block would LMD-GHOST select as the root of the heavier subtree? Explain your calculation of the subtree weight.
Critical Thinking
1. Define a "Reorg" in your own words. Why is a deep reorg (e.g., 10+ blocks) considered a security failure in most blockchain networks?
2. If an exchange requires 12 confirmations for a Bitcoin deposit, but only 32 slots for an Ethereum deposit, what does this tell you about the relative "time to finality" and the underlying consensus logic?
Consensus Synthesis Exam Consensus Systems Final Examination
Graduate Course: Distributed Ledger Technology & Mechanism Design
Student Name: __________________________
ID Number: _____________________________
Instructions
This exam consists of technical analysis questions and system design prompts. Provide rigorous mathematical or logical justifications for all answers. You may refer to the CAP theorem, the Byzantine Generals Problem threshold, and specific consensus protocols (PoW, PoS, DAG, FBA) studied in the sequence.
Part I: Theoretical Foundations
1. [5 pts] Prove why \(n > 3f\) is the lower bound for reaching consensus in a system with \(f\) Byzantine faults. Specifically, explain the "Sybil-like" behavior of a traitor in a 3-node system (\(n=3, f=1\)).
2. [5 pts] Explain the difference between **Safety** and **Liveness**. Which property does Nakamoto Consensus (PoW) prioritize during a network partition, and what is the specific consequence of this choice for "Consistency"?
Part II: Mechanism Analysis
3. [5 pts] In a Proof of Stake system, define the **"Nothing at Stake"** problem and describe how **Slashing Conditions** act as a game-theoretic deterrent. Why is slashing not possible in a pure Proof of Work system?
Case Study Challenge
A new protocol "FastChain" claims to achieve 50,000 TPS with 1-second deterministic finality and 51% Byzantine fault tolerance on a globally distributed network of 1,000 nodes using a modified BFT voting mechanism.
Critique this claim. Refer to the **trilemma of scalability, security, and decentralization**, as well as the communication complexity of classical BFT algorithms (O(n²)).
End of Examination | Distributed Consensus Mechanisms Sequence