A Byzantine fault-tolerant consensus algorithm keeps replicated systems from accepting conflicting states when some participants act arbitrarily or maliciously. Without it, compromised databases might show different balances or histories, creating a fork. Participants authenticate messages and decisions cryptographically, then agree on valid state transitions. section 12.1.2
A BFT protocol is judged by two essential properties:
- Safety prevents participants from agreeing on contradicting states; forks should not occur, or should occur only with negligible probability. section 12.4.1
- Liveness ensures submitted transactions eventually get processed, so malicious participants cannot permanently stop progress. section 12.4.1
- Classical BFT protocols use a known, fixed participant set; proof of authority or proof of stake can determine that set. section 12.1.3 section 12.5
- They typically avoid proof-of-work overhead and can provide finality in seconds with throughput on the order of thousands of transactions per second. section 12.3.2 section 12.3.5
DiemBFT
Diem uses DiemBFT, a HotStuff variant, to operate a payment network backed by fiat reserves. The protocol is designed to avoid forks and continue making progress after network partitions, provided the network eventually heals and stabilizes. section 12.4 section 12.4.1
Figure 12.1 A centralized network can be seen as a single point of failure, whereas a distributed and decentralized network are resilient to a number of servers shutting down or acting maliciously. A permissioned network has a known and fixed set of main actors, while in a permissionless network, anyone can participate.
Compare centralized, decentralized, permissioned, and permissionless networks by their failure resilience and participant rules. section 12.1.3
