fix: do not penalize peers for Invalid blocks from new_payload#297
Open
fix: do not penalize peers for Invalid blocks from new_payload#297
Conversation
In BSC's PoSA with devp2p block propagation, new_payload returning Invalid frequently results from timing issues during concurrent reorgs — the block itself is legitimate but was executed against the wrong state. The current code reports all Invalid blocks as BadBlock to the network layer, applying -16384 reputation per occurrence. Under BSC's fast block time (0.45s), this rapidly drains peers: just 4 reorg-related Invalids ban a peer, while recovery takes 4.5 hours per penalty at +1/sec. This aligns with geth's behavior: geth's fetcher only drops a peer when header verification fails (verifyHeader), never when block execution fails (insertChain). Truly malicious peers are still caught by the network layer's BadMessage / BadProtocol penalties. Refs #290, #258 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
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.
Summary
new_payloadreturnsInvalid. ReturnNoneinstead ofErr(BadBlock)to the network layer.Problem
In BSC's PoSA with devp2p block propagation,
new_payloadreturningInvalidfrequently results from timing issues during concurrent reorgs — the block itself is legitimate but was executed against the wrong state. The current code appliesBadBlockreputation penalty (-16,384) per occurrence.Under BSC's fast block time (down to 0.45s), this creates a death spiral:
InvalidThis is the root cause behind peers dropping from 4–5 to 1 as described in #290, and the persistent peer loss in #258.
Solution
All
Invalidresults fromnew_payloadare now logged but do not trigger peer reputation penalties. This aligns with geth's behavior:dropPeerwhenverifyHeader()fails (header-level validation)insertChain()fails (execution-level validation)new_payloadcombines both header and execution validation, so we cannot distinguish between the two — the safe default is to not penalizeTruly malicious peers (sending malformed messages, protocol violations) are still caught by the network layer's existing
BadMessage/BadProtocolreputation penalties, which operate at the RLPx session level before blocks ever reachnew_payload.Test plan
reth_network_connected_peers— should stabilize at normal levels (20-50)RUST_LOG="net::peers=trace"— confirm noBadBlockreputation changesreth_consensus_engine_beacon_pipeline_runsstops incrementing during normal operationRefs #290, #258
🤖 Generated with Claude Code