RGB protocol versioning / features

[dr-orlovsky]

(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)

[dr-orlovsky]

After discussion with @giacomozucco @fedsten @sabina-sa it was decided to accept this change

[UkolovaOlga]

Comments from the discussion

S> When the protocol is upgraded with new features, asset ‘brands’ that want to use these features will have to issue their assets anew. So, for example, there might be two versions of e.g. Tether at the same time: the old one and the new one.
Some brands will allow these two version of assets, old and new, to circulate simultaneously. Other brands will want to cancel the old assets and work with the new ones, i.e. to “migrate”. Of course, they cannot cancel the contracts in code, but they can do it by declaring legally that old assets are no longer their responsibility. ERC20 projects are doing that all the time, and give a limited time for asset owners to migrate to a new contract.
I assume that there will be user demand for having a conversion process (audit? automatic process?) between asset versions. So that existing, important properties of the old contract, like “no reissue”, are not affected by migration to a new version of asset with the new contract.

So, I think it is important to keep track whether some new features (like introducing Simplicity or Mimblewimble) can somehow “break” the logic of the old schemas, in the case that a new contract keeps everything from the old contract, with addition of these new features.

M> Correct. Still, upgrading existing assets/contracts is not as difficult of an issue compared to adding new functionality to RGB new contracts over time, so the protocol could evolve.

Regarding keeping track on whether new features affect the logic of old SCs. (1) This will be happening anyway regardless the RGB versioning (even if we prohibit it; some bugs may be found while RGB will have no option to upgrade, but the market will invent some “unnatural way” of marking upgrade and will go through the process you describe anyway), (2) which kind of audit is required — it’s up to issuers, owners and the market to decide, right?

S> Sure, audit and related activities are up to the market to decide, but if the assets migrate often and e.g. the process has some known difficulties, it also becomes blamed on the protocol. So maybe it would be easier to prevent the most obvious user mistakes / misunderstandings. Probably that could be done by careful creation & description of the new versions of schemas, so that it becomes obvious if the new version of contract follows the old one, or creates a twist/loophole.
Also, since contracts do not interact with each other, it looks to me that new contract creation should be safe.

M> Schemas can be created by anybody, there is no central authority to decide. As an LNP/BP Association we will propose schemas to start with, but it may be the case when somebody will propose a better fungible asset schema and ours will not get traction.

So what we can do is to create guidelines for schema creation, review (including “don’t trust, verify your schema you are using assets from”), and this can be made under the name of the Association.

Anyway, now we need to understand if there are any possible attacks via this versioning system other than social engineering/fishing, which will always be possible in one way or another

.

F> So if I understood correctly the reasoning being this is that in a client validated model it would be easier to scam an old node making him think that something invalid under v2 rules is actually valid, while on a blockchain an attacker needs to fool also the block producer, making the cost of attack higher (and therefore we can let coins mined in 2009 move to P2SH and segwit outputs). Is that correct or there are other motivations behind this choice?

M> With the discussed proposal it will remain at the same level of impossibility as before; nothing changed here. What we had before is the inability to upgrade protocol for any new contract, that is the topic of the proposal

.

F> So, this proposal will apply only to new contracts and not also to old ones, which would be more reckless but would avoid the need for a re-issuance of the asset that wish to upgrade to a new version

.

M> In RGB, contracts do not interact with each other, they are 100% independent. This is very different from any other system (LN, blockchain). So there is nothing like “RGB network” or “RGB chain”: a contract IS a chain (DAG), but two contracts are not linked (they were before, but with anchor introduction, they are not anymore). So, when the system was designed and there were no anchors, it was not possible to upgrade, since the DAG of one contract could be interconnected with the other, which is not the case any more.

Second, addressing your question, why not to do the same within a contract, the answer is more complicated. It all comes down to the following: if you upgrade a contract without an issuer, you have no guarantee that future owners will accept this upgrade; and it will destroy the fungibility property. If the upgrade is managed by the issuer, it’s easier (and much safer/cleaner) to do a new contract + migration, instead of trying to embed upgrade functionality inside the contract.


F> I agree that it would be problematic to let the users upgrade the tokens they hold but for a different reason. The fact that future payee may not accept it, is a risk that is up to the user to take, so part of a market dynamic (which is the same risk as migrating the new USDT contract when there is still low usage). I think the real issue is that if we have a soft fork-like upgrade, a v1 user may accept a transaction that respects the v1 rules but not the v2 rules (due to some anyone-can-spend mechanism), making him unaware that when he would spend the token to a future v2 payee such transaction will be considered invalid.

Anyway, this issue seems to apply only to same contract tokens, with v2 new contract it should indeed be fine as new token is not considered fungible by anyone with the old tokens, but I will think more about that if there may be other less obvious complications.