Skip to content

eth: fix canonical chain state inconsistency in checkpoint verifier#1593

Merged
cffls merged 2 commits into0xPolygon:developfrom
cffls:develop
Jun 26, 2025
Merged

eth: fix canonical chain state inconsistency in checkpoint verifier#1593
cffls merged 2 commits into0xPolygon:developfrom
cffls:develop

Conversation

@cffls
Copy link
Copy Markdown
Contributor

@cffls cffls commented Jun 26, 2025

Add fallback logic to find potentialcommon ancestor using future milestones when no whitelisted milestone exists in the current chain. Such scenario usually happens in a devnet. This prevents nodes from getting stuck on wrong forks during milestone verification.

The issue occurs when nodes are on a fork and receive a new milestone:

  • Existing logic only checks whitelisted milestones in current chain
  • If current chain has no whitelisted milestones, rewind defaults to milestone start-1
  • This can leave nodes on wrong fork instead of finding actual common ancestor

New logic adds findCommonAncestorWithFutureMilestones() which:

  • Reads future milestone list from database (contains previously failed milestones)
  • Searches from newest to oldest milestone to find matches with local chain
  • Returns matching milestone block number to minimize rewind distance
  • Falls back to calculated target block if no matches found

Changes

  • Bugfix (non-breaking change that solves an issue)
  • Hotfix (change that solves an urgent issue, and requires immediate attention)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (change that is not backwards-compatible and/or changes current functionality)
  • Changes only for a subset of nodes

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

  • I have added at least 2 reviewer or the whole pos-v1 team
  • I have added sufficient documentation in code
  • I will be resolving comments - if any - by pushing each fix in a separate commit and linking the commit hash in the comment reply
  • Created a task in Jira and informed the team for implementation in Erigon client (if applicable)
  • Includes RPC methods changes, and the Notion documentation has been updated

Cross repository changes

  • This PR requires changes to heimdall
    • In case link the PR here:
  • This PR requires changes to matic-cli
    • In case link the PR here:

Testing

  • I have added unit tests
  • I have added tests to CI
  • I have tested this code manually on local environment
  • I have tested this code manually on remote devnet using express-cli
  • I have tested this code manually on amoy
  • I have created new e2e tests into express-cli

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

Add fallback logic to find potentialcommon ancestor using future milestones when
no whitelisted milestone exists in the current chain. Such scenario usually happens in a devnet.
This prevents nodes from getting stuck on wrong forks during milestone verification.

The issue occurs when nodes are on a fork and receive a new milestone:
- Existing logic only checks whitelisted milestones in current chain
- If current chain has no whitelisted milestones, rewind defaults to milestone start-1
- This can leave nodes on wrong fork instead of finding actual common ancestor

New logic adds findCommonAncestorWithFutureMilestones() which:
- Reads future milestone list from database (contains previously failed milestones)
- Searches from newest to oldest milestone to find matches with local chain
- Returns matching milestone block number to minimize rewind distance
- Falls back to calculated target block if no matches found
@cffls cffls requested a review from a team June 26, 2025 00:42
@codecov
Copy link
Copy Markdown

codecov bot commented Jun 26, 2025

Codecov Report

Attention: Patch coverage is 0% with 59 lines in your changes missing coverage. Please review.

Project coverage is 48.10%. Comparing base (b1a23a3) to head (5bf86b5).
Report is 590 commits behind head on develop.

Files with missing lines Patch % Lines
eth/bor_checkpoint_verifier.go 0.00% 59 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1593      +/-   ##
===========================================
- Coverage    50.83%   48.10%   -2.74%     
===========================================
  Files          780      819      +39     
  Lines       125430   132545    +7115     
===========================================
- Hits         63765    63759       -6     
- Misses       57555    64653    +7098     
- Partials      4110     4133      +23     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Copy Markdown
Contributor

@lucca30 lucca30 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks!

@cffls cffls merged commit 5a2b674 into 0xPolygon:develop Jun 26, 2025
11 of 17 checks passed
cffls added a commit to cffls/bor that referenced this pull request Jun 30, 2025
eth: fix canonical chain state inconsistency in checkpoint verifier
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants