The report from CoinWorld:
Author: Hanssen; Translator: saku; Original article link:
https://talk.nervos.org/t/en-cn-misc-single-use-seals/8279
Single-Use-Seals (SUS) are the cornerstone of the RGB/RGB++ protocol, which expands the capabilities of Bitcoin.
But what exactly are Single-Use-Seals? How do we implement them on the blockchain? Did you know that Single-Use-Seals existed in the CKB technical architecture before the proposal of the RGB++ protocol?
We will briefly discuss these questions and showcase some CKB script designs based on the concept of Single-Use-Seals.
What are SUS?
To achieve Single-Use-Seals, we propose that miners prove the truthfulness of a series of key-value pair expressions. The keys are expressions, and the values are declarations. Together with the (disposable) witness, they form the parameters of the expression. Once an expression is added to the set of seals, the associated values cannot be changed.
Peter Todd – Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance
The following image is from Peter Todd’s practical example of SUS. It vividly and accurately describes SUS:
Just like real-life seals, once they are sealed, they cannot be reopened, and each one has a unique identifier.
[Image]
Imagine in the digital world, you can have unique and indestructible seals to seal any data, and no one (including yourself) can forge these seals. That is SUS.
Simplified SUS
When we spend an output, our goal is to redirect the funds to another set of outputs by committing the allocation of these outputs to the Single-Use-Seals.
Peter Todd – Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance
In the blockchain world, Unspent Transaction Outputs (UTXOs) are where users store their assets. The process of users transferring their assets essentially involves consuming UTXOs and creating new UTXOs for others.
The natural consistency between SUS and UTXOs makes the design of Single-Use-Seals directly and simply on the UTXO model.
We can think of Transaction Outputs (TXOs) as our seals, and each transaction submitted on the blockchain can be seen as sealing its data into all the input TXOs. By doing so, we achieve the design of Single-Use-Seals on the UTXO model: the outputs of the transaction satisfy all the requirements of Single-Use-Seals:
Sealed seals cannot be destroyed because we need to spend the TXOs to seal the seals, and money cannot be spent twice.
The seals are unique and cannot be forged because all TXOs are unique.
We can have the seals before sealing the data because the creation and spending of TXOs are separate processes.
Seal Chain and Type ID
Type ID describes a way to create singleton types by using a special type script, which means 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 a closed seal. This approach simplifies the verification process because the verifier only needs to reach consensus on the initial seal and can obtain the latest seal through the seal chain. However, this also means that the verifier 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 seals.
The difference between Cells on CKB and UTXOs on BTC is that Cells can store arbitrary data, and the transformation of this data is restricted by the “Type” Script.
In the Type ID scheme of CKB, we require that each seal on the seal chain must include the ID of the first seal as the starting information. Type ID means that the Type Script gives a unique ID to the Cell and restricts it from being changed throughout the process from the beginning to the end of the seal chain. This ID allows verifiers to retrieve the latest seals 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 mentioned earlier, a seal can only be sealed once. Therefore, the Single Use Lock can only be unlocked once.
Type Proxy Lock: This Lock requires the unlocking with a Cell that has a specific Type Script. In the case of Type ID, only those who have full access to the updated seal chain can unlock it.
Asset issuance permission control is a practical application scenario for these two Scripts.
In the xUDT protocol on CKB, issuers can forge new tokens by proving that they can unlock the Owner lock. Using a simple signature-based Lock, we cannot determine whether the issuer still possesses their private keys, which means they can always forge new tokens, allowing each asset to be infinitely inflated.
Here, Single Use Lock provides a solution. After consuming a specified Cell, since no one can unlock the Owner lock to forge new tokens, we can trust that the token supply does have an upper limit.
As a more flexible solution, token issuers can use Type Proxy Lock to bind the minting permission to a Type ID Cell. It is like an unforgeable key that can be handed over to others or destroyed.
