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 #8004

Closed
thedevbirb opened this issue Feb 20, 2024 · 6 comments · Fixed by #8098
Closed

Explicit Peering Agreement implementation #8004

thedevbirb opened this issue Feb 20, 2024 · 6 comments · Fixed by #8098

Comments

@thedevbirb
Copy link
Contributor

Context

Teku implements the concept of a “trusted”/”static” peer, which guarantees the ability to always remain connected to a peer ignoring defensive measures such as peer scoring, however it provides no guarantees of being part of their mesh or to send/receive full messages from them unconditionally.

Why explicit peering agreement

Gossipsub v1.1 introduces the concept of "Explicit Peering Agreement", which is an agreement that must be reached from a pair of nodes in order to “remain connected to and unconditionally forward messages to each other outside of the vagaries of the peer scoring system and other defensive measures”.

This feature if enabled in Teku could allow nodes to explicitly connect to some relays networks such as Fiber or Bloxroute to boost the propagation of their blocks.

Possible implementation

Most of the work for supporting explicit peers (called "direct peers" in Teku and in jvm-libp2p) has been done in #3576. However, direct peers seem to be never assigned (I'd be happy to know I'm wrong). As such, there are only few things that needs to be done:

  • set them from the command line
  • allow them to be added and removed dynamically
  • exclude them from peer scoring or other defensive measures

Lastly this list of nodes needs to be passed to the libp2p implementation.

If there is interest, we can open a PR that implements this functionality.

@tbenr
Copy link
Contributor

tbenr commented Feb 21, 2024

Thanks for raising. We are evaluating it.

@mempirate
Copy link

Hello @tbenr, any questions we can answer to help with evaluation?

@mempirate
Copy link

mempirate commented Mar 8, 2024

We have implemented explicit peering agreements in Lighthouse as trusted peers:

If you agree with this approach, we'll open a PR that implements this. They can also be defined as an additional flag instead.

@tbenr
Copy link
Contributor

tbenr commented Mar 8, 2024

Hey, sorry for the delay. The only concern I have is this:
If direct peers are always part of node meshes, it is not necessarily true that we want to have static peers being direct peers too. Image you have a node with several static peers in several regions of the globe, you may want to have direct peers to be only co-located ones. So if my reasoning is true we may want to specify only a subset of static peers to be direct peers.

WDYT?

@mempirate
Copy link

I think that makes sense. In the context of Lighthouse they didn't want to introduce another CLI flag, which is why we went with this approach. If you agree, we can start drafting a PR that adds an --explicit-peers flag and related functionality in the networking stack.

@thedevbirb
Copy link
Contributor Author

Hey @tbenr, if you want you can check out a draft of what an implementation of this could look like in #8098. Let me know what you think! Thanks a lot.

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 a pull request may close this issue.

3 participants