The Node That Keeps Answering And Lies

Fail-stop versus Byzantine fault models in a 3-node cluster, with the 2f+1 versus 3f+1 replication arithmetic

Core Concept

A fault model is an assumption about how a component is allowed to misbehave, and every consensus protocol you pick is downstream of it. A node that crashes and stops talking is benign because it is detectable by absence — the heartbeat stops, and every surviving replica reaches the same conclusion. A node that keeps running, keeps answering, and sends conflicting data — value X to replica A and value Y to replica B in the same round — is the expensive failure: nothing is missing, so absence cannot catch it, and no single observer can tell a liar from a slow link.

Key Components

The Fault Model

The assumption about how a component may misbehave. Crash or lie — the choice decides which protocol family you are even allowed to run.

Fail-Stop

The node crashes cleanly and goes silent. Benign not because losing it is cheap, but because absence is detectable by everyone, at the same time.

Byzantine

The node stays up, passes health checks, and answers — with wrong or conflicting values per replica. Nothing missing; a liar is indistinguishable from a flaky network.

The Replication Arithmetic

f crash faults → 2f+1 replicas. f Byzantine faults → 3f+1. One machine dying costs three; one machine lying costs four — unless you can make lies unforgeable.

How It Works

Choose the fault model first. Crash or Byzantine is not a detail of the protocol — it is the premise. Every quorum size, every voting rule, every leader rule is derived from it.

Fail-stop is caught by silence. The heartbeat stops; every survivor independently concludes the same node is gone, so a simple majority can still make progress without it.

Byzantine is caught by cross-checking. The lying node answers everyone — differently to each. Detection works only by comparing messages between honest replicas, which is what makes the protocol strictly more expensive.

crash: n ≥ 2f + 1 f=1 → 3 replicas
byzantine: n ≥ 3f + 1 f=1 → 4 replicas
Lamport–Shostak–Pease: 3f+1 holds for ORAL messages;
with unforgeable written messages (signatures):
solvable for ANY number of generals and traitors.

Signatures change the arithmetic. If a message cannot be repudiated or forged, a liar cannot tell X to A and Y to B. That is exactly why modern systems sign everything — the bound quoted as “3f+1” is the no-signature case only.

Where it lands. etcd, ZooKeeper, Raft-family clusters assume fail-stop and would be defeated by one lying member. Blockchains pay for Byzantine tolerance because their participants are mutually untrusting.

Real-World Applications

etcd / ZooKeeper / Raft databases — built on the fail-stop model; a single Byzantine member can wedge the whole quorum.
Public blockchains (BFT, PBFT, PoS validators) — Byzantine tolerance is the product, because no one trusts the other validators.
“Up and confidently wrong” incidents — a corrupted disk returning plausible bytes, a bad deploy on one host, a compromised process: all pass health checks, all lie.
Quorum sizing decisions — “majority works” is a crash-fault statement; it says nothing about how many liars you can absorb.

Checkpoint — answer before you move on

1Why can no single observer tell a Byzantine node from a slow network, while a fail-stop node is easy for everyone to agree about?

What is missing in one case that is present in the other — and what does each observer see locally?

2How many replicas do you need to tolerate one crash fault, and one Byzantine fault? Which condition does the 3f+1 bound depend on?

2f+1 → 3, and 3f+1 → 4. The bound is from Lamport–Shostak–Pease and applies only while messages are ORAL.

3Why can your etcd cluster get away with a fail-stop assumption while a blockchain must pay for Byzantine tolerance?

It is not about technology — it is about whether the participants trust each other. Name what changes the threat model.