Single-Use-Seals(SUS) is the basestone of RGB/RGB++ protocols, extending Bitcoin’s ability. But what exactly is SUS? How can we have such things on blockchains? Do you know that the concept of SUS actually existed in CKB far before the RGB++ protocol? We will briefly discuss these here and showcase some simple scripts on CKB with the idea of SUS.
What is SUS?
To implement Single-Use Seals we propose that miners attest to the contents of a series of key:value sets of true expressions, with the keys being the expressions, and the values being commitments, which along with (discardable) witnesses make up the argument to the expression. Once an expression is added to the closed seal set, the value associated with it can’t be changed.
Peter Todd - Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance
The picture at the beginning of this article is from Peter Todd’s concrete example of SUS, which vividly and accurately describes the SUS: Like real-life seals, we can not open them again after closing, and each has a unique identifier.
Imagine that, in the digital world, you can also have unique, indestructible seals to seal arbitrary data while nobody (including you!) can fake these seals. That’s what SUS describe.
SUS Made Simple
When we spend an output our goal is to direct the funds spent to a set of outputs by irrevocably committing single-use seals to that distribution of outputs.
Peter Todd - Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance
In the blockchain world, UTXOs(Unspent Transaction Outputs) are places where users store their assets. When users transfer their assets, they basically destroy their UTXOs and create new UTXOs for others.
Because of the natural consistency of SUS and the UTXO model, the design of seals on the UTXO model is straightforward. Let’s define the TXOs(Transaction Outputs) as our seals and each transaction commitment on the blockchain as sealing the transaction data to all its input TXOs. Then we are done! The TXO meets all the requirements we want for SUS:
- Closed seals are indestructible because we spend TXOs to close seals and can not spend the same money twice.
- Seals are unique and can not be faked because all TXOs are unique.
- We can have seals before sealing data because we create and spend TXOs separately.
Seal Chain and Type ID
Type ID describes a way of using a special type script which can create a singleton type - there’s only one live cell of this type.
We can create a seal chain by linking a new seal to an existing one when closing a seal. This approach simplifies the verification process, as verifiers only need to reach a consensus on the genesis seal to track data updates. However, it also means that verifiers must have the entire chain to verify the latest data.
Thanks to CKB’s Turing-complete VM and its extended-UTXO model - the Cell Model, we can have more information in a seal. The difference between a cell on CKB and a UTXO on BTC is that a cell can store arbitrary data whose transformations are restricted by a “type” script.
In the Type ID method on CKB, we enforce that every seal on a seal chain must contain the first seal’s ID as genesis information. Type ID means the type script gives cells unique IDs and restricts them from being changed from the beginning to the end of the seal chain. The ID allows verifiers to retrieve the latest seal simply from a universal indexer on CKB.
More SUS on CKB
- Single Use Lock: This lock requires a specified live cell consumption to unlock. As we talked about before, a seal can only be closed once. Thus, the lock can also only be unlocked once.
- Type Proxy Lock: This lock requires cells with a specified type script involved to unlock. If the type script is Type ID, only people with permission to update the seal chain can unlock this lock.
Assets issuing permission controlling is a practical application scenario for these two scripts. In CKB’s xUDT protocol, issuers can mint new tokens when they prove they can unlock the owner lock. With only simple signature-based locks, we can not tell if issuers still have their private key, which means they can always mint new tokens, making every asset supply unlimited.
Here, the Single Use Lock provides us with a solution. After spending the specified cell, since no one can unlock the owner lock to mint new tokens, we can now trust that the token supply is indeed limited.
As a more flexible solution, token issuers can use the Type Proxy Lock to bind the minting permission to a Type ID cell. It is like a lock with an unforgeable key you can give to others or destroy.
You can find implementations for these scripts on GitHub.