-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(op-node): Increase gossip seenMessagesTTL #4873
Conversation
…ck gossip is valid for
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #4873 +/- ##
===========================================
- Coverage 39.78% 35.23% -4.56%
===========================================
Files 271 181 -90
Lines 18589 15264 -3325
Branches 601 0 -601
===========================================
- Hits 7396 5378 -2018
+ Misses 10648 9339 -1309
- Partials 545 547 +2
Flags with carried forward coverage won't be shown. Click here to find out more. |
…er duplicate detection.
Adding @protolambda and @trianglesphere for review to this one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. And this is a non-breaking change in practice (since we don't rely on duplicate block propagation), should be fine to roll out whenever.
This PR has been added to the merge queue, and will be merged soon. |
This PR is next in line to be merged, and will be merged as soon as checks pass. |
Description
Increases the libp2p gossip
seenMessagesTTL
value so that it prevents a valid block from being replayed before it is invalid according to the application layer validation rules.Specifically, a block first becomes valid when its timestamp is 5 seconds in the future, and remains valid until its timestamp is 60 seconds in the past. Thus there's a 65 second period where blocks are valid. By setting
seenMessagesTTL
to cover this period, all forms of replaying gossip are prevented as either the libp2p layer will discard the message as a duplicate or it will be rejected based on its timestamp.While it's possible to ignore these duplicates with application layer validation it's more efficient to discard them at the libp2p layer to avoid the need for any validation to occur (which currently would include signature verification). Using
seenMessagesTTL
is also simpler as it's cache size is based on time so guarantees to cover all messages, whereas adjusting the size of theblockHeightLRU
in the application layer validation requires establishing an upper maximum on the number of valid blocks which could be received in the time window.Metadata