Increase penalty for old block gossip spam #6050
Merged
Conversation
This file contains 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
michaelsproul
added
ready-for-review
AgeManning
approved these changes
Jul 5, 2024
|
@mergify queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 94d55be |
michaelsproul
added
ready-for-merge
5 tasks
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.
Issue Addressed
Simplified and streamlined version of:
Proposed Changes
We're still seeing a lot of stale pre-finalization blocks being gossiped by Erigon/Caplin. To encourage users to update to a non-buggy version, this PR increases the peer penalty which will result in more frequent bans.
As far as I can tell there are no cases where honest peers should be gossiping blocks prior to finalization. If a peer is syncing, they should not be broadcasting the blocks they're syncing on gossip. In case of a consensus fault and chain split, it's somewhat irrelevant whether the two sides of the split remain connected to each other, as the damage has already been done by finalizing and nodes will need to be manually resynced to the correct chain. E.g. if Lighthouse-Geth finalizes an invalid checkpoint, then it will view the (valid) minority chain as conflicting with its view of finalization. There is no way it will continue importing blocks from the valid chain until its DB is blown away to revert the faulty finalization. Most attached validators (ones that attested to the invalid finalization) will also be lost at this point (leaked out to 0).
Additional Info
Related to:
BEACON_BLOCK_DELAY_GOSSIPmetric only after a bock is verified #6046