Questions: Byzantine Fault Tolerance and Practical BFT

Question 1

A distributed system has 10 nodes. What is the maximum number of Byzantine failures it can tolerate while still achieving consensus?

• A. 4 — because 10 > 3×4 = 12 is false, but 10 > 3×3 = 9 is true
• B. 5 — a simple majority of 10 nodes means half can be faulty
• C. 3 — because n > 3f requires f < 10/3 ≈ 3.33, so f ≤ 3
• D. 2 — because safety requires at least 3× the faults to be honest nodes

Answer: (C)

The bound n > 3f means f < n/3. With n = 10, f < 3.33, so the maximum is f = 3. With f = 3, n = 10 > 3×3 = 9. Option B reflects the crash fault tolerance threshold (n > 2f), not BFT. Option A confuses the direction of the inequality. The one-third bound is a proven lower bound — it is not a design choice but a mathematical consequence of the Byzantine Generals Problem.

Question 2

An engineering team is building an internal distributed database for a company's own servers. Some nodes occasionally crash. Which fault tolerance model is most appropriate, and why?

• A. Byzantine fault tolerance — because any production system should use the strongest possible guarantees
• B. Crash fault tolerance (e.g., Raft or Paxos) — because the nodes are trusted and only crash failures are expected
• C. Byzantine fault tolerance — because crashed nodes can send conflicting messages before stopping
• D. No fault tolerance is needed — internal servers can be considered reliable

Answer: (B)

BFT is necessary when nodes may be actively malicious or send different messages to different peers — scenarios that arise when nodes are controlled by different, potentially adversarial parties (e.g., blockchain networks). In an internal corporate system, nodes are trusted and only crash failures (stop-and-stay-down) are expected. Crash fault tolerance (Raft, Paxos) handles this at O(n) message complexity, whereas BFT costs O(n²) per round. Choosing BFT for an internal system would impose massive overhead without providing real benefit.

Question 3

A node that crashes and stops responding is an example of a Byzantine failure.

• T. True
• F. False

Answer: False

A node that crashes and stops responding is a crash failure — the simplest and most benign failure mode. Byzantine failures are qualitatively different: a Byzantine node can continue operating but behave arbitrarily, sending different messages to different peers, lying about its state, or actively trying to undermine consensus. The key distinction is that crash failures simply remove a node from participation, while Byzantine failures add a potentially deceptive participant. This is why BFT requires a stricter threshold (n > 3f) than crash fault tolerance (n > 2f).

Question 4

A system with 4 nodes using PBFT can tolerate 1 Byzantine failure, because 4 > 3×1.

• T. True
• F. False

Answer: True

With n = 4 and f = 1, n > 3f gives 4 > 3, which is satisfied. This is the smallest possible BFT system — one Byzantine failure tolerated with the minimum viable node count. In PBFT, consensus requires 2f + 1 = 3 matching prepare and commit messages, and the client waits for f + 1 = 2 matching replies. With 4 nodes, 1 can be Byzantine without preventing the 3 honest nodes from reaching agreement.

Question 5

Why does tolerating Byzantine failures require more than two-thirds of nodes to be honest, while crash fault tolerance only requires a simple majority?

Model answer: A Byzantine node can actively deceive by sending 'attack' to some nodes and 'retreat' to others, creating confusion rather than simply disappearing. To outvote conflicting messages, honest nodes need enough of a majority that even after removing the f potentially faulty nodes' votes AND accounting for f conflicting messages injected by Byzantine nodes, a clear honest majority still remains. With n = 3f, the math doesn't work — honest nodes cannot distinguish a Byzantine node from an honest node that received different information. At n = 3f + 1, the honest supermajority is just sufficient to unmask the deception. Crash failures, in contrast, simply remove nodes, so only a simple majority of remaining nodes is needed.

The intuition is that Byzantine failures add noise rather than subtract participants. The 2/3 honest threshold is a proven impossibility result — no BFT protocol can tolerate f Byzantine failures with fewer than 3f + 1 total nodes, regardless of how clever the protocol design is.