Plasma Improvement Proposals or RFCs

#1

I’d be for creating an RFC repository or a Plasma Improvements Proposal repo, hosted under some neutral github organization. It is high time we started standardizing Plasma specifications. This will clearly take some time, but I’d like this to get to a point where each time somebody proposes a variant, they reference a previous spec, along with a list of changes to be made.

References:


#2

+1 to this. Would be great to have a standardized way to propose new features and a place to discuss them.

I’m generally hoping that a system like this could be used to develop a really great generalized plasma specification that can run on top of any flavor of plasma.

#3

+1 and petition to call them PLIPS

#4

It sounds good. I think it will help Plasma progress in a more concrete way.

#5

+1, great idea @gakonst

#6

Let’s do it then.

Given that PG is a non-profit, using their github to host such repositories along with code that can be reused across implementations could be a good idea.

However, I’d generally prefer that it is a neutral github, any name recommendatins?

https://github.com/plasma is occupied, wonder if we could persuade that person to change their handle…

#7

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:

  1. SMT helper functions and classes in Python trie library (GitHub)
  2. 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.