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

v2.0: excludes node's pubkey from bloom filter of pruned origins (backport of #2990) #3015

Merged
merged 1 commit into from
Sep 30, 2024

Conversation

mergify[bot]
Copy link

@mergify mergify bot commented Sep 27, 2024

Problem

Bloom filter of pruned origins can return false positive for a node's own pubkey but a node should always be able to push its own values to other nodes in the cluster.

Summary of Changes

Excludes node's pubkey from bloom filter of pruned origins


This is an automatic backport of pull request #2990 done by Mergify.

@mergify mergify bot requested a review from a team as a code owner September 27, 2024 20:30
Bloom filter of pruned origins can return false positive for a node's
own pubkey but a node should always be able to push its own values to
other nodes in the cluster.

(cherry picked from commit bce28c0)
Copy link

@gregcusack gregcusack left a comment

Choose a reason for hiding this comment

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

lgtm!

@bw-solana
Copy link

Is the potential problem here that a node won't push its own values because of a false positive in the bloom filter indicating we pruned this pubkey? And thus, the cluster will have stale values for this node unless they explicitly pull the values?

@gregcusack
Copy link

gregcusack commented Sep 28, 2024

Ya when a node gets a CrdsValue, it will check in its push active set which peers it can send this value to. Each peer in the push active set has a bloom filter associated with it. If the origin of the CrdsValue appears in the bloom filter of the peer, the node will not send the CrdsValue to that peer (that peer has pruned the node for messages originating from the CrdsValue's origin).

So yes, there is a chance that when a node has a CrdsValue it created, the node's own pubkey shows up in the bloom filter for one or more of its peers in the push active set. As a result, the node would not push its own value it created out into the network.

And yes peers would have to explicitly pull these values from the origin node. That's assuming there were only false positives in the push active set.

@behzadnouri behzadnouri added the automerge automerge Merge this Pull Request automatically once CI passes label Sep 30, 2024
Copy link

@bw-solana bw-solana left a comment

Choose a reason for hiding this comment

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

Couple minor suggestions, but I'm okay pushing it

// If true forces gossip push even if the node has pruned the origin.
mut should_force_push: impl FnMut(&Pubkey) -> bool + 'a,
) -> impl Iterator<Item = &Pubkey> + 'a {
let pubkey_eq_origin = pubkey == origin;

Choose a reason for hiding this comment

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

I like the idea of naming this something like pushing_my_own_value

gossip/src/push_active_set.rs Show resolved Hide resolved
@mergify mergify bot merged commit 3aa2c0a into v2.0 Sep 30, 2024
39 checks passed
@mergify mergify bot deleted the mergify/bp/v2.0/pr-2990 branch September 30, 2024 15:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge automerge Merge this Pull Request automatically once CI passes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants