LNPBP-11, 12, 13: RGB public state transitions

[dr-orlovsky]

Right now only parties owning some of RGB contract state (i.e. able to spend an UTXO with some assigned RGB state data, i.e. close a seal over next state) can update the state with state transitions. While this is very strong "anarcho-capitalistic" smart contract system, there are cases when independent third parties should be able to modify/interact with smart contract, for instance "decentralized issuance" (which can be used in bitcoin-backed RGB bitcoin derivatives, when anyone in the world can lock some bitcoins to some pre-defined Miniscript template-based UTXO and produce RGB asset). However, in order to have these assets interoperable (and issuance being decentralized) we need all these actions to happen under some single genesis, whence anyone can extend smart contract history after genesis with this issuance procedure.

Here I propose how this can be achieved with a simple RGB modification, which adds a lot of new use cases to the core of RGB (like "call a method of RGB smart contract").

First, we introduce that genesis and state transitions, additionally to state assignments with single-use seals, may contain (if Schema allows) a vector of so-called opened valencies. Each opened valencies is a "public extension point" of some Schema-defined type: it is not linked to any UTXO and anyone can create a RGB node of special structure (public extensions of RGB state) connected to such valences. Moreover, there is no limit on how many public extensions can connect to a single opened valences type (and such limits can't be enforced).

Public extensions has structure similar to genesis and state transitions structure with the following differences:

• like genesis, they do not reference any ancestor seals (since there are none)
• they link to a specific type of opened valences from previous state transition or genesis (which must define opened valences of that type, otherwise public extension is not valid)

Like any other type of RGB state history node (genesis and state transitions) they can have new state assignments with seals defined (thus, creating new state rather then updating existing one, like done in genesis), metadata and simplicity scripts; their structure and validation rules are defined with the Schema and Schema-provided simplicity scripts.

Similar to genesis (and unlike owned transitions) public extensions are not committed into bitcoin transactions, thus being ephemeral until some other owned transition closes one of it's seals/updates their state, after which they become committed into bitcoin transactions graph through that transition. In practice this means that publicity can update RGB contract history only if some of state owners is willing to accept those updates, which will include the new state into future subgraph starting from such RGB state history node.

[UkolovaOlga]

Discussion notes

@dr-orlovsky> Schema defines which types of states exist. For instance, one “type of state” is “amount of asset” (but even for fungible assets there are more state types, like “right to re-issue” etc). State is a “digital right”, like ownership rights on the asset, or secondary issuance right etc. So under some schema there could be multiple types of state.

Schema and genesis define rules for validation of each state type, for instance for ownership right (=“amount of the asset” state) the rule is: “sum of inputs must be equal to sum of outputs”. For other rights the rule is different, for instance for the secondary issuance we need to validate that the sum of all issuances does not exceed the max supply from genesis.

Genesis assigns some state (of some type) to UTXOs, defining seals in the following way. Whoever owns the state=can spend that UTXO, owns the corresponding right and can assign a new state to new UTXO creating state transition.

^^^ For now, this is just terminology of current RGB w/o the proposed change

Now, lets imagine that the contract creator, in genesis (if the schema allows it) says “anybody who can prove that he has locked bitcoins to this specific multisig can issue equivalent amount of the asset of this type”. This is a validation rule for some specific state type.

However, the question here is who has the right to do this issuance? This kind of issuance is not a state, since it can’t be bound to a specific UTXO: the right is “public”, meaning “anyone can do it” (of course they still need to follow the validation rules). So this is not a single-use-seal or state, and we name this thing “valency”: it is an extension point, where anyone can add something to the contract (again, under the fixed validation rules defined by schema/genesis).

So, any party can use that valency by creating a special data structure, which, like genesis (but it’s not genesis!), does not require to be committed into the blockchain (since it does not close any seals). This data structure is called “extension”.

Again, similar to genesis, this data structure can define a set of seals with some state (only of types and in amounts allowed by the schema) and assign that state to UTXOs (providing necessary proofs, suck as proofs of bitcoins being locked, as a part of metadata).

Next, those who are willing to accept this “issued” tokens just spend those UTXOs (validating the extension and genesis), creating a normal state transition, and the further process goes as usual.

In “ethereum terms”, valencies are “contract methods”, which can be called by anybody, with values for the method parameters stored in the metadata fields, creating extension (equivalent of ethereum contract-call type of transaction).

All that extension does is creating seals. So you use an extension when you spend that UTXO from that seal, and you either lose that state/invalidate that extension, or commit to the state transition referencing that extension in the spending transaction, and if you do the latter, you need to validate that extension against schema & genesis rules (otherwise new owners will not accept your proofs).

Once you define a seal, the rest always works in the same way for all three things: genesis, transitions and now extensions: there must be no vulnerabilities, b/c the validation procedure is always the same.

It does not require any changes in the validation logic (it extends the verification against schema rules with new rules, but not the commitment structure validation or scripting).

——
In other words, the proposal allows the contract creator to extend the right of defining new single-use-seals not just to those who are already a part of the contract (i.e. owns some state/asset on their UTXO), but also to publicity. Nevertheless, this publicity, whenever it uses that right, should stick to certain procedure, otherwise the created state (and seals) would be unusable.

@fedsten > Let me see if I understood correctly with a practical example:

1. Alice issues a new token with a schema that defines some state, and an extension point that defines how others can freely create a new seal separated from the transaction graph originating from her seal.
2. Later on Bob creates a new seal that points to the extension point of Alice's contract, providing proof that the condition defined in the extension point are met (eg he locked some bitcoins in a multisig).
3. Carol receives some tokens from Bob, and she verifies that Bob has indeed met the condition defined in Alice's contract to consider the state transition as valid.

@dr-orlovsky> Correct

@fedsten > Could Bob also include another extension point in his new seal? Would this be something forbidden by default or required to be defined in Alice's contract?

@dr-orlovsky > You are mixing seals with graph nodes (state transitions/extensions/genesis). Each node can define multiple seals of multiple types.
'Node <-one to many-> Seal type <-one to many-> Seal definition' - this is the real data structure, so extension points are parts of nodes, but not parts of seals. Maxim Orlovsky, [6 Oct 2020, 17:46:23]:
To explain it a bit: with the fungible asset schema I can create a state transition spending the “secondary issuance” seal/UTXO, and this state transition will define:

1. one seal of “secondary issuance” type (for future issuances)
2. multiple seals of “asset” type (which will hold assets created during this issuance).
   [it’s all with normal RGB]

Now, coming back to your question. Yes, state transitions may also have extension points, but only if a schema allows it.

• State transition uses ancestors to reference state & seals defined by some previous node (as a part of assignments);
• Extension node uses ancestors to reference valencies (=extension points) of a previous node (genesis, state transition or other extension).

@fedsten > So basically any new state may derive by either a seal that got unsealed, or an open valency that defined some conditions?

@dr-orlovsky > Yes, such usage is possible. Actually it opens a lot of different use cases (especially those completely outside of asset/token world), impossible with RGB before this concept was been introduced. If you think of a single-use-seal as of a digital right with a clear owner (“owned right”) and possible additional data/state, and of an extension point as a publically-available digital right (“public right”), with complex rules and conditions you can apply for their further evolution with schema and simplicity scripting… This is actually mind blowing what can be done with it (up to building trustless legal systems with economical enforcements for P2P & anonymous parallel digital economy). Also this is very scalable: extensions are ephemeral and their creation does not require a bitcoin transaction.