Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Change legacy rando geth fork choice to be deterministic #871

Merged
merged 4 commits into from
Oct 19, 2023
Merged

Change legacy rando geth fork choice to be deterministic #871

merged 4 commits into from
Oct 19, 2023

Conversation

paulgoleary
Copy link
Contributor

Opening for discussion. ReorgNeeded is part of the legacy geth-based fork choice rules but I assume it's still what's used. If so, it has this strange coin-flip last tie breaker rule. Not sure how often this is fired but if it is it would contribute to unnecessary forks and re-orgs. Trivial and safe to change and does not require a HF.
Change was safe / successfully at previous company FWIW.

Description

Please provide a detailed description of what was done in this PR

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

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 mumbai
  • 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

@JekaMas
Copy link
Contributor

JekaMas commented May 19, 2023

Is it about selfish mining? http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf

@codecov
Copy link

codecov bot commented May 19, 2023 •
edited
Loading

Codecov Report

All modified lines are covered by tests ✅

Files Coverage Δ
core/forkchoice.go 75.00% <100.00%> (-5.00%) ⬇️

... and 684 files with indirect coverage changes

📢 Thoughts on this report? Let us know!.

@cffls
Copy link
Contributor

cffls commented May 19, 2023

Will this change enable validators to win a fork by mining blocks with lower hash value?

@paulgoleary
Copy link
Contributor Author

The history of this implementation is related to concerns about selfish mining / hash-grinding attacks. But it's important to note that it has always been the final 'tie breaker' after other fork choice rules have been applied, so difficulty still dominates the choice.
So with Bor (Clique-derived) consensus it's hard to see how a validator could gain an advantage by trying to game this. Since difficulty is always won by the primary, the only possible attack would be for a non-primary producer to somehow engineer a tie in difficulty and then grind out a lower hash to get their fork chosen.

@JekaMas
Copy link
Contributor

JekaMas commented May 22, 2023

It might be that yhis change willbe safe and useful after introducing finality.

@github-actions
Copy link

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Jun 15, 2023
@github-actions
Copy link

github-actions bot commented Jul 7, 2023

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Jul 7, 2023
@github-actions
Copy link

github-actions bot commented Aug 8, 2023

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Aug 8, 2023
@github-actions
Copy link

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Aug 30, 2023
@github-actions
Copy link

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Sep 26, 2023
@github-actions
Copy link

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Oct 18, 2023
@manav2401 manav2401 removed the Stale label Oct 18, 2023
@manav2401 manav2401 merged commit a9c5737 into develop Oct 19, 2023
12 checks passed
@manav2401 manav2401 deleted the poleary/change-rando-fork-choice branch October 19, 2023 07:26
@manav2401 manav2401 mentioned this pull request Oct 30, 2023
Merged
mh0lt pushed a commit to erigontech/erigon that referenced this pull request Nov 7, 2023
@manav2401
headerdownload: handle tie breaker for forkchoice in pow networks (#8616
97f00a1 
)

Based on maticnetwork/bor#871 in bor, this PR
handles import of same difficulty chains (tie breaker conditions) based
on their height and hash.

This PR also modifies an existing test to check different types of
side-chain import and how the canonical is decided.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pratikspatil024 pratikspatil024 pratikspatil024 approved these changes

@manav2401 manav2401 manav2401 approved these changes

@marcello33 marcello33 marcello33 approved these changes

@0xsharma 0xsharma 0xsharma approved these changes

@ssandeep ssandeep ssandeep approved these changes

@temaniarpit27 temaniarpit27 Awaiting requested review from temaniarpit27

@0xKrishna 0xKrishna Awaiting requested review from 0xKrishna

@cffls cffls Awaiting requested review from cffls

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@paulgoleary @JekaMas @cffls @ssandeep @0xsharma @marcello33 @manav2401 @pratikspatil024