-
Notifications
You must be signed in to change notification settings - Fork 281
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
discv5: transport pre-negotiation packet (LETSTALK) #83
Comments
If needed, we can add a protocol message like Regarding the secrets, I think the outputs of the handshake should NOT be reused in any way. It's fragile enough as-is. |
The need for this is now becoming more urgent since @zsfelfoldi wants to add pre-negotiation to les. Here's the use case: when a client finds a server, it needs to establish a TCP connnection and run the handshake only to find out that the provided service is too expensive or not enough capacity is available. Discovery should be able help with this issue by providing enough information to make an informed connectivity decision. With the LETSTALK packet from the previous comment, pre-negotiation would look as follows:
|
We might need a better name for this new packet pair, and a clearer definition of its semantics. |
This is more of a discussion starter / idea than a concrete proposal:
Although it's not yet documented, the discv5 spec seems to be evolving towards encrypted aes-gcm based communication, rather than obfuscation and recoverable signatures....
Assuming we get there, the following idea:
Regarding libp2p - other implementations that want to use libp2p for flexibility and interoperability could do so (eg: polkadot) - and they could be able to communicate with nodes that use such a mechanism as proposed above (???). Eth 2.0 will use discovery v5 anyway in all likelihood.
However, for implementations that want to deliver a single performance optimized method of networking that employs a common udp+tcp handshake, the discovery 'channel' (pardon the pun) and this aes-gcm encrypted communication would be all that was needed, as long as the transport was reliable. Which particular transport outside of TCP could in future be determined by ENR (eg: ETH = tcp 30303, http 80 etc)
Thoughts?
The text was updated successfully, but these errors were encountered: