Byzantine Fault

A failure mode where a component doesn't just stop working — it continues operating but produces incorrect or misleading output. Named after the Byzantine Generals Problem (Lamport, Shostak, Pease, 1982), a thought experiment about coordinating an army when some generals may be traitors.

The generals problem

Several generals surround a city and need to agree whether to attack or retreat. They communicate by messenger. Some generals may be traitors who send contradictory orders — telling one neighbor "attack" and another "retreat" — trying to break coordination so part of the army attacks while the rest retreats.

The proven result: you need more than 3f+1 total generals to tolerate f traitors. With 3 generals and 1 traitor, the 2 loyal generals cannot reliably determine which messages to trust. With 4 generals and 1 traitor, they can use majority voting to overrule the bad actor.

Crash faults vs Byzantine faults

A crash fault is simple: the process stops. It sends no more messages. Other processes can detect this (eventually) by the absence of communication. This is the easier failure model — algorithms like Paxos and Raft handle it.

A Byzantine fault is any behavior that deviates from the protocol — wrong values, contradictory messages to different peers, selective silence, or arbitrary behavior. It's strictly harder to handle because you can't trust any single message from a potentially faulty node.

The practical difference is detection. A crashed node is obviously broken. A Byzantine node looks functional, which is what makes it dangerous.

Crash and Byzantine are the two endpoints software people usually name, but the full space of fault models — permanent vs transient, the redundancy schemes that mask each, and the reliability metrics used to compare them — is laid out from the hardware side in Dubrova's fault-tolerant-design.

Real-world examples

• A disk that silently returns corrupted data instead of reporting an error
• A misconfigured server that reports success to clients but doesn't actually persist writes
• A compromised node in a peer-to-peer network that lies about which blocks it has
• An LLM agent that confidently produces code based on a misread prompt — it didn't crash, it just interpreted things differently than every other agent (log-distributed-llms)

Handling Byzantine faults

PBFT (Practical Byzantine Fault Tolerance) is the classic algorithm — every node broadcasts its decision to every other node, and nodes accept the majority view. Expensive: O(n^2) messages per decision.

Convert to crash faults — the cheaper alternative. Instead of running Byzantine-tolerant protocols, add external validators that check output correctness. An agent that produces code that fails tests is now a detected crash (retry it) rather than a silent divergence. This is the strategy recommended in log-distributed-llms for multi-agent LLM systems, and it's the same reason databases use checksums on disk reads.

human-in-the-loop review serves a similar function — a human checking agent output is a Byzantine fault detector, catching cases where the agent's work is plausible but wrong.