TL;DR
Binance Consensus records the next validator set at the epoch boundary and activates it after a delayed switching height. We show that if two branches reach the epoch boundary with different state and both continue to grow until the switching height, they may activate different validator committees. We construct an attack scenario demonstrating how committee divergence can occur in Binance Consensus.
Background
Binance Consensus is the consensus protocol used in BNB Smart Chain and implemented through the Parlia protocol. Parlia adopts a committee-based consensus model where a fixed-size validator set produces blocks in a round-robin schedule. The validator set is updated periodically based on staking results.
At the boundary of each epoch, the validator set for the next epoch is recorded in the extra field of the block header. The new validator set is not activated immediately. Instead, the protocol applies the validator-set update only after a delayed switching condition is satisfied.
The switching rule is implemented in the following code:
Under commonly used parameters:
- epochLength = 200
- validators = 21
- turnLength = 1
The validator-set switching occurs 10 blocks after the epoch boundary.
This design separates two steps:
- validator-set determination
- validator-set activation
Threat Model
The attack scenario described in this report assumes the following conditions:
- The adversary can delay or reorder network messages.
- Temporary network partitions may occur.
- The adversary can submit staking transactions that affect validator ranking.
The adversary does not require control over a majority of validators and does not rely on signature forgery. These assumptions are consistent with commonly studied threat models for blockchain consensus protocols.
Observation
The current design introduces a dependency between branch state and future validator-set activation. If two branches reach the epoch boundary with different state, they may encode different validator sets in their respective epoch blocks. Because validator-set activation is delayed, both branches may continue to grow under the old validator set until the switching height. If the fork persists until that height, the two branches may activate different validator committees. We refer to this phenomenon as committee divergence.
High-Level Attack Scenario
At a high level, the following scenario may occur.
Step 1: Fork before the epoch boundary
The chain forks shortly before an epoch boundary (e.g., block height 200).
... -> 198 -> 199
/ \
200A 200B
Step 2: Different validator sets recorded
If the two branches carry different state, the epoch block on each branch may encode a different validator set:
200A.extra -> validator set A'
200B.extra -> validator set B'
Step 3: Branches continue to grow
Because the validator-set update is applied only after a delay, both branches may continue to produce blocks under the current committee:
200A -> ... -> 210A
200B -> ... -> 210B
Step 4: Divergent committee activation
At the switching height (e.g., block 210), the validator-set update is applied.
Branch A activates A'
Branch B activates B'
From that point onward, the two branches may operate under different validator committees.
Step 5: Safety implications
After the committee switch, the two branches operate under different validator sets. Validators in each committee continue signing blocks on their respective branches. Consequently, the system may produce conflicting finalized blocks, which may affect the safety guarantees of the consensus protocol.
Feasibility Analysis
The most challenging part of the above scenario is sustaining the fork long enough for the validator-set switch to occur. Currently, Binance Consensus adopts the Fast Finality (FF) mechanism. To realize the scenario above, the finalized block must remain around height 198 while the subsequent blocks remain in a competitive state.
Based on previously discussed approaches, this behavior is feasible under certain network conditions.
Another possible contributing factor is temporary network partitioning. Given the block interval ( currently around 0.75 seconds, with an upgrade targeting 0.25 seconds), short network partitions on the order of several seconds may realistically occur in globally distributed deployments.
To avoid enabling malicious exploitation, we omit the detailed reproduction procedure in this disclosure.
Suggested Mitigation
A potential mitigation is to ensure that validator-set activation occurs only after the corresponding epoch block has been finalized.
In the current design, the validator set for the next epoch is recorded at the epoch boundary but becomes active after a short delay determined by the switching rule:
func (s *Snapshot) minerHistoryCheckLen() uint64 {
return (uint64(len(s.Validators))/2+1)*uint64(s.TurnLength) - 1
}
Under commonly used parameters, this results in the new validator set becoming active roughly 10 blocks after the epoch boundary. However, this delay may not be sufficient to guarantee that the epoch boundary block has already been finalized.
As a result, if competing branches encode different validator sets and both survive until the switching height, the two branches may activate different validator committees, leading to inconsistent committee views across branches.
We strongly recommend decoupling validator-set activation from the short switching delay and instead tying activation to finalized chain state.
One possible approach is:
- The validator set determined at epoch boundary E should not become active within the same epoch.
- Instead, the new validator set should only become active after the epoch boundary block has been finalized.
- In practice, this can be achieved by activating the new validator set starting from the next epoch.
For instance:
- If a new validator set is recorded at block 200 (start of epoch E)
- The new committee should not become active during epoch E
- Instead, it should only become active at block 400 (start of epoch E+1)
Epoch E
200 ----------- 399
Epoch E+1
400 -> new validator set becomes active
By delaying activation until the next epoch, the validator set is guaranteed to be derived from a finalized chain state, which prevents different branches from activating different committees.
More generally, validator-set updates should satisfy the following property:
A validator set should only become active after the block determining it has been finalized.
Adopting this rule removes the window in which competing branches may activate inconsistent validator committees and improves the robustness of the consensus protocol.
Conclusion
This report describes a high-level observation discovered during ongoing research on blockchain consensus mechanisms. This document intentionally omits exploit code and precise attack parameters.
We hope this disclosure helps the BNB Chain team and the community further improve the robustness of Binance Consensus. We would be happy to provide additional technical details and collaborate on potential mitigations if needed.