Hi everyone! As the designer of the LES protocol I am really glad to see that some of you support adding my message format extensions to ETH64
@zsfelfoldi Thank you for coming up with these ideas! I enjoyed reading through them and thinking about how they would be used. Nice work!
I would also strongly suggest using my handshake message format which is a general key-value list allowing peers to communicate extra parameters and capabilities in an easily extendable way.
This is a good suggestion! This would be a general purpose way to accommodate the " Making Pruned State Explicit" proposal. I do think that there should be some mandatory fields, especially to address the networkId/chainId issue raised by @ajsutton. However, these mandatory fields can be moved to be mandatory keys.
The most complex addition of LES is the flow control mechanism which I believe has already been more or less proven to be useful but I am currently polishing it to truly show its potential. I would totally support making it available in ETH64 but on the other hand I do realize now that the way it is currently used in LES is probably also too strict and brittle.
I agree that “Consider Incorporating Client-side Flow Control” is something to have in the long-term. While it may not be there initially, the goal of the “Encapsulate Metadata as a Header Rather than Inlining Before Payload” is to make it easy to add metadata fields like this in the future.
Recently I had a very useful discussion with FrankSzendzielarz and he suggested adding a message similar to http 503 (temporarily unavailable) or 429 (too many requests) and sending that in case of a buffer underrun instead of instantly disconnecting.
This is an interesting idea! I wonder how this would work end-to-end. Would the message contain some information to help the almost-spammy peer know when it can begin sending messages again? It seems like there needs to be some explicit agreement set for what will help the almost-spammy peer’s behavior improve.
Having a common general protocol format would even allow us easily merging LES and ETH64 which was also suggested in this thread and which I would also support if done properly.
I was somewhat worried that " Folding LES into ETH" would be controversial. I’m glad to hear this is open for consideration.