GPBFT instance should drop spammable messages from future rounds #240
Closed
Comments
This was referenced May 17, 2024
masih
added a commit
that referenced
this issue
May 21, 2024
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. Resolved #240
masih
added a commit
that referenced
this issue
May 21, 2024
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
added a commit
that referenced
this issue
May 22, 2024
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
github-merge-queue bot
pushed a commit
that referenced
this issue
May 22, 2024
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Most messages carry a justification which demonstrates that 2/3 of power is up to the same round (or previous) as the message itself. An attacker can't generate these for rounds arbitrarily far in the future, unless the network has actually progressed to that round, so these are not a DOS vector (assuming #153).
A COMMIT for bottom carries no such evidence. Pick some finite number of rounds ahead at which to accept these messages, and drop anything further ahead. The upcoming rebroadcast mechanism will be responsible for getting the network up to the same round if a network partition lasts longer than that.
Check also that there are no other such spammable messages. Perhaps just use
msg.justification= nilas the test.See filecoin-project/FIPs#998
The text was updated successfully, but these errors were encountered: