Why does simple 3-way majority voting not solve Byzantine faults?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Byzantine faults, also known as Byzantine Generals' Problem, refer to a situation where components in a system fail in arbitrary ways, including lying or sending conflicting information to other components. This type of failure is particularly challenging to manage because it can cause system components to exhibit erratic behavior that undermines the reliability and correctness of data communications and decision-making processes.
Understanding Byzantine Faults
To provide a deeper insight into why simple 3-way majority voting does not remedy Byzantine faults, we first need to comprehend what these faults entail. Byzantine faults can occur in any distributed system where components need to agree on a strategy or a value to function correctly, despite some components being unreliable, malicious, or faulty.
Limitations of 3-Way Majority Voting
3-way majority voting is a simple fault-tolerant technique typically used to manage errors in systems by assuming that as long as the majority (two out of three) of components agree on a value or decision, it can be considered correct. This method works under the assumption that faults are minor and not malicious. However, in the context of Byzantine faults, this assumption often fails due to the complex nature of the errors.
Example Scenario
Imagine three generals of an army, located at different posts, who need to agree on a common plan to attack or retreat:
- General A (honest): Sends "attack" to both B and C.
- General B (Byzantine faulty): Sends "retreat" to A and "attack" to C.
- General C (honest): Receives conflicting commands and sends "attack" to both A and B.
In this case, a simple majority vote would not yield a clear, correct decision since the votes would be split, and the presence of a Byzantine fault (from General B) effectively manipulates the outcome.
Why Major Voting Fails in Byzantine Scenarios
- Manipulation of Votes: As shown in the example, a Byzantine fault can manipulate the voting process by sending different values to different parties.
- Split Decisions: Even with an odd number of nodes (e.g., 3), the design does not guarantee a correct or unified decision if one node deliberately causes confusion.
- Lack of Consensus on Faults: Majority voting assumes a consensus on which node might be faulty which is not possible in Byzantine failures without additional protocols.
Enhanced Solutions Beyond Majority Voting
To effectively combat Byzantine faults, systems often need more sophisticated algorithms that involve more nodes and detailed protocols such as:
- Byzantine Fault Tolerance algorithms (BFT): These include practical implementations like PBFT (Practical Byzantine Fault Tolerance), which require a minimum of nodes to tolerate number of Byzantine faults while ensuring consensus even if some nodes are not honest.
- Cryptographic methods: Digital signatures and hashing techniques to ensure message integrity and detect tampered messages.
Summary Table: Comparison of Failures and Mechanisms
| Failure Type | Majority Voting | Byzantine Fault Tolerance |
| Node Failure | Effective | Effective |
| Data Tampering | Ineffective | Effective |
| Malicious Attacks | Ineffective | Effective |
| System Recovery | Moderate | High |
Conclusion
The intricacies of Byzantine faults make simple solutions like 3-way majority voting inadequate, primarily because they are designed to handle straightforward failures rather than complex or malicious behaviors. In systems where security and consensus are critical, particularly in contexts like blockchain technologies or military communications, more robust protocols such as BFT are not just beneficial—they are necessary. Understanding and implementing these advanced solutions provides a stronger defense against the potentially severe consequences of Byzantine faults in distributed systems.
By delving into advanced fault tolerance strategies, organizations can safeguard their operations and ensure data reliability and system integrity even under potential threat scenarios, thereby maintaining performance and trust.
Related reading
- Why exactly isn't MEF a DI/IoC container?
- Why Hazelcast CacheLoader class needs to be visible by all clients?
- Why implement non idempotent operations?
- Why in chord p2p system, the finger table don''t store all the information about the other nodes?
- Why is 2-phase commit not suitable for a microservices architecture?
- Why is at-most-once delivery the default for actor systems?
- Why is Git not considered a block chain?
- Why is IoC / DI not common in Python?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.