CoinWorld reported:
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 were already present in the technical architecture of CKB 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 is SUS?
To achieve Single-Use Seals, we propose that miners prove the truthfulness of a series of expressions about key-value pairs. The keys are expressions, and the values are declarations, which, together with (disposable) witnesses, form the parameters of the expressions. Once an expression is added to the set of seals, the associated value 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, which vividly and accurately describes SUS:
Just like physical seals, once they are sealed, they cannot be opened again, and each one has a unique identifier.
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 what SUS is.
Simple and understandable SUS
When we spend an output, our goal is to direct the funds to another set of outputs by submitting the allocation of this set of outputs to these 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 on the UTXO model direct and simple.
We can regard Transaction Outputs (TXOs) as our seals, and each transaction submitted on the blockchain can be seen as sealing its data into all input TXOs. In this way, we have achieved Single-Use Seal design on the UTXO model: the sealed seals meet all our requirements for Single-Use Seals:
The sealed seals cannot be destroyed because we need to spend 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 Chains and Type ID
Type ID describes a way to create singleton types by using special type scripts, which means there is only one Live Cell under this Type.
CKB RFC 0022 – CKB Transaction Structure
We can create seal chains by connecting new seals to the closed seals. This approach simplifies the verification process because the verifier only needs to reach consensus on the initial seal and can obtain the latest seals 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 – 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 limited by “Type” Scripts.
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 the Cell a unique ID and restricts it from being changed throughout the process from the beginning to the end of the seal chain. This ID allows the verifier to retrieve the latest seals with just the common indexer on CKB.
More SUS on CKB
Single Use Lock: This Lock requires consuming a specified Live Cell to unlock. As we mentioned earlier, a seal can only be sealed once. Therefore, a Single Use Lock can only be unlocked once.
Type Proxy Lock: This Lock requires unlocking with a Cell that has a specific Type Script. In the case of Type ID as the Type Script, only those with full authority over the updated seal chain can unlock it.
Asset issuance permission control is a practical application scenario for these two Scripts.
In CKB’s xUDT protocol, issuers can mint new tokens by proving that they can unlock the Owner lock. With a simple signature-based Lock, we cannot determine whether the issuer still possesses their private key, which means they can always mint new tokens, allowing unlimited issuance for each asset.
Here, Single Use Lock provides us with a solution. After consuming a specified Cell, as no one can unlock the Owner lock to mint 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.
