-
Notifications
You must be signed in to change notification settings - Fork 987
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
base: dev
Are you sure you want to change the base?
Add GetENR #3861
Conversation
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. |
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. |
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 |
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).
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. |
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.