Byzantine faults: when nodes lie, not just crash

Paxos, Raft, replication, and failure detection all assume crash faults: a broken node stops participating entirely — it goes silent, and every mechanism in this domain is built to detect and route around that silence. This is a reasonable assumption for most infrastructure most teams operate — their own servers, in their own data centers, running their own trusted code — but it's not the only kind of failure that exists.

A Byzantine fault is a node that keeps participating but sends incorrect, inconsistent, or actively contradictory information — including, in the adversarial framing, deliberately malicious behavior: telling different nodes different things, or claiming to have done something it didn't. The name comes from the "Byzantine Generals Problem," a thought experiment about generals coordinating an attack via messengers, where some generals might be traitors actively trying to prevent the honest generals from reaching agreement.

Both algorithms assume every node that responds is telling the truth about its own state — a node claiming "I promised proposal 5" is trusted to actually have promised proposal 5. A Byzantine node could lie about this, and neither Paxos nor Raft's safety guarantees hold up against that kind of active dishonesty. This isn't an oversight — it's a deliberate scope decision: defending against lying nodes requires substantially more message overhead and complexity, which would be wasted cost for the overwhelming majority of systems that genuinely only need to handle crash faults.

A Byzantine fault-tolerant protocol can reach correct consensus even when some fraction of nodes actively lie — but the mathematics requires significantly more nodes and more message rounds than crash-fault-tolerant consensus needs for the same guarantee: tolerating f Byzantine faults generally requires at least 3f + 1 total nodes (versus roughly 2f + 1 for crash faults alone), because the protocol needs enough honest nodes to outvote and cross-check the lying ones, not merely outnumber the failed ones.

Most internal infrastructure — a company's own database cluster, its own service mesh — reasonably assumes trusted, non-malicious participants and sticks with crash-fault-tolerant tools like Raft. Byzantine fault tolerance becomes necessary specifically when participants in a system don't inherently trust each other — the canonical example is blockchain consensus (Bitcoin's proof-of-work, and BFT-based protocols used by some other blockchains), where the entire premise is that some unknown fraction of participants might be actively adversarial, with no shared organization vouching for anyone's honesty.

Every mechanism this domain covered — logical clocks, replication, Paxos, Raft, failure detection, sagas — solves a real, common problem under the assumption that failures are honest (a crash, a delay, a network partition), never deceptive. That assumption is correct for the overwhelming majority of systems engineers actually build, which is exactly why crash-fault tolerance, not Byzantine fault tolerance, is the default lens for distributed-systems engineering — and why recognizing which assumption a given system actually needs is the last, most practical skill this domain builds toward.