Forming a Ring: ETH v64 Wire Protocol Ring

eth-v64-wire-protoco

#21

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 :slight_smile:

@zsfelfoldi Thank you for coming up with these ideas! I enjoyed reading through them and thinking about how they would be used. Nice work! :clap:

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.

:heart::heart::heart: I was somewhat worried that " Folding LES into ETH" would be controversial. I’m glad to hear this is open for consideration.


#22

One idea that could simplify peer management is to add messages for requesting chain state information. Peers initially report their chain’s best hash and total difficulty via the Status message, but keeping up-to-date stats on peers is otherwise somewhat indirect.

Some possible request / response messages:

  • GetChainState()
  • ChainState(blockHash, blockNumber, totalDifficulty)

And it may also be useful to verify total difficulty claims by querying other peers with:

  • GetTotalDifficulty(blockHash)
  • TotalDifficulty(blockHash, totalDifficulty)

#23

@matthalp here is the proposal I promised:


#24

Great! I will review and comment there.


#25

@mbaxer I think it makes a lot of sense to have explicit chain state request/responses instead of relying on receiving the NewBlock/NewBlockHashes methods from peers. It’s also worth noting that chain state updates changes from a pub-sub type model to a polling model. There are some slight trade-offs here but a client typically communicates with at most 25 peers at a time, so there probably isn’t the scale to make any of the trade-offs notable.

The total difficulty messages are also interesting, but I have to think that through more. This morning I was wondering why headers don’t just include total difficulty instead of just the difficulty at that block, which may also solve some of the issues here (and it’s sealed in the header).