feat(discv5): add crate for interfacing reth network and sigp/discv5

[emhane]

• Makes sigp/discv5 usable in reth network by implementing minimal interface HandleDiscovery.
• Parses enodes into multiaddresses (used by CL) that can be added into sigp/enr via public api.
• Exposes sigp/discv5 api for filtering queries with custom filters, to narrow down lookup queries. this is necessary since mostly eth2 peers are found on discv5 rn. populating kbuckets with eth2 nodes will lead to almost inability to find EL peers if kbuckets become full, since by Kademlia, kbuckets favour long lived connections - this means it will keep the first nodes it puts in its buckets if those nodes stay online.

[Rjected]

I'm still a bit confused by the downgrade logic, why do we have to include discv4 in this discv5 logic? It seems to make everything more complex, and I'm not sure what the benefit is

[Rjected]

so opstack actually includes this key in enrs?

[emhane]

some yeah, for example

2024-03-22T11:29:19.139714Z TRACE net::discovery::discv5: discovered peer on opstack fork_id=None enr=Enr { id: Some("v4"), seq: 1708293705211, NodeId: 0x8aa3a341cc388b03310b4b13f641722dd2bf0d6a992c1a9bf984489674ef4876, signature: "98ac9fdef036164e4566b84efea47b3f6944f96d8bbef0026830d27346f4253e4731288dddbe4af11dfd5481cfcb6ebc71a56c83dd931a547e7da0a1b75b6a21", IpV4 UDP Socket: Some(78.153.130.198:9222), IpV6 UDP Socket: None, IpV4 TCP Socket: Some(78.153.130.198:9222), IpV6 TCP Socket: None, Other Pairs: [("opstack", "85f1dbda0300"), ("secp256k1", "a1031b9dda693d646e1dabff64e3140c65afeb9c16c6847d40ce8f8936e6b347d496")] }
2024-03-22T11:29:19.140715Z TRACE net::swarm: adding new peer to network peer_id="0x1b9d…4d41" socket_addr=78.153.130.198:9222 fork_id=None

not 100% sure if its fork id, or smthg else?

[Rjected]

hmmm, yeah probably a forkid / forkhash

[emhane]

but maybe only for base?

[emhane]

blocked by #7328, missing TryFrom<Enr> impl

[mattsse]

few more nits

[emhane]

the uint, why are we defining new uint types?

because I copied a module from sigp/discv5, because I didn't want to invent smthg new to test the code, i wanted to use code that is used in production and is heavily audited. it's just a dev dep so I'm hoping it doesn't disturb you.

then this function should be pub crate

related to the point above, if libraries would just make functions public, code would seldom have to be copy pasted. I'm relecetuant to restrict visibility since I don't know in what way users may want to use reth, and want it to be as fun as possible for them. an inaccessible function doesn't spark joy.

they get all sent to the same service.
doing this on separate tasks is unnecessary.

yes, but they only get sent when the preceding query finishes if not spawned on separate threads. I can poll the futures concurrently on the same thread if you prefer.

[Rjected]

the uint, why are we defining new uint types?

because I copied a module from sigp/discv5, because I didn't want to invent smthg new to test the code, i wanted to use code that is used in production and is heavily audited. it's just a dev dep so I'm hoping it doesn't disturb you.

let's remove the construct_uint call and use our U256, because Key logic is more important wrt testing imo

[emhane]

the uint, why are we defining new uint types?

because I copied a module from sigp/discv5, because I didn't want to invent smthg new to test the code, i wanted to use code that is used in production and is heavily audited. it's just a dev dep so I'm hoping it doesn't disturb you.

let's remove the construct_uint call and use our U256, because Key logic is more important wrt testing imo

alright sure, how do I do this with our type (need to re-write the copied sigp module so I can run the test)?

let a = U256::from(self.hash.as_slice());

[Rjected]

the uint, why are we defining new uint types?

because I copied a module from sigp/discv5, because I didn't want to invent smthg new to test the code, i wanted to use code that is used in production and is heavily audited. it's just a dev dep so I'm hoping it doesn't disturb you.

let's remove the construct_uint call and use our U256, because Key logic is more important wrt testing imo

alright sure, how do I do this with our type (need to re-write the copied sigp module so I can run the test)?

let a = U256::from(self.hash.as_slice());

let's use U256::from_be_slice

[mattsse]

I think this is a great standalone service and this should give us everything we need for reth-network

lgtm, pending @Rjected

[Rjected]

LGTM! this should unblock a lot of things