Fix: fix quorum calculation bug in HasQuorum function (#124) #125
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Title: Fix Quorum Calculation Logic in
HasQuorumFunctionSummary
This PR fixes a consensus bug in the
HasQuorumfunction where quorum calculation incorrectly depended on the number of signers instead of the validator set size. The faulty logic required 100% voting power whenever there were fewer than 4 signers, which caused unnecessary stalls in valid scenarios.Background
The core IBFT library (
consensus/ibft/validators.go) defines quorum based on validator set size (set.Len()), not the number of block signers. It provides two quorum calculation methods:2F + 1formula (whereF = max faulty nodes)ceil(2/3 * N)formulaThe buggy implementation in our code deviated from this by introducing a special case:
This caused valid blocks with sufficient voting power (e.g., 3 high-VP signers with 80% VP) to fail quorum checks when
valsCount < 4.Changes Implemented
signers < 4getQuorumSize(blockNumber, totalVotingPower)for quorum calculationHasQuorumfor better maintainabilityBefore (Buggy)
After (Fixed)
Benefits
Testing
TestValidatorSet_HasQuorumverified)Impact