Delete expensive chain compatibility checks in check_peer_relevance #7056
Conversation
This file contains 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
pawanjay176
force-pushed
the
cheap-status-check
branch
from
33870c1 to
d5e5d18
Compare
|
This pull request has merge conflicts. Could you please resolve them @dapplion? 🙏 |
pawanjay176
force-pushed
the
cheap-status-check
branch
from
d5e5d18 to
bcedb76
Compare
pawanjay176
reviewed
Feb 27, 2025
| match remote.finalized_epoch.cmp(&local.finalized_epoch) { | ||
| // This peer has a finalized epoch less than ours. This peer is likely to not be | ||
| // useful to us, as they want to sync from us. As a nice gesture, we could do work | ||
| // from them and check if their finalized_root matches our imported chain. |
There was a problem hiding this comment.
Suggested change
| // from them and check if their finalized_root matches our imported chain. | |
| // for them and check if their finalized_root matches our imported chain. |
| // However, this check is unncessary, as if we are incompatible the peer will be | ||
| // eventually disconnected anyway. Consider the two cases: | ||
| // | ||
| // - Peer is our chain: we should forward peer to sync to allow them to sync from us |
There was a problem hiding this comment.
Suggested change
| // - Peer is our chain: we should forward peer to sync to allow them to sync from us | |
| // - Peer is on our chain: we should forward peer to sync to allow them to sync from us |
| )) | ||
| } | ||
| } | ||
| // Peer claims to know about a finalized checkpoint ahead of hours. Send peer to |
There was a problem hiding this comment.
Suggested change
| // Peer claims to know about a finalized checkpoint ahead of hours. Send peer to | |
| // Peer claims to know about a finalized checkpoint ahead of ours. Send peer to |
| } | ||
| } | ||
| // Out of bounds root check, allow the peer to connected to us and expect | ||
| // they to disconnect or be disconnected if we are in incompatible chains |
There was a problem hiding this comment.
Suggested change
| // they to disconnect or be disconnected if we are in incompatible chains | |
| // them to disconnect or be disconnected if we are in incompatible chains |
| )) | ||
| } | ||
| } | ||
| // Out of bounds root check, allow the peer to connected to us and expect |
There was a problem hiding this comment.
Suggested change
| // Out of bounds root check, allow the peer to connected to us and expect | |
| // Out of bounds root check, allow the peer to connect to us and expect |
| // chain. | ||
| if self | ||
| .chain | ||
| .block_root_at_slot(remote_finalized_slot, WhenSlotSkipped::Prev) |
There was a problem hiding this comment.
If this check is indeed cheap, I would prefer to keep it as it would cause make it harder for peers to sync in a chaotic network if we remove this.
I do not have a sense of how cheap this is though.
There was a problem hiding this comment.
It's very cheap, reading a single block root from the freezer is fast (<3ms)
|
Closing as not required, but feel free to reopon |
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.
Issue Addressed
Extends #5481 not to do any DB reads when processing status messages. These have proven to be very expensive during the Holesky incident
Proposed Changes
I added extensive comments to justify the changes, please check those :)
A working solution that doesn't read anything from the chain is 92a3936. Then 33870c1 covers a bit more ground by using the existing cached head which should be free