Fix the threshold in 3sf-mini #158
Open
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.
I believe that 3sf-mini has a rounding issue:
research/3sf-mini/consensus.py
Lines 96 to 97 in d225a67
For instance, if$\frac{2n}{3}$ , whereas integer division sometimes gives us a smaller threshold. As a result, if a faulty staker sends different blocks to different peers, the network may get partitioned. I have introduced such a proposer in a fork. Indeed, it keeps growing two and sometimes three chains. I've also noticed scenarios in the simulations, in which validators were forgetting finalized blocks:
state.config.num_validators == 4, then the above condition evaluates totrueoncount == 2. This is due to the fact that distributed computing literature often refers to thresholds in rational numbers, e.g.,This PR proposes a fix that avoids integer division:
With this fix in place, the simulation seems to work fine, even in the presence of a faulty proposer.