Comments (1)
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:
- 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.
- 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).
- 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:
- one seal of “secondary issuance” type (for future issuances)
- 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.
from lnpbps.
Related Issues (20)
- Make data type constants part fo the standard HOT 1
- Upgrade LNPBP-4 with merke trees
- LNPBP-2 references to an outdated stage of commitment procedure of LNPBP-1 HOT 2
- LNPBP-1 lacks standardization of public key serialization format HOT 6
- Cover multiple instances of the same pubkey in LNPBP-1 and 2 standards
- Allow bulletproof implementation upgradability in RGB schema HOT 1
- LNPBP-31: ElGamal on Secp256k1
- Write Tapret commitments standard HOT 4
- Test vectors HOT 1
- Write specification for opret-based RGB in BOLT lightning
- ticker doesn't allow numbers HOT 2
- decide future of current RGB21 implementation HOT 1
- Add contract media global state HOT 2
- RGB: Use i64 instead of i32 for Timestamps in interface standards HOT 6
- RGB-21 Schema: What should be the limit of the length of the name field? HOT 2
- RGB-21 Schema: Custom token data formatting HOT 2
- LNPBP-2: Miniscript determinism can't be used for key tweaks HOT 1
- LNPBP-2: Upgrade miniscript version requirement to v5.0.0 tagged commit
- LNPBP-38: Add support for Bifrost
- RGBv2: Reduce anchor entropy bit size by merging with txid data
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lnpbps.