Libplanet PBFT
Posted on
What is PBFT?
Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithm designed to provide safety and liveness in distributed systems even when some nodes behave maliciously or fail arbitrarily — the so-called Byzantine faults.
PBFT assumes a partially synchronous network and tolerates up to f faulty replicas in a system of n = 3f + 1 total replicas. It ensures that all non-faulty replicas agree on the same sequence of client requests, despite faults.
What PBFT guarantees
- Safety: No two correct replicas execute requests in a different order.
- Liveness: As long as the network is partially synchronous and the primary is correct (or replaced), progress continues.
Concept of PBFT
PBFT operates in view-based epochs led by a primary replica. Each client request goes through these phases:
- Pre-Prepare: The primary proposes a request to all replicas.
- Prepare: Replicas echo the request to each other, ensuring it’s seen by at least 2f + 1 replicas.
- Commit: Replicas confirm the request is safe to execute.
- Reply: All non-faulty replicas execute the request and respond to the client.
A client accepts the result once it receives matching replies from f + 1 replicas.
If the primary is suspected of being faulty or slow, replicas trigger a view change to elect a new primary, preventing deadlocks.
Practical Implementation: Tendermint-style PBFT
Libplanet adopts a practical variant of the classic PBFT algorithm, inspired by the Tendermint consensus protocol. While classical PBFT assumes a fixed and known set of validators and involves a three-phase commit (Pre-prepare, Prepare, Commit) for each consensus round, Tendermint-style PBFT introduces several modifications to enhance scalability and real-world applicability:
- Round-based Voting with Timeouts: Tendermint-style PBFT introduces the concept of rounds and timeouts to handle leader failures more gracefully. If a proposer (leader) fails to propose a valid block in time, validators move to the next round and elect a new proposer. This dynamic leader election via round-robin avoids the liveness issues that classical PBFT faces under partial synchrony.
- Deterministic Proposer Selection: Instead of relying on external mechanisms to rotate leaders, Tendermint deterministically selects the proposer based on round number and validator set. This avoids the need for view-change protocols present in classic PBFT.
- Block-based Proposals: While classical PBFT focuses on agreement over individual operations or commands, Tendermint-style PBFT operates over entire blocks, reducing communication overhead and simplifying the consensus state.
- Delayed Finality: Classical PBFT provides immediate finality after reaching quorum in the Commit phase. In contrast, Tendermint-style PBFT may delay finality slightly to account for network asynchrony and validator performance. However, it still guarantees deterministic finality (i.e., no forks) once a block is committed.
- Simplified Communication Pattern: Tendermint reduces the communication complexity by leveraging gossip-based broadcasting and limiting the number of messages required for consensus, in contrast to the quadratic message complexity of classic PBFT.
By adopting these Tendermint-inspired adaptations, Libplanet achieves a more scalable and resilient consensus mechanism suitable for decentralized and partially synchronous environments, while retaining the core safety and liveness guarantees of PBFT.