What is Byzantine fault tolerance?
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
Byzantine fault tolerance is the property of reaching correct agreement even when some participants do not merely crash but actively lie or send contradictory messages. The classical result is that agreement is possible as long as faulty participants number fewer than one third of the total. Many blockchains are designed on that premise.
Key points
- Tolerates lying and contradictory messages, not just crashes
- Classically, agreement holds if faults stay under one third
- Requires several rounds of voting among participants
- Message volume grows sharply with the participant count
Definition
The property of a distributed system in which correct nodes still reach the same conclusion despite some nodes behaving arbitrarily. It assumes faulty nodes make up fewer than one third of the total.
Distributed systems face two kinds of failure: crash faults, where a node simply stops responding, and arbitrary faults, where it returns wrong values or tells different peers different things. The latter are Byzantine faults, and they arise from bugs and misconfiguration as readily as from malice.
Once faulty participants reach one third of the total, honest participants can no longer establish a decisive majority and contradictory conclusions can stand at the same time. Below one third, exchanging claims as votes lets every honest participant converge on the same answer.
Implementations run several phases — propose, pre-vote, commit — each requiring more than two thirds in favour. A block that clears both voting phases cannot be reversed, which gives explicit finality. That differs in kind from longest-chain rules, where confidence only grows probabilistically.
The price is communication. Because participants exchange votes with one another at each phase, message counts grow roughly with the square of the participant count. Chains using this approach therefore cap the validator set or compress traffic with aggregate signatures.
Watch out for
- · The one-third bound counts voting weight, usually staked amount, not head count
- · If many validators share one operator or one cloud provider, the independence assumption breaks
- · Explicit finality says nothing about whether the implementation is free of bugs