RGB protocol versioning / features

(updated)

I think the best way for RGB versioning is to have LN-like set of features, with even/odd differentiation, and commit to it in a Schema.

This version will define not the Schema version, but version of RGB protocol as a whole, i.e. how the schema data and all smart contract data issued under this schema will be serialized and interpreted. This will allow RGB updates such as addition of Simplicity language etc.

With a client-side validation we _prohibit_ to change anything in terms how protocol works (commitment rules, validation rules etc) once the contract is created. But RGB a sa whole is a set of absolutely unrelated contracts, so I understood that while a single contract can’t be “upgraded”, nothing prevents in a client-validated paradigm to have protocol versioning/features for different contracts, so new contracts can be created under RGBv2 for instance (providinb mimblewimble aggregation/whatever)