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.

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

eth/downloader: only roll back light sync if not fully validating #21537

Merged
merged 1 commit into from
Sep 9, 2020

Conversation

karalabe
Copy link
Member

@karalabe karalabe commented Sep 9, 2020

Fixes #21505.

There is a notion of rollbacks during fast sync, where recent blocks that might not be clean are deleted from the database on a sync failure. This is needed to avoid attacks on fast sync since we're not running transactions.

For light sync however, rollbacks are pointless because there's no batch of full blocks imported on top to validate them. As long as the PoW checks out, light clients will take the node's word for it.

This PR disables the rollback mechanism for light syncs, which was causing crashes in the light txpool due to deleting headers that it imported before. Interestingly, the issue was that the rollback mechanism wasn't disabled after initial sync (opposed to fast sync switching to full sync).

@karalabe karalabe added this to the 1.9.22 milestone Sep 9, 2020
@@ -1501,18 +1501,20 @@ func (d *Downloader) processHeaders(origin uint64, pivot uint64, td *big.Int) er
rollbackErr = err

// If some headers were inserted, track them as uncertain
if n > 0 && rollback == 0 {
if (mode == FastSync || frequency > 1) && n > 0 && rollback == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't it be frequency==1 ? Why do we add rollbacks only when the header check is every N:th block, but not when it's every block?

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, if it checked every block, there's nothing to roll back. We should only roll back if we checked every 24th block for PoW, since we don't know if the previous ones were valid or not

Copy link
Member

Choose a reason for hiding this comment

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

If we pass the pivot point, the frequency is 1. In this case, we don't need to rollback?

what about this:

if frequency > 1 && n > 0 && rollback == 0 {

Copy link
Member

@rjl493456442 rjl493456442 left a comment

Choose a reason for hiding this comment

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

LGTM

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.

Panic on reorgOnNewHead
3 participants