The diagrams illustrate PBFT-family consensus algorithms (PBFT, IBFT, and QBFT), which are Byzantine Fault Tolerant protocols used in permissioned blockchains such as Hyperledger Besu.
1. PBFT (Practical Byzantine Fault Tolerance)
Purpose
- Allows distributed nodes to agree on a block even if some validators are malicious or faulty.
- Tolerates up to f Byzantine nodes among 3f + 1 validators.
Consensus Phases
1. Request
- A client sends a transaction to the leader (primary).
2. Pre-Prepare
- The leader proposes a new block.
- All validators receive the proposal.
3. Prepare
- Validators verify the proposed block.
- If valid, they broadcast a Prepare message.
- When a validator receives at least 2f + 1 Prepare messages, the block is considered prepared.
4. Commit
- Validators broadcast Commit messages.
- After receiving 2f + 1 Commit messages, the block is finalized.
5. Reply
- Validators execute the transactions.
- The client receives confirmation.
Characteristics
- Three communication rounds.
- Immediate finality (no forks).
- High message complexity (O(n²)).
- Excellent for permissioned networks.
2. IBFT (Istanbul Byzantine Fault Tolerance)
IBFT is an adaptation of PBFT designed specifically for Ethereum-compatible blockchains.
Consensus Flow
Leader Selection
- One validator becomes the proposer for the current round.
Proposal
- The proposer creates a candidate block.
Validation
Validators verify:
- Block format
- Signatures
- Transactions
- Gas limits
- Previous block hash
Prepare
- Validators multicast a Prepare message.
Commit
- After receiving 2f + 1 Prepare messages, validators send Commit.
Finalization
- Once 2f + 1 Commit messages are collected, the block is appended to the chain.
Additional Features
- Round-change protocol.
- Automatic leader replacement after timeouts.
- Better suited for blockchain environments than classical PBFT.
- Used in early versions of Hyperledger Besu and Quorum.
3. QBFT (Quorum Byzantine Fault Tolerance)
QBFT is the successor to IBFT and is currently the recommended consensus algorithm for Hyperledger Besu.
It keeps the PBFT consensus model while simplifying validator management and improving robustness.
Consensus Phases
1. Proposal
- The proposer creates a block.
2. Prepare
- Validators verify the proposal.
- Valid validators broadcast a Prepare message.
3. Commit
- After receiving 2f + 1 Prepare messages, validators broadcast Commit.
4. Finalization
- After 2f + 1 Commit messages, the block becomes final.
Improvements over IBFT
- More robust round-change mechanism.
- Better handling of validator changes.
- Simpler protocol specification.
- Improved interoperability with Enterprise Ethereum implementations.
- Lower operational complexity.
Comparison
| Feature | PBFT | IBFT | QBFT |
|---|---|---|---|
| Byzantine Fault Tolerant | ✅ | ✅ | ✅ |
| Leader-based | ✅ | ✅ | ✅ |
| Consensus Phases | Pre-Prepare → Prepare → Commit | Proposal → Prepare → Commit | Proposal → Prepare → Commit |
| Immediate Finality | ✅ | ✅ | ✅ |
| Forks | No | No | No |
| Round Change | Basic | Improved | More Robust |
| Ethereum Compatible | No | Yes | Yes |
| Hyperledger Besu | No | Legacy | Recommended |
Fault Tolerance
For all three protocols:
- Number of validators = 3f + 1
- Maximum Byzantine failures = f
- Quorum = 2f + 1
Examples
| Validators | Byzantine Faults Tolerated | Quorum |
|---|---|---|
| 4 | 1 | 3 |
| 7 | 2 | 5 |
| 10 | 3 | 7 |
| 13 | 4 | 9 |
Why QBFT is Preferred Today
For modern permissioned Ethereum networks (such as Hyperledger Besu), QBFT is generally preferred because it:
- Provides deterministic finality.
- Tolerates Byzantine failures.
- Includes a more reliable round-change mechanism.
- Simplifies validator management.
- Offers improved stability over IBFT while maintaining the same consensus guarantees.
This is why QBFT has become the default recommendation for new Hyperledger Besu deployments.
