Byzantine Fault
A failure in which a component behaves arbitrarily or deceptively — returning wrong results rather than stopping — as distinct from simply crashing.
The failure model distinction that determines which algorithms apply. A crash fault means a node stops; it never lies. A Byzantine fault means a node may send contradictory information to different peers, return corrupted results, or behave maliciously.
Most infrastructure assumes crash faults, and that assumption is usually reasonable inside one organisation's trust boundary. Raft and Paxos tolerate crash faults only; a single Byzantine participant can break them.
Byzantine fault tolerance requires more replicas — the classic result is that tolerating f Byzantine faults needs 3f+1 participants, versus 2f+1 for crash faults — and considerably more message exchange. It is the reason blockchain consensus is expensive: participants are mutually untrusting by design.
Where it matters outside that context, and it does occur: silent data corruption from failing memory or storage returning wrong bytes rather than errors, and a buggy release that returns confidently wrong answers. The practical defences are not consensus protocols but checksums, end-to-end verification, and canary comparison — checking that a component's output is right, not merely that it responded.