Thank you everyone for your contributions! There are a lot of great ideas here.
I want to take a moment to establish the scope of ETH v64:
- Protocol warts: remove glaring holes, ambiguity, technical in current ETH v64 protocol (possibly at the RLPx wire level)
- Synchronization: make it easier to write synchronization code
- State: make client state more apparent amongst peers (e.g. archive vs. full) and even reduce data transferred (receipt bloom filters I’m looking at you)
Over the next few days I’m going to draft “minimum viable EIPs” for the ideas that seem like can be candidates for ETH v64. Each of these EIPs will have proper attribution to those who proposed it. I will ping either author to drive it hence forward unless they are not interested. That is not to say the ideas I do not draft into EIPs are not worthwhile, I just do not see them within the immediate scope of the three goals for ETH v64 mentioned above.
Let mebe explicit that amongst my proposals on here I only consider myself an author of Making pruned state explicit as the others are previously established ideas from prior works.
The next step is then getting client implementor buy in. This seems to be the right place to get consensus because (1) they are the implementors and (2) this is so low-level that other stakeholders higher in the stack will not even notice.