Allow peer sync recovery from a wrong fork#1588
Merged
marcello33 merged 1 commit into0xPolygon:v2.2.0-beta-candidatefrom Jun 24, 2025
Merged
Allow peer sync recovery from a wrong fork#1588marcello33 merged 1 commit into0xPolygon:v2.2.0-beta-candidatefrom
marcello33 merged 1 commit into0xPolygon:v2.2.0-beta-candidatefrom
Conversation
This commit implements a fork detection mechanism in the whitelist milestone validation system to resolve synchronization issues that occur when nodes sync from new milestone with extremely low latency. The problem was that nodes on different chain forks would be unable to sync with peers due to milestone validation rejecting chains with different block hashes, leading to "mismatch error" failures. Root Cause Analysis: The issue was caused by chain fork lock-in where milestone validation prevented nodes stuck on wrong forks from syncing to the correct canonical chain. Debug logs revealed that different nodes had different block hashes for the same block numbers, confirming a fork scenario where milestone validation was blocking recovery. Solution Implemented: - Added ChainReader interface to milestone validation for blockchain access - Implemented fork detection logic in IsValidPeer method that checks if local blockchain has different hash than milestone hash for the same block number - When a fork is detected, the validation allows peer synchronization to proceed, enabling automatic recovery to the canonical chain - Added SetBlockchain method to inject blockchain reference after both whitelist service and blockchain are initialized (avoiding circular dependency) - Updated service creation in eth/backend.go to set blockchain reference after initialization
marcello33
approved these changes
Jun 24, 2025
fdf6cd6
into
0xPolygon:v2.2.0-beta-candidate
10 of 13 checks passed
cffls
added a commit
to cffls/bor
that referenced
this pull request
Jun 30, 2025
This commit implements a fork detection mechanism in the whitelist milestone validation system to resolve synchronization issues that occur when nodes sync from new milestone with extremely low latency. The problem was that nodes on different chain forks would be unable to sync with peers due to milestone validation rejecting chains with different block hashes, leading to "mismatch error" failures. Root Cause Analysis: The issue was caused by chain fork lock-in where milestone validation prevented nodes stuck on wrong forks from syncing to the correct canonical chain. Debug logs revealed that different nodes had different block hashes for the same block numbers, confirming a fork scenario where milestone validation was blocking recovery. Solution Implemented: - Added ChainReader interface to milestone validation for blockchain access - Implemented fork detection logic in IsValidPeer method that checks if local blockchain has different hash than milestone hash for the same block number - When a fork is detected, the validation allows peer synchronization to proceed, enabling automatic recovery to the canonical chain - Added SetBlockchain method to inject blockchain reference after both whitelist service and blockchain are initialized (avoiding circular dependency) - Updated service creation in eth/backend.go to set blockchain reference after initialization
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.
This commit implements a fork detection mechanism in the whitelist milestone validation system to resolve synchronization issues that occur when nodes sync from new milestone with extremely low latency. The problem was that nodes on different chain forks would be unable to sync with peers due to milestone validation rejecting chains with different block hashes, leading to "mismatch error" failures.
Root Cause Analysis:
The issue was caused by chain fork lock-in where milestone validation prevented nodes stuck on wrong forks from syncing to the correct canonical chain. Debug logs revealed that different nodes had different block hashes for the same block numbers, confirming a fork scenario where milestone validation was blocking recovery.
Solution Implemented:
Changes
Breaking changes
Please complete this section if any breaking changes have been made, otherwise delete it
Nodes audience
In case this PR includes changes that must be applied only to a subset of nodes, please specify how you handled it (e.g. by adding a flag with a default value...)
Checklist
Cross repository changes
Testing
Manual tests
Please complete this section with the steps you performed if you ran manual tests for this functionality, otherwise delete it
Additional comments
Please post additional comments in this section if you have them, otherwise delete it