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

Explicit Peering Agreement implementation #13773

Merged
merged 1 commit into from
Mar 29, 2024

Conversation

thedevbirb
Copy link
Contributor

@thedevbirb thedevbirb commented Mar 20, 2024

What type of PR is this?

Feature

What does this PR do? Why is it needed?
This PR enables Gossipsub v1.1 "Explicit Peering Agreement as discussed in #13635

Which issues(s) does this PR fix?
Closes #13635

Other notes for review
Explicit peers (called "direct" in the codebase, to follow go-libp2p-pubsub convention) are considered also "static" in order to connect with them at startup and persist the connection with them. Then, the peers specified in the CLI option are just passed downstream to pubsub configuration.

@CLAassistant
Copy link

CLAassistant commented Mar 20, 2024

CLA assistant check
All committers have signed the CLA.

cmd/flags.go Outdated
}
// DirectPeers specifies a set of peers to connect to for "Explicit Peering Agreement"
// Reference: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#explicit-peering-agreements
DirectPeers = &cli.StringSliceFlag{
Copy link
Member

Choose a reason for hiding this comment

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

this flag is not necessary. The -peer flag means the same thing here as we only specify trusted peers there(those not penalized/disconnected with). Making them a direct peer of our mesh is a logical next step.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see! I added another flag because maybe you wanted to distinguish between "static" and "explicit". For instance, Teku keeps this separation (Consensys/teku#8004 (comment)), while Lighthouse doesn't.

If you want to proceed with making the -peer flag configuring direct peers, I'll update my PR accordingly soon!

Copy link
Member

Choose a reason for hiding this comment

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

In prysm, this peer is assumed to be trusted:
https://github.com/prysmaticlabs/prysm/pull/13773/files#diff-e231d920accff9e68d1581fc082513cda53631f2a312c9005448288b29dd08a3R97

So its fine to make them direct too for us. There isn't much benefit to differentiating them with different flags.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've made some changes in order to configure static peers as direct in the pubsub options. I hope it is good now. Thank you!

@thedevbirb thedevbirb force-pushed the feat_explicit_peers branch 2 times, most recently from 64b5511 to dbf69ed Compare March 25, 2024 15:43
@thedevbirb thedevbirb marked this pull request as ready for review March 25, 2024 15:45
@thedevbirb thedevbirb requested a review from a team as a code owner March 25, 2024 15:45
if err != nil {
log.WithError(err).Error("Could not convert static peers raw ENRs into multiaddresses")
return
}
Copy link
Member

Choose a reason for hiding this comment

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

If 0 valid addrs are returned from PeersFromStringAddrs, we should log an error/warning and exit early

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've just added a warning log! Thank you

@thedevbirb thedevbirb force-pushed the feat_explicit_peers branch from dbf69ed to 9fc5d31 Compare March 27, 2024 08:16
nisdas
nisdas previously approved these changes Mar 27, 2024
Copy link
Member

@nisdas nisdas left a comment

Choose a reason for hiding this comment

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

Thanks !

@nisdas
Copy link
Member

nisdas commented Mar 27, 2024

You have lint failures:

compilepkg: nogo: errors found by nogo during build-time code analysis:
beacon-chain/p2p/pubsub.go:180:2: ineffectual assignment to "psOpts" (ineffassign)
beacon-chain/p2p/pubsub.go:180:2: this value of psOpts is never used (SA4006)

return psOpts
}

// addDirectPeersOption parses the static peers from the service configuration and adds
// the direct peers option to the pubsub options.
func (s *Service) addDirectPeersOption(psOpts []pubsub.Option) {
Copy link
Member

Choose a reason for hiding this comment

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

You will need to return the opts, as it becomes a different slice below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry for that! I've written very few lines of Go code so far :). I thought psOpts was passed by reference. Now I've enforced it and the underlying data should be modified.
Tried to run golangci-lint locally and seems good now

@thedevbirb thedevbirb force-pushed the feat_explicit_peers branch 2 times, most recently from 9c59203 to a22b2fd Compare March 27, 2024 09:12
return
}

*psOpts = append(*psOpts, pubsub.WithDirectPeers(directAddrInfos))
Copy link
Member

Choose a reason for hiding this comment

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

This isn't the standard way its usually done in go. To make this more readable can you return psOpts in the method ? so that it is clear what is the argument to the method and what is its output.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm sorry again! I think I've simplified the logic a bit by moving the parsing of raw ENRs into a separate function. I hope it is idiomatic Go code now. Thanks for the patience

Copy link
Member

Choose a reason for hiding this comment

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

No worries, it looks good to me now

@thedevbirb thedevbirb force-pushed the feat_explicit_peers branch from a22b2fd to 908046b Compare March 27, 2024 13:20
@nisdas nisdas added this pull request to the merge queue Mar 29, 2024
Merged via the queue into prysmaticlabs:develop with commit 5b1da73 Mar 29, 2024
17 checks passed
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.

Explicit Peering Agreement implementation
3 participants