-
Notifications
You must be signed in to change notification settings - Fork 292
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
Comments
Thanks for raising. We are evaluating it. |
Hello @tbenr, any questions we can answer to help with evaluation? |
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. |
Hey, sorry for the delay. The only concern I have is this: WDYT? |
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 |
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:
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.
The text was updated successfully, but these errors were encountered: