Drop spammable messages beyond max allowed lookahead rounds #258
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #258 +/- ##
==========================================
+ Coverage 71.66% 71.91% +0.25%
==========================================
Files 31 32 +1
Lines 2333 2386 +53
==========================================
+ Hits 1672 1716 +44
- Misses 532 539 +7
- Partials 129 131 +2
|
masih
force-pushed
the
masih/rbrdcst-drp-spmbls
branch
from
396869b to
fbf4f9f
Compare
Kubuxu
reviewed
May 21, 2024
Kubuxu
approved these changes
May 21, 2024
anorth
reviewed
May 21, 2024
Member
|
My comments are essentially nits so need not block you merging. I would appreciate you taking the time to explore whether a more robust predicate is possible, though. |
The gPBFT rebroadcast design revision introduced an improvement whereby "spammable" messages, i.e. `COMMIT` for bottom, for future rounds should be dropped by the participants. The specification leaves room for implementers to optionally retain some number of such messages to reduce reliance on the need for rebroadcast and ultimately help reach consensus in fewer rounds. The work here: 1. introduces `WithMaxLookaheadRounds` configuration option to `gpbft` package, defaulting to zero if unset. 2. drops all spammable messages belonging to rounds that are beyond the configured max lookahead rounds. A `Spam` adversary is introduced to replicate the conditions at which max lookahead rounds would start dropping messages. A set of tests then use the `Spam` adversary to assert that honest participants reach expected consensus despite the presence of spam messages. Note that there are no APIs to assert that the upper lookahead bound is respected by the implementation. A TODO is left to revisit this once telemetry is introduced whereby tests can observe future message queue size metrics to assert a configured lookahead is indeed respected. Resolves #240
masih
force-pushed
the
masih/rbrdcst-drp-spmbls
branch
from
fbf4f9f to
a5b82d3
Compare
|
Fuzz test failed on commit a5b82d3. To troubleshoot locally, download the seed corpus using GitHub CLI by running: gh run download 9189781334 -n testdataAleternatively, download directly from here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The gPBFT rebroadcast design revision introduced an improvement whereby "spammable" messages, i.e.
COMMITfor bottom, for future rounds should be dropped by the participants. The specification leaves room for implementers to optionally retain some number of such messages to reduce reliance on the need for rebroadcast and ultimately help reach consensus in fewer rounds.The work here:
WithMaxLookaheadRoundsconfiguration option togpbftpackage, defaulting to zero if unset.A
Spamadversary is introduced to replicate the conditions at which max lookahead rounds would start dropping messages. A set of tests then use theSpamadversary to assert that honest participants reach expected consensus despite the presence of spam messages.Note that there are no APIs to assert that the upper lookahead bound is respected by the implementation. A TODO is left to revisit this once telemetry is introduced whereby tests can observe future message queue size metrics to assert a configured lookahead is indeed respected.
Resolves #240