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

Investigate/peering #582

Closed
wants to merge 6 commits into from
Closed

Investigate/peering #582

wants to merge 6 commits into from

Conversation

meowsbits
Copy link
Contributor

@meowsbits meowsbits commented Nov 2, 2023

Reports like #567 and others in other channels (mostly Discord) suggest some kind of vague issue with peering. This is a WIP to explore the problem and potential solutions.

@ziogaschr
Copy link
Member

@meowsbits what do you think of merging this PR and start using the snap DNS list?

I thought this used to exist, but
I don't see logs around bootnodes/discovery
config anymore, so I'm adding them
because I like verbose logging.

Date: 2023-11-02 17:01:51-06:00
Signed-off-by: meows <[email protected]>
We have all.classic.blockd.info AND
snap.classic.blockd.info, so let's use
both of them in reasonable places.

Date: 2023-11-02 17:02:45-06:00
Signed-off-by: meows <[email protected]>
Snap imports should happen below the pivot,
and full import above the pivot.
Normally, blocks are like 18M high
and pivot blocks only a few (ie 128 blocks)
below the chain head.

In a special case, though,
a peer can have a full block > 0 but < 128,
say, 2 blocks, and we can try to sync from them.
When doing so, our pivot will be at 0,
and as such, the delegation fn splitAroundPivot
will separate blocks AFTER the pivot (0) for
FULL import, while blocks before the pivot --
which normally should be SnapImported --
are none, and so all blocks above 0 are
imported with importBlockResults rather
than commitSnapSyncData.

This results in block 2 being considered (or marked) FULL
at the blockchain level.
Snap sync (as implemented) does not expect FULL
blocks below the pivot, so it should be confused
about whether its snap-syncing or full-syncing.

Then, when and if rollbacks happen (eg b/c bad sync),
it might be that the rollback under snap parameters
does not adequately rollback those full-imported
low blocks.

Date: 2023-11-03 12:48:02-06:00
Signed-off-by: meows <[email protected]>

eth/downloader: fix logic from last commit (bad return broke loop)

Date: 2023-11-03 14:16:53-06:00
Signed-off-by: meows <[email protected]>

eth/downloader: fix redundant condition (noop)

Date: 2023-11-04 08:17:33-06:00
Signed-off-by: meows <[email protected]>
A checkpoint condition exists to prevent
snap sync with peers having heads less
than the checkpoint.

ETC does not have checkpoints installed,
so this is a noop.

This patch adds a condition to prevent
snap sync with peers reporting heads
less than fsMinFull blocks to prevent
edge case badnesses around rollbacks
and pivot handling when the target
peers has very low blocks (eg. 2).

Date: 2023-11-06 09:15:50-07:00
Signed-off-by: meows <[email protected]>
This reverts commit 86f11f11167f54119fe0f7a294f1cf14c7be778e.
By installing a checkpoint we'll avoid
some snap sync issues where we're attempting
to sync with very low, unsynced, nodes
and running into issues with pivoting to
full sync too early because of that (or
encountering bugs related to aborted sync rewinds).

The current block number is 18_666_111, so
the checkpoint block 18_186_239 is well
below that; safely canonical.

I just derived the checkpoint values
manually, though if we get the les client
or server working again we can theoretically
use the API les.latestCheckpoint.

Date: 2023-11-06 11:03:47-07:00
Signed-off-by: meows <[email protected]>
@meowsbits meowsbits force-pushed the investigate/peering branch from 9bdf2fa to ec42a29 Compare February 6, 2024 19:14
@meowsbits
Copy link
Contributor Author

meowsbits commented Feb 6, 2024

Thanks for the bump on this. I just rebased on master and pushed. There were 4 subsequent commits that I hadn't pushed, but now have. I'd like to freshen up on what's going on here and then I'll come back to ya, especially since it seems like we've addressed probably the brunt of the peering issues with your #611.

@ziogaschr
Copy link
Member

We can close this one I think

@meowsbits meowsbits closed this Jun 12, 2024
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.

2 participants