|
| 1 | +# QBFT Consensus |
| 2 | + |
| 3 | +RBFT implements the QBFT (Quorum Byzantine Fault Tolerant) consensus protocol, |
| 4 | +a practical BFT algorithm designed for permissioned blockchain networks. |
| 5 | + |
| 6 | +## References |
| 7 | + |
| 8 | +- [The Istanbul BFT Consensus Algorithm (IBFT paper)](https://arxiv.org/abs/2002.03613) |
| 9 | +- [QBFT Formal Specification (ConsenSys)](https://github.com/ConsenSys/qbft-formal-spec-and-verification) |
| 10 | + |
| 11 | +## Protocol overview |
| 12 | + |
| 13 | +QBFT operates in rounds within each block height. Each round has a designated |
| 14 | +proposer determined by round-robin rotation. |
| 15 | + |
| 16 | +### Normal case (round 0) |
| 17 | + |
| 18 | +1. **Block timeout** — the proposer waits for the block interval, then |
| 19 | + broadcasts a `Proposal` containing the new block. |
| 20 | +2. **Prepare** — validators verify the proposal and broadcast a `Prepare` |
| 21 | + message. |
| 22 | +3. **Commit** — once a validator receives a quorum of prepares, it broadcasts |
| 23 | + a `Commit` message with a commit seal. |
| 24 | +4. **Finalize** — once a quorum of commits is collected, the block is added |
| 25 | + to the chain with the commit seals embedded in the header. |
| 26 | +5. **NewBlock** — the committed block is broadcast so all nodes (including |
| 27 | + followers) can update their chains. |
| 28 | + |
| 29 | +### Round change |
| 30 | + |
| 31 | +If the proposer fails to propose within the timeout, validators trigger a |
| 32 | +round change: |
| 33 | + |
| 34 | +1. Each validator sends a `RoundChange` message for the next round. |
| 35 | +2. When a quorum of round changes is collected, the new round's proposer |
| 36 | + creates a proposal with a justification (the round change messages). |
| 37 | +3. The protocol continues from step 2 (prepare phase). |
| 38 | + |
| 39 | +### Timeout schedule |
| 40 | + |
| 41 | +Round timeouts grow exponentially to avoid thrashing: |
| 42 | + |
| 43 | +``` |
| 44 | +timeout(r) = first_interval * growth_factor^r |
| 45 | +``` |
| 46 | + |
| 47 | +Default values: |
| 48 | + |
| 49 | +| Parameter | Default | |
| 50 | +|---|---| |
| 51 | +| `first_interval` | 1.0 s | |
| 52 | +| `growth_factor` | 2.0 | |
| 53 | +| `max_round` | 10 | |
| 54 | + |
| 55 | +## Proposer election |
| 56 | + |
| 57 | +The proposer for round 0 at a given height is the validator after the previous |
| 58 | +block's proposer (wrapping around). For subsequent rounds, the index advances |
| 59 | +by the round number: |
| 60 | + |
| 61 | +``` |
| 62 | +round_zero_index = index_of(previous_proposer) + 1 |
| 63 | +proposer_index = (round_zero_index + round) % num_validators |
| 64 | +``` |
| 65 | + |
| 66 | +At height 1, the first validator (index 0) proposes. |
| 67 | + |
| 68 | +## Quorum and fault tolerance |
| 69 | + |
| 70 | +For `n` validators: |
| 71 | + |
| 72 | +- Maximum Byzantine faults tolerated: `f = (n-1) / 3` |
| 73 | +- Quorum size: `q = (2n - 1) / 3 + 1` |
| 74 | + |
| 75 | +The protocol guarantees safety (no conflicting blocks are finalized) as long as |
| 76 | +at most `f` validators are faulty. It guarantees liveness as long as at least |
| 77 | +`q` validators are honest and connected. |
| 78 | + |
| 79 | +## Validator sets and epochs |
| 80 | + |
| 81 | +The validator set can change dynamically through the QBFTValidatorSet contract. |
| 82 | +Changes take effect at epoch boundaries (every `epochLength` blocks) to ensure |
| 83 | +all validators agree on the set for a given block range. |
0 commit comments