The Byzantine Generals Problem and Why Most Systems Don’t Need Byzantine Fault Tolerance
Crash faults and Byzantine faults are not the same problem, and reaching for blockchain-grade guarantees inside a trusted internal network usually solves a problem you don’t have.
Blockchain’s rise put a strange new phrase into everyday engineering conversation: Byzantine fault tolerance. Teams that had never touched a cryptocurrency started asking whether their internal services needed it too, as if it were simply a stronger, more modern flavor of the reliability they already had. It is not. Byzantine fault tolerance solves a specific and much harder problem than the one most backend systems actually face, and understanding the difference will save you from adopting a heavyweight protocol for a threat that was never on your table to begin with.
The Original Problem
The name comes from a 1982 paper by Leslie Lamport, Robert Shostak, and Marshall Pease, who framed distributed agreement as a story about generals surrounding a besieged city. Each general commands part of an army and can only communicate by messenger. They must all agree on the same plan, attack together or retreat together, because a divided army loses. The complication is that some generals might be traitors who send different messages to different peers on purpose, trying to trick the loyal generals into acting on conflicting information.
Lamport, Shostak, and Pease proved something precise about this scenario: reaching agreement in the presence of arbitrarily lying, colluding participants is only possible when the loyal generals outnumber the traitors by more than two to one. In modern terms, a system needs at least 3f + 1 total nodes to correctly tolerate f Byzantine, meaning arbitrarily malicious or corrupted, nodes. That extra math is not a design preference. It is a hard lower bound baked into the problem itself.
Crash Faults Are a Much Smaller Problem
Most production outages look nothing like a lying general. A server runs out of memory and dies. A process hangs. A network partition isolates a rack for ninety seconds. In every one of these cases the failed node simply stops participating correctly, it does not actively construct false messages designed to fool its peers. This is called a crash fault, and it is the failure model that protocols like Paxos and Raft were built around, the same protocols quietly running underneath Google Spanner, etcd, and ZooKeeper.
Because a crashed node cannot lie, tolerating it is mathematically cheaper. A crash-fault-tolerant, or CFT, system only needs 2f + 1 nodes to survive f crashes, rather than the 3f + 1 a Byzantine-fault-tolerant, or BFT, system requires. That difference of just one extra node per fault sounds small until you notice what it is actually paying for underneath.
| Property | Crash Fault Tolerance (Raft, Paxos) | Byzantine Fault Tolerance (PBFT and similar) |
|---|---|---|
| Assumed failure behavior | Node stops or goes silent | Node can lie, forge, or collude |
| Nodes needed to tolerate f faults | 2f + 1 | 3f + 1 |
| Typical message pattern | Leader broadcasts to followers | All-to-all voting across replicas |
| Message complexity per round | Roughly linear in node count | Roughly quadratic in node count |
| Where it is used | Internal databases, config stores, single-organization clusters | Permissioned and public blockchains, multi-organization consortiums |
The Replica Math, Visualized
The 2f + 1 versus 3f + 1 gap is easy to state and easy to underestimate. Here is what it looks like as your fault tolerance target grows.
To tolerate three simultaneous faults, a CFT cluster needs seven nodes. A BFT cluster needs ten, and those extra three nodes are not idle backups, they carry their own compute, storage, and network overhead around the clock, whether or not anyone is actually misbehaving.
The Message Overhead Nobody Mentions
Node count is only half the bill. Raft’s message pattern is simple: a leader sends entries to followers and collects acknowledgements, which scales roughly linearly with the number of nodes. Byzantine protocols like PBFT cannot get away with that, because a Byzantine node might tell the leader one thing and everyone else another. To catch that, replicas broadcast their votes to every other replica during the prepare and commit phases, producing message traffic that grows roughly with the square of the node count.
At ten nodes that gap is manageable. At a hundred nodes it is not, which is exactly why most Byzantine systems, including public blockchains, either cap their active validator set or introduce sharding and rotating committees just to keep the all-to-all chatter under control.
Why Blockchains Actually Need It
None of this means BFT is unnecessary in general, it means it solves a specific kind of trust problem. A public blockchain has no single administrator. Its validators belong to different, mutually distrustful organizations, some of whom may have a financial incentive to cheat, and there is no shared operator who can simply restart a misbehaving node. In that setting, assuming a node might actively lie is not paranoia, it is an accurate description of the environment. The same logic applies to permissioned consortium chains that span competing banks or supply chain partners, and to any system where the parties running the nodes do not fully trust each other.
Why Your Internal Service Probably Does Not
Most backend systems live entirely inside one company’s infrastructure, managed by one operations team, running on hardware that team controls end to end. The realistic failure modes there are crashes, restarts, bad deploys, and network blips, not a rogue employee reprogramming a database replica to lie to its peers on purpose. If that describes your environment, you already have a name for your actual threat model: crash faults. Reaching for a Byzantine-tolerant consensus layer to guard against an adversary who is not in your threat model means paying 3f + 1 replicas and quadratic message overhead to defend against something your internal network security, access controls, and code review process are already handling in a completely different, and usually more effective, layer.
Do you actually need BFT?
- Do the nodes in your consensus group belong to different organizations that do not fully trust each other?
- Could a single compromised or malicious node plausibly forge conflicting messages to different peers, and would your security controls fail to catch it?
- Is there no single operator who can identify and remove a misbehaving node once it is detected?
- Are you willing to pay for extra replicas and quadratic message overhead as the cluster grows?
- If you answered no to most of these, Raft or Paxos-style crash fault tolerance is very likely the right, and far cheaper, fit.
What We Learned
The Byzantine Generals Problem describes a genuinely harder challenge than the one most engineering teams face day to day: reaching agreement when some participants might actively lie, not just fail silently. That extra guarantee comes at a real cost, more replicas at 3f + 1 instead of 2f + 1, and message traffic that grows quadratically instead of linearly. Public blockchains and multi-organization consortiums need that guarantee because they genuinely operate without a trusted, shared operator.
A single company’s internal services, running on infrastructure one team controls, are almost always dealing with crash faults instead, and Raft or Paxos already solve that problem at a fraction of the cost. The right question before adopting blockchain-grade consensus is never “would this be more robust,” it is “do I actually have an adversary inside my trust boundary,” and for most internal systems, the honest answer is no.
