SOLID STATE PRESS
← Back to catalog
Byzantine Fault Tolerance cover
Coming soon
Coming soon to Amazon
This title is in our publishing queue.
Browse available titles
Cryptocurrency & Blockchain

Byzantine Fault Tolerance

The Generals' Problem, PBFT, and How Blockchains Agree Without Trust — A TLDR Primer

Distributed systems and blockchain courses throw terms like Byzantine fault tolerance, PBFT, and Nakamoto consensus at students with almost no setup — and then the exam arrives. If you have stared at a whiteboard wondering why agreeing on anything gets so complicated when one node might be lying, this guide is for you.

A concise primer with no filler. It starts with the Byzantine Generals Problem — the 1982 thought experiment by Lamport, Shostak, and Pease that put a name to the hardest class of distributed failure — and builds from there. You will learn why crash faults and Byzantine faults are not the same thing, where the 3f+1 node requirement comes from and how to reason through it, and how Castro and Liskov's PBFT algorithm turned theory into a deployable three-phase protocol. The guide then shows how Bitcoin's Nakamoto consensus sidesteps classical voting entirely, using economic cost as a substitute for mathematical guarantees, and closes with a survey of where BFT shows up today — Tendermint, HotStuff, Ethereum's finality gadget, and safety-critical hardware.

The book is written for high school and early college students taking computer science, cryptography, or blockchain courses, as well as self-learners who need a fast, honest orientation before diving into research papers. Every term is defined in plain language. Every claim is backed by a concrete example or worked number. No filler.

If you need to understand how blockchains reach agreement without trust, pick this up and start reading today.

What you'll learn
  • State the Byzantine Generals Problem and explain why it is hard
  • Distinguish crash faults from Byzantine faults and know why the distinction matters
  • Understand the one-third bound: why BFT needs at least 3f+1 nodes to tolerate f traitors
  • Walk through the phases of Practical Byzantine Fault Tolerance (PBFT)
  • Compare classical BFT with Nakamoto consensus (Proof of Work) and modern BFT-style blockchains
  • Recognize where BFT shows up in real systems: Bitcoin, Ethereum, Tendermint, aircraft, and more
What's inside
  1. 1. The Byzantine Generals Problem
    Introduces the original thought experiment by Lamport, Shostak, and Pease and explains why agreement is hard when some participants may lie.
  2. 2. Faults, Failures, and Why Byzantine Is the Worst Kind
    Defines the spectrum of failures a node can have — crash, omission, timing, Byzantine — and why arbitrary/malicious behavior is the hardest case to defend against.
  3. 3. The 3f+1 Bound and Why Math Forces It
    Walks through the proof intuition that any BFT system needs at least 3f+1 nodes to tolerate f Byzantine faults, with a small worked example.
  4. 4. Practical Byzantine Fault Tolerance (PBFT)
    Explains Castro and Liskov's 1999 PBFT algorithm — the three-phase protocol (pre-prepare, prepare, commit) that made BFT actually deployable.
  5. 5. Nakamoto Consensus: BFT Without Voting
    Shows how Bitcoin's Proof of Work sidesteps classical BFT by using economic cost and the longest-chain rule, and how it relates to (and differs from) traditional BFT.
  6. 6. BFT in Modern Blockchains and Beyond
    Surveys where BFT shows up today — Tendermint, HotStuff, Ethereum's finality gadget, aircraft control systems — and what students should watch for next.
Published by Solid State Press
Byzantine Fault Tolerance cover
TLDR STUDY GUIDES

Byzantine Fault Tolerance

The Generals' Problem, PBFT, and How Blockchains Agree Without Trust — A TLDR Primer
Solid State Press

Byzantine Fault Tolerance

The Generals' Problem, PBFT, and How Blockchains Agree Without Trust — A TLDR Primer

Copyright © 2026 Solid State Press.

Published by Solid State Press.

All rights reserved. No part of this book may be reproduced or transmitted in any form without prior written permission, except for brief quotations in critical reviews and educational use.

Part of the TLDR Study Guides series.

Contents

  1. 1 The Byzantine Generals Problem
  2. 2 Faults, Failures, and Why Byzantine Is the Worst Kind
  3. 3 The 3f+1 Bound and Why Math Forces It
  4. 4 Practical Byzantine Fault Tolerance (PBFT)
  5. 5 Nakamoto Consensus: BFT Without Voting
  6. 6 BFT in Modern Blockchains and Beyond
Chapter 1

The Byzantine Generals Problem

Imagine you are a general besieging a city. Your army is split across several camps surrounding the walls, and you can only communicate by messenger. To win, every loyal general must attack at the same time — a divided assault fails. The problem: some of your generals may be traitors who will send different messages to different camps, deliberately trying to cause chaos. How do you guarantee that all loyal generals agree on the same plan?

This thought experiment, formalized in a landmark 1982 paper by Leslie Lamport, Robert Shostak, and Marshall Pease, became one of the foundational problems in computer science. The paper called it the Byzantine Generals Problem — "Byzantine" serving as a colorful label for treachery and deception, borrowed from the historical reputation of the Byzantine Empire's court intrigues. The name stuck, and the problem it describes sits at the heart of every blockchain, distributed database, and fault-tolerant system built since.

Why This Is a Computer Science Problem

The generals are a metaphor. Replace each general with a node — a computer in a distributed system, meaning a collection of machines that communicate over a network and work together toward a shared goal. Replace the messengers with network messages. Replace the traitors with nodes that have crashed, been hacked, or are deliberately sending false information.

The goal — every loyal general agrees on the same plan — translates directly into the computer science concept of consensus: getting all honest nodes in a distributed system to agree on a single value, even when some nodes are behaving badly.

This might sound straightforward. Why not just have every general share their plan and vote? The trouble is that a traitor doesn't have to lie outright. A traitor can send "attack at dawn" to some generals and "retreat at noon" to others. If honest generals simply collect messages and act on the majority, they can be manipulated — because they don't know which messages are genuine and which are forged.

The Two Characters: Honest and Traitor

Lamport and his co-authors drew a sharp line between two types of participants. An honest node (loyal general) follows the protocol exactly: it sends the same message to every other node, tells the truth about what it received, and does not deviate. A traitor node (Byzantine node) can do anything at all — send contradictory messages, stay silent, selectively delay responses, or collude with other traitors. The only thing a traitor cannot do is break cryptography (forge signatures from honest nodes, for instance, in versions of the problem that use signed messages).

About This Book

If you are taking a distributed systems course and need a beginner primer that actually makes sense, studying blockchain technology and want the consensus algorithms explained without hand-waving, or preparing for a technical interview where someone might ask you to sketch the Byzantine Generals Problem for students in the room — this book is for you. Developers exploring crypto consensus mechanisms and curious readers who want to understand how blockchains agree without trust will find it equally useful.

This guide covers the Byzantine Generals Problem, the 3f+1 fault-tolerance bound, Practical Byzantine Fault Tolerance (PBFT), Nakamoto consensus via proof of work, and a proof of work vs. PBFT comparison that shows why different systems make different trade-offs. It doubles as a blockchain consensus algorithms study guide and keeps Byzantine fault tolerance explained simply throughout. Short by design, no filler.

Read straight through to build the concepts in order, follow each worked example step by step, then attempt the problem set at the end to confirm you can apply what you have learned.

Keep reading

You've read the first half of Chapter 1. The complete book covers 6 chapters in roughly fifteen pages — readable in one sitting.

Coming soon to Amazon