Learn the vocabulary of reaching correct consensus even when some nodes behave arbitrarily or maliciously.
0 / 5 completed
1 / 5
A teammate explains that a distributed consensus protocol must keep producing correct agreement even if some nodes send conflicting, contradictory messages to different peers, not just crash silently. What property is being described?
Byzantine fault tolerance is exactly this: it lets a distributed system reach correct agreement even when some nodes behave arbitrarily or maliciously, including sending different, contradictory messages to different peers, rather than only handling nodes that crash or go silent. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This tolerate-arbitrary-behavior guarantee is exactly why Byzantine fault tolerance is required for systems that cannot fully trust every participant, such as public blockchains.
2 / 5
During a design review, the team adopts a Byzantine fault tolerant protocol for a permissioned blockchain, specifically because it can still reach consensus even if up to a bounded fraction of nodes are compromised and lie about the ledger's state. Which capability does this provide?
This provides consensus correctness despite a bounded number of arbitrarily malicious nodes, since the protocol tolerates lying or contradictory participants up to a known threshold, typically fewer than one-third of all nodes. A crash-fault-tolerant protocol that only assumes nodes stop responding cannot handle nodes that actively lie or send conflicting votes to different peers. This tolerate-malicious-behavior guarantee is exactly why Byzantine fault tolerance is chosen for systems where participants cannot be fully trusted.
3 / 5
In a code review, a dev notices a consensus implementation assumes every node either responds correctly or stops responding entirely, with no handling for a node that sends different values to different peers. What does this represent?
This is a missed Byzantine-fault-tolerance requirement, since a node sending different values to different peers is exactly the arbitrary behavior a crash-only assumption fails to handle. A cache eviction policy is an unrelated concept about discarded cache entries. This crash-only-assumption gap is exactly the kind of oversight a reviewer flags once the system must tolerate participants that may actively misbehave rather than merely go silent.
4 / 5
An incident report shows a consensus cluster produced two conflicting committed values after a compromised node sent contradictory votes to different peers, because the protocol only tolerated crash failures. What practice would prevent this?
Adopting a Byzantine fault tolerant consensus protocol ensures contradictory votes from a bounded number of malicious nodes cannot produce conflicting committed values, since the protocol requires a supermajority of matching votes before committing. Continuing to run a crash-fault-tolerant protocol regardless of how many nodes might send contradictory votes to different peers is exactly what caused the conflicting commits described in this incident. This supermajority-agreement approach is the standard fix once nodes are confirmed to be capable of sending contradictory votes.
5 / 5
During a PR review, a teammate asks why the team reaches for Byzantine fault tolerant consensus instead of a simpler crash-fault-tolerant protocol like Raft, given that Raft is easier to reason about and cheaper to run. What is the reasoning?
Byzantine fault tolerant consensus trades extra message rounds and a higher required node count for correctness even against actively malicious nodes, while Raft is simpler and cheaper but assumes nodes only crash rather than lie. This is exactly why Byzantine fault tolerance is favored for systems with untrusted or adversarial participants, such as public blockchains, while Raft's crash-only assumption remains acceptable inside a single trusted, permissioned cluster.