Discv5 support #3517
Discv5 support #3517
Conversation
gerceboss
commented
Jul 29, 2025
gerceboss
commented
- Clean structure
- Better config for discovery and ability to handle both v4 and v5
| bindIp = bindIp, | ||
| enrAutoUpdate = enrAutoUpdate, | ||
| rng = rng | ||
| ) | ||
|
|
||
| proc receiveV5*(d: Protocol, a: Address, packet: openArray[byte]): Result[void, cstring] = |
There was a problem hiding this comment.
I think we need to port this function receiveV5 to nim-eth
There was a problem hiding this comment.
Do we want to directly use the nim-eth inside receiveV5 function or rewrite it according to nim-eth's receive ?
There was a problem hiding this comment.
nim-eth's receive return no error, only print logs. So we need to make it return error.
gerceboss
force-pushed
the
feat/add-discv5
branch
from
4cc54d4 to
d90b462
Compare
| discv5_network_bytes.inc(packet.len.int64, labelValues = [$Direction.In]) | ||
|
|
||
| let packet = ?d.codec.decodePacket(a, packet) | ||
| let decoded = d.codec.decodePacket(a, packet) |
There was a problem hiding this comment.
@jangko Something like this , correct? We can reuse DiscResult from discovery v4 but will need to have some common file for them, then the ones specific to their functionalities and variables.
There was a problem hiding this comment.
Generally we want to share from discovery V5 to V4, not the other way around.
What I mean by porting receiveV5, the one in nim-eth should be fixed, so we don't have two copies of receive proc.
And discovery v5 designed to accept external shared stream transport, and don't have to open it itself.
Same with discovery V4.
There was a problem hiding this comment.
@jangko ,So how should I proceed in this repository for now? update implementations in nim-eth?
There was a problem hiding this comment.
Having that code duplication in the current solution of discv5 integration (with discv4) is definitely a bit ugly and not great for maintainability.
I've been wanting to add some other discv5 init calls to the API to be able to pass in an already created transport. This being mostly needed for Portal, but would be useful also for this double discv4/discv5 on same UDP port use case.
