Add GetENR

[wemeetagain]

• Add MetadataV3 with custody_subnet_count #3821 (comment)

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

• Add MetadataV3 with custody_subnet_count #3821 (comment)

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]

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]

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]

@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]

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.

[ppopth]

But Discv5 also supports arbitrary req/resp and can support applications built on top, portal is an example of this.

If it's used for applications, why do those applications want to know the ENR of the CL's peers rather than finding new peers?

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.

Capabilities are not mapped to MetaData. I don't see it anywhere, or I missed anything?. What I see is only attnets and a couple things more.

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.

But in this PR you put it in the req/resp section which is a core part of the CL, that doesn't seem like a supplemental part at all.