It is reasonable to maintain a table for UTXO of all kinds, where one of the fields will be “right type” field + “state” field, specifying OwnedRightType and state data from the specific allocation. It’s important to note that txid:vout would not be a unique key, since a single UTXO may have multiple allocations. Maybe it can be done as two linked tables. And probably it will be good to keep that data in YAML file cache structured in that way as well.
What we need to distinguish is:
Bitcoin data structures, for instance UTXO
RGB data structures, for instance state transition, genesis, owned right assignment, state data, metadata
RGB concepts, which are not always directly mapped to (1) and (2), which are “single-use-seal”, “owned right”
Owned right
Owned right is a particular right (abstract concept); for instance in fungible assets these rights are:
asset ownership
inflation
renomination
burn epoch creation
burn / burn-and-replace operation
An owned right may have some state data attached. Some rights do not have state data, and this called “declarative” (or “Void” previously).
Also, an owned right is always attached (we call that “assigned”) to a specific UTXO.
Assignment
Assignment is an owned right (defined by owned right typeu8 value) + state data + UTXO, which forms a single-use-seal definition when it is assigned that owned right.
So: nothing can prevent some given UTXO from having multiple assignments, of different owned right type, and even for each owned right type there might be multiple assignments.
UTXO <-one to many-> owned right type <-one to many-> assignment of some state:
assign an inflation right to it (one)
assign ownership right fo 100 of USDT
assign ownership right of 10 Apple shares under different contract
assign ownership right of 10000 of USDT again
This is a very bad situation, but we can’t prevent it from happening.
Especially if you assign different types of owned rights under the same contract you may not be able to create a state transition without loosing some of the rights or assets (since state transitions have a very strict set of owned rights type for which they can close seals). That is why @dr-orlovsky has created “split rights" state transition, which does only one thing - gives the ability to split those mixed rights into different UTXOs.
The open question is still how this multiplicity of UTXOs has to be managed.
UkolovaOlga
commented
3 years ago
It is reasonable to maintain a table for UTXO of all kinds, where one of the fields will be “right type” field + “state” field, specifying OwnedRightType and state data from the specific allocation. It’s important to note that txid:vout would not be a unique key, since a single UTXO may have multiple allocations. Maybe it can be done as two linked tables. And probably it will be good to keep that data in YAML file cache structured in that way as well.
What we need to distinguish is:
Owned right
Owned right is a particular right (abstract concept); for instance in fungible assets these rights are:
An owned right may have some state data attached. Some rights do not have state data, and this called “declarative” (or “Void” previously). Also, an owned right is always attached (we call that “assigned”) to a specific UTXO.
Assignment
Assignment is an owned right (defined by owned right type
u8value) + state data + UTXO, which forms a single-use-seal definition when it is assigned that owned right.So: nothing can prevent some given UTXO from having multiple assignments, of different owned right type, and even for each owned right type there might be multiple assignments.
UTXO <-one to many-> owned right type <-one to many-> assignment of some state:
This is a very bad situation, but we can’t prevent it from happening. Especially if you assign different types of owned rights under the same contract you may not be able to create a state transition without loosing some of the rights or assets (since state transitions have a very strict set of owned rights type for which they can close seals). That is why @dr-orlovsky has created “split rights" state transition, which does only one thing - gives the ability to split those mixed rights into different UTXOs.
The open question is still how this multiplicity of UTXOs has to be managed.