-
Notifications
You must be signed in to change notification settings - Fork 219
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
feat: bans for bad incoming blocks #5934
feat: bans for bad incoming blocks #5934
Conversation
Co-authored-by: stringhandler <[email protected]>
Test Results (Integration tests) 2 files + 2 11 suites +11 29m 15s ⏱️ + 29m 15s For more details on these failures, see this check. Results for commit fff14f0. ± Comparison against base commit 27f78de. ♻️ This comment has been updated with latest results. |
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.
I'll be honest I don't love this PR.
We're letting the ban periods be configurable per node which is okay, but then we're passing those periods around anytime we need to fetch reasons for a ban. These reasons don't actually need to know the configuration details.
On the BanReason
struct, we could use an enum to define the expected ban duration. BanDuration::Short
, BanDuration::Long
and BanDuration::Permenant
.
This makes it easy to manage in different services without creating a heavy requirement of config details. Once the BanReason reaches the ConnectivityManager, it can read the enum, and apply the correct configuration. The ConnectivityManager is the only one that needs to be able to translate that a BanDuration::Short
means 60 seconds.
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.
It's a lot cleaner
I would personally try to go one step closer, and get the timing config into the ConnectivityManager
so ban_peer_until
can take the BanReason
and we still don't need to destructure the duration until inside ban_peer_until
ConnectivityManager
is brought up with the CommsNode
spawn. So we have lots of config options at hand, and which we could pass directly to the ConnectivityManager
.
At the point the destructure is managed by the ConnectivityManager
it can be a simple helper function. Pass in the BanDuration
enum, and receive a Duration
as the return.
I am going to leave the config to move to this issue:#5933 |
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.
I accept pushing the last refactor to a new issue.
LGTM, utAck.
Description
Bans peers who send bad incoming blocks.
Consolidates banning a bit more.
Motivation and Context
Created an issue to fix the ban period in the config: #5933
Fixes: #5795