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

Add GetENR #3861

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

Add GetENR #3861

wants to merge 1 commit into from

Conversation

wemeetagain
Copy link
Contributor

I do wonder however why there is no GetENR among the req/resp messages.

For peers who have dialed us, we won't have discovery port information, so can't easily query the peer's discv5 for its ENR.

While not necessary for current beacon node functionality, GetENR provides a direct way to connect inbound p2p peers via discv5.

This protocol is likely fairly cheap to implement and maintain, and it is quite limited in the bandwidth it consumes.
It can be treated as an optional protocol (similarly to light client protocols) since it is not needed to maintain consensus or network stability.

@ppopth
Copy link
Member

ppopth commented Sep 18, 2024

GetENR provides a direct way to connect inbound p2p peers via discv5.

Sorry for the late reply.

I assume that the inbound peers you are talking about are behind NAT. How can peers behind NAT have the ENR and be on Discv5?

IIUC, currently we don't have any kind of hole punching yet.

@wemeetagain
Copy link
Contributor Author

I assume that the inbound peers you are talking about are behind NAT.

No, this is for the case where a peer dials you, and you want to communicate with it via discv5/portal.

Without GetENR, you don't have enough info to connect via discv5. You can derive the node id, you know the IP, but you don't know the port that the peer's discv5 is running on. And there is no reliable way to determine that port.
With GetENR, you can get the peer's ENR. The ENR contains the discv5 port, but really the ENR can just be passed directly into your discv5/portal instance.

@ppopth
Copy link
Member

ppopth commented Sep 20, 2024

@wemeetagain

You can derive the node id, you know the IP, but you don't know the port that the peer's discv5 is running on

Alright, got it.

Why do you want to talk to them in Discv5? Discv5 is used for node discovery only. It's like you don't need to do any node discovery in this case.

My concern against this PR is that we treat Discv5 as a supplementary component rather than a core component. That is, when someone wants to launch a new Ethereum network but doesn't want to use Discv5 as a node discovery mechanism, they wouldn't be able to do that because they still need to answer to the GetENR requestes.

@wemeetagain
Copy link
Contributor Author

Why do you want to talk to them in Discv5? Discv5 is used for node discovery only. It's like you don't need to do any node discovery in this case.

Yes node discovery is not needed here. But Discv5 also supports arbitrary req/resp and can support applications built on top, portal is an example of this.

The ENR may also be useful on its own.

It is used to advertise node capabilities. The consensus-relevant capabilities are mapped to the MetaData protocol, but this is a more permissionless (not needing to be updated/coordinated via fork) mechanism to retrieve node capabilities, and has the additional feature of being self-signed.

It may also be useful for diagnostic purposes (eg: to return in the node/peers beacon API endpoint).

treat Discv5 as a supplementary component rather than a core component

Yes I agree here. I would view this protocol also as supplemental and not required. If a node does not use discv5, then this protocol would not be handled/supported by that node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants