A good first suggestion I would have for an RFC/PLIP would be the standardization of an SMT’s properties and structure. It’s been very difficult for me to try and suss out what a “vanilla” Sparse Merkle Tree is, so I’ve had to make a lot of decisions in my various implementations I’ve helped create in order to be maximally clear about how it works in practice.
See the following for examples:
- SMT helper functions and classes in Python trie library (GitHub)
- Vyper proposal for calculating SMT roots and empty branches (VIP)
This would be a very beneficial thing to specify, as it could enable easy interoperability and simplify implementations if we all agree on how it’s specified. Additionally, there have been a number of optimization/compression techniques people have applied for SMTs (denoting sparse branch points, etc.) that would be simpler to talk about with a common specification handy. My suggestion is to first specify what the un-optimized implementation looks like, and then specify different optimizations on top of that.
P.S. I’ve started working on various ways of updating proofs using broadcasts and event streams to make it easier and more efficient for clients to keep up with changes when they go offline.