Skip to content
Writing

Playing the Byzantine Generals Problem in a room full of engineers

2026 · 6 min read


A Saturday DevCongress meetup at the Fido hub. Our system design instructor, Tonny-Bright Sogli, split the room into groups of about five, made each group a “general”, and played game master. The job was simple: get one order, attack or retreat, from the game master to every general so they all act together.

We played three rounds. Each one broke something new.

Round one: everyone is honest

A loyal lead general relays the order down the chain. Every group passes it on faithfully. Everyone agrees. It's almost boring, which is the point: when nobody lies, agreement is just message passing.

Round two: one group is compromised

One group in the chain turns traitor. It doesn't go quiet; it tells some generals to attack and others to retreat. That's the nasty part. A node that crashes is easy to notice. A node that stays up and lies differently to different people looks exactly like a working one.

Round three: everyone talks to everyone

Now every group sends conflicting messages to every other group. Within a couple of minutes nobody could say what the original order was. More communication didn't produce more certainty; it produced more noise.

The rule underneath

Lamport, Shostak and Pease formalised this in 1982. If generals can only pass along spoken messages (no signatures, nothing that can't be faked) then with n generals and f traitors you can guarantee agreement only when

n ≥ 3f + 1

One traitor needs four generals. Two need seven. Three need ten. Below that line it isn't unlikely, it is impossible: no protocol, however clever, can do it. Try it:

Generals
4
Traitors
1

Consensus guaranteed

4 ≥ 3 × 1 + 1. The loyal generals agree no matter what the traitors say.

Green generals are loyal, red ones lie. Dashed lines are messages that can't be trusted.

Why three, not two

The smallest case shows it. Take a commander and two lieutenants, one of them a traitor. Lieutenant A hears “attack” from the commander, and hears from lieutenant B that the commander said “retreat”.

Either the commander is the traitor and told them different things, or B is the traitor and is lying about what the commander said. From where A stands, those two worlds look identical, and they demand opposite responses. No rule A follows can be right in both. Scale that up by replacing each general with a group of f and you get the general bound.

The other way to see it is through overlap. With 3f + 1 generals, any two groups of 2f + 1 share at least f + 1 members, so at least one honest general sits in both and can't be made to say two different things. That overlap is what protocols like PBFT build on.

What surprised me afterwards

  • Crashes are cheaper than lies. Raft and Paxos, the protocols behind etcd, Consul and CockroachDB, stay consistent with only 2f + 1 nodes because they assume a failed node goes silent rather than malicious. Most of us run that model inside our own infrastructure, and it's the right call there.
  • Signatures change the maths. If a lieutenant can't forge the commander's order, Lamport showed agreement is possible with any number of traitors. Cryptography is doing real work in Byzantine systems, not decoration.
  • Where you actually need it: blockchains and distributed ledgers, where you can't trust the other nodes by design; aircraft and spacecraft, where redundant flight computers vote because a faulty sensor can send garbage rather than nothing; and zero-trust systems that refuse to assume the network, or the service on the other end, is honest.

What I took away

The useful question isn't “how do I reach agreement” but “what am I assuming about the things that fail”. Silent failure and lying failure need different numbers of machines, different protocols and a different bill. Getting that assumption wrong is how you over-build a system or, worse, under-build one.

The original paper is short and still very readable: The Byzantine Generals Problem (Lamport, Shostak & Pease, 1982). Thanks to Tonny-Bright and everyone at DevCongress for turning it into a game.


Work with me

Hiring for a backend, mobile or cloud role, or have something you want built? Tell me what you have in mind.

Send me a note