Overview
Peers discover and connect to each other via ENRs (https://eips.ethereum.org/EIPS/eip-778). Discv5 is used to find new peers and their associated ENRs. Peers should store a subnet-bitfield representing the long-lived random subnets they are subscribed to. This allows one to search for and filter peers based on which long-lived subnets they are subscribed to.
Issue
Once a peer has found an ENR, they connect to other peers via tcp and negotiate libp2p protocols. A listening peer receiving the incoming connection has no mechanism to recover the ENR of the connecting peer. Therefore a client may have a number of connected peers, with no knowledge of their long-lived subnet subscriptions (which is useful information in deciding whether to search for more peers when a node needs to subscribe to a specific subnet).
Furthermore, a client listening and receiving a connection from a peer, cannot add that peer into its routing table and therefore doesn't add this peer to the DHT as it does not know the connecting peer's ENR.
Possible Solutions
1. Add the subnet bitfield to the STATUS message
In this solution, we simply add the bitfield to the RPC STATUS message. This solves the immediate problem of finding peer's long-lived subscribed subnets however only updates when either client initiates a STATUS. A peer could update their subnet bitfield and then may trigger a STATUS to all peers to inform them of the update.
This solution doesn't allow peers to add connecting peers to their local node table which is a feature we may want to improve the overall DHT and local routing table (especially for bootnodes).
2. Add a seperate RPC method for retrieving an ENR
In this solution we add a dedicated RPC method used to request/inform peers of an ENR/ENR-update. This method could be called by a node on connection to inform the listening peer of it's ENR. This method could also be used to update connected nodes when our local ENR is modified (including the subnet bitfield).
ENR's can be at most 300 bytes long and we may want to include additional information. Therefore the payload of this RPC method could include other information along with the ENR.
Overview
Peers discover and connect to each other via ENRs (https://eips.ethereum.org/EIPS/eip-778). Discv5 is used to find new peers and their associated ENRs. Peers should store a subnet-bitfield representing the long-lived random subnets they are subscribed to. This allows one to search for and filter peers based on which long-lived subnets they are subscribed to.
Issue
Once a peer has found an ENR, they connect to other peers via tcp and negotiate libp2p protocols. A listening peer receiving the incoming connection has no mechanism to recover the ENR of the connecting peer. Therefore a client may have a number of connected peers, with no knowledge of their long-lived subnet subscriptions (which is useful information in deciding whether to search for more peers when a node needs to subscribe to a specific subnet).
Furthermore, a client listening and receiving a connection from a peer, cannot add that peer into its routing table and therefore doesn't add this peer to the DHT as it does not know the connecting peer's ENR.
Possible Solutions
1. Add the subnet bitfield to the STATUS message
In this solution, we simply add the bitfield to the RPC STATUS message. This solves the immediate problem of finding peer's long-lived subscribed subnets however only updates when either client initiates a STATUS. A peer could update their subnet bitfield and then may trigger a STATUS to all peers to inform them of the update.
This solution doesn't allow peers to add connecting peers to their local node table which is a feature we may want to improve the overall DHT and local routing table (especially for bootnodes).
2. Add a seperate RPC method for retrieving an ENR
In this solution we add a dedicated RPC method used to request/inform peers of an ENR/ENR-update. This method could be called by a node on connection to inform the listening peer of it's ENR. This method could also be used to update connected nodes when our local ENR is modified (including the subnet bitfield).
ENR's can be at most 300 bytes long and we may want to include additional information. Therefore the payload of this RPC method could include other information along with the ENR.