Miscellaneous: One-time sealing is the cornerstone of RGB/RGB++ protocol

Author: Hanssen; Translation: saku; Original link:

https://talk.nervos.org/t/en-cn-misc-single-use-seals/8279

One-time seals are the cornerstone of the RGB/RGB++ protocol, which expands the capabilities of Bitcoin.But what exactly is a one-time seal (SUS)? How do we implement it on the blockchain? Did you know that one-time seals already existed in the technical architecture of CKB before the RGB++ protocol was proposed?

We will briefly discuss the above questions and show some CKB script designs based on the concept of one-time seals.

What is SUS?

To achieve a one-time seal, we propose that miners prove the contents of a series of truth expressions over sets of key-value pairs. The keys are expressions, the values ​​are claims, and together with the (disposable) witness they form the parameters of the expression. Once an expression is added to a seal set, the value associated with it cannot be changed.

Peter Todd - Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance

The following picture from Peter Todd's SUS Practical Example vividly and accurately describes SUS: Like real-life seals, they cannot be opened once they are sealed, and each has a unique identifier.

Imagine that in the digital world, you can have a unique and indestructible seal to seal any data, and no one (including yourself) can forge these seals. This is SUS.

Simple and easy to understand SUS

When we spend an output, our goal is to make the spent funds flow to another set of outputs by submitting the allocation of this set of outputs to these one-time seals.

Peter Todd - Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance

In the blockchain world, UTXO (Unspent Transaction Outputs) is where users store their assets. The process of users transferring their assets through transactions basically consumes UTXO and creates new UTXO for others.

The natural consistency of SUS and UTXO makes the design of one-time seal on the UTXO model straightforward and simple.We can think of TXO (Transaction Outputs) as our seals, and each transaction submitted on the blockchain can be regarded as sealing its data into all input TXOs. In this way, we have completed the one-time seal design on the UTXO model: the output of the transaction meets all our requirements for one-time sealing:

• The sealed seal cannot be destroyed because we need to spend TXO to seal it, and a sum of money cannot be spent twice.

• The seal is unique and cannot be forged because all TXOs are unique.

• We can have the seal before sealing the data because creating and spending TXO are separate processes.

Seal Chain and Type ID

Type ID describes a way to create a singleton type by using a special type script - that is, there is only one Live Cell under this Type.

CKB RFC 0022 - CKB Transaction Structure

We can create a seal chain by connecting a new seal to it when closing a seal. This approach simplifies the verification process because the validator only needs to reach consensus on the initial seal and can get the latest seal through the seal chain. However, this also means that the validator must retrieve the entire seal chain to verify the latest data.

Thanks to CKB's Turing-complete virtual machine and its extended UTXO model - the Cell model, we can include more information in the seal. The difference between Cell on CKB and UTXO on BTC is that Cell can store arbitrary data, and the conversion of this data is restricted by the "Type" Script.

In CKB's Type ID scheme, we require that each seal on the seal chain must contain the ID of the first seal as the starting information. Type ID means that Type Script gives the Cell a unique ID and restricts its ID from the beginning to the end of the seal chain. This ID allows validators to retrieve the latest seal only through the universal indexer on CKB.

More SUS on CKB

• Single Use Lock: This Lock requires the consumption of a specified Live Cell to unlock. As we said before, a seal can only be sealed once. Therefore, a Single Use Lock can only be unlocked once.

• Type Proxy Lock: This Lock requires a Cell with a specific Type Script to unlock. In the case where this Type Script is Type ID, only those who have the full limit of the updated seal chain can unlock it.

Asset issuance permission control is a practical application scenario of these two scripts. In CKB's xUDT protocol, issuers can mint new tokens when they prove they are able to unlock the Owner lock. Using only a simple signature-based Lock, we cannot be sure that the issuer still has their private key, which means they can always mint new tokens, making each asset infinitely scalable.

Here, Single Use Lock provides us with a solution. After consuming the specified Cell, since no one can unlock the Owner lock to mint new tokens, we can believe that the token supply is indeed capped.

As a more flexible solution, token issuers can use Type Proxy Lock to bind minting permissions to Type ID Cell. It is like a key that cannot be forged and can be given to others or destroyed.