In the Bitcoin ecosystem, various scaling solutions have emerged rapidly to address the numerous challenges faced by the Bitcoin network. Among them, Lightning Network cleverly constructs off-chain payment channels to solve the pain points of Bitcoin transactions being "expensive and slow." Meanwhile, protocols like RGB and RGB++ focus on another important area—issuing assets on the Bitcoin layer one network and expanding Bitcoin's programmability.
The cornerstone of the RGB and RGB++ protocols is the Single-Use-Seal and Client-side Validation (CSV) technology, first proposed by renowned Bitcoin Core early developer Peter Todd in 2016. In this article, we will detail the Single-Use-Seal and Client-side Validation technologies, as well as the differences between RGB and RGB++ protocols.
Single-Use-Seal and Client-side Validation#
Imagine you are shipping a container filled with precious goods through logistics. To ensure that the container is not opened without authorization during transport, you might use a special seal: a Single-Use-Seal. This plastic seal with a unique number cannot be restored once opened, effectively preventing the container from being secretly accessed.
Figure: A plastic Single-Use-Seal with a unique number; Source: https://petertodd.org/2016/commitments-and-single-use-seals#single-use-seals
In the digital world, we also need such a "seal" mechanism to protect information or assets. Traditional electronic seals often rely on centralized trusted entities to verify their status, but in the decentralized blockchain world, we seek trustless solutions. So, how can we achieve reliable electronic sealing without centralized authority? The answer lies in Bitcoin's UTXO model.
UTXO, short for Unspent Transaction Output, is the basic unit of Bitcoin. Each UTXO contains two key pieces of information: its own denomination and a locking script that determines how the funds can be spent. The design of Bitcoin's UTXO model and consensus rules ensure that each UTXO can only be spent once. To simplify understanding, we can think of each UTXO as a small safe containing a certain amount of Bitcoin. Each safe can only be opened once; once opened, the Bitcoin inside is taken out, and the safe itself is destroyed. This design aligns with the characteristics of a Single-Use-Seal: creating a UTXO is like sealing a seal, while spending a UTXO is akin to breaking the seal.
Bitcoin prevents "double spending" (i.e., a UTXO being spent multiple times) through the time-tested Proof of Work (PoW) consensus mechanism, ensuring the security of user assets. Therefore, another significant advantage of using UTXO as a Single-Use-Seal is that it inherits 100% of the security of the Bitcoin blockchain.
Protocols like RGB and RGB++ for issuing assets on the Bitcoin layer cleverly utilize this characteristic of UTXO, treating it as a container for asset and transaction information. This information is attached to a specific Bitcoin UTXO in the form of a Commitment. When it is necessary to update the relevant information, the UTXO must be spent, and a new UTXO must be specified in the new transaction with the updated asset information attached.
However, the limitations of Bitcoin scripts make it impossible to directly programmatically verify assets other than BTC on the Bitcoin chain. To solve this tricky problem, the Client-side Validation (CSV) model was born. In this model, users need to verify the validity of the assets and the legality of the transactions themselves.
RGB and RGB++: Two Paths, One Goal#
RGB and RGB++ are both Bitcoin layer asset issuance protocols built on the foundation of Single-Use-Seal and Client-side Validation, but they each have their unique characteristics in implementation.
RGB is led by Maxim Orlovsk and the LNP/BP Standards Association, aiming to create a Turing-complete, scalable, and privacy-focused smart contract solution based on Bitcoin. RGB++ was proposed by Cipher, co-founder of Nervos CKB, in February this year and deployed to the mainnet in early April. In July, RGB++ was further upgraded to RGB++ Layer, dedicated to bringing homomorphic binding, smart contract capabilities, and bridge-less cross-chain functionalities to all UTXOs.
From the user's perspective, the main difference between the two lies in the verification mechanism. RGB requires users to run their own clients for verification, somewhat like making everyone a bank teller. RGB++, on the other hand, utilizes a Turing-complete UTXO blockchain (like Nervos CKB) for verification, akin to hiring a professional accountant to handle complex accounts; of course, if users do not trust the accountant, they can choose to verify themselves.
Let’s illustrate the workflow of these two protocols through a specific transfer example:
Suppose Alice has 100 TEST tokens based on the RGB protocol, and she wants to transfer 40 to Bob as a birthday gift. The process is as follows:
- Bob first needs to issue an electronic invoice and send it to Alice (this step is similar to the transaction process in the Lightning Network).
- After receiving and checking Bob's invoice, Alice generates an RGB transaction to transfer 40 TEST tokens to Bob. At the same time, Alice needs to filter out all historical records related to these TEST tokens from her local client history to prove her ownership of these tokens. Alice then sends the new transfer transaction along with the proof of ownership to Bob for verification.
- Upon receiving it, Bob carefully checks each TEST token and its history to ensure they are genuine and valid. Once verified, Bob generates a "confirmation signature" and returns it to Alice.
- After receiving Bob's confirmation signature, Alice broadcasts the Commitment corresponding to this RGB transaction to the Bitcoin blockchain.
If Alice is transferring 40 TEST tokens based on the RGB++ protocol to Bob, the process is much simpler:
- Bob only needs to send his BTC address to Alice (this step can be skipped if Alice already knows it).
- Alice directly transfers 40 TEST tokens to Bob through her wallet.
On the Bitcoin blockchain, both transactions appear as Alice spending a UTXO #1 associated with 100 TEST tokens and generating two new UTXOs: one associated with 40 TEST tokens UTXO #2 (to Bob) and one associated with 60 TEST tokens UTXO #3 (Alice's change).
The difference is that in the RGB protocol, the TEST token information associated with UTXO #1, UTXO #2, and UTXO #3 needs to be parsed and verified through the RGB client. In the RGB++ protocol, these UTXOs are homomorphically bound to Cell #1, Cell #2, and Cell #3 on the CKB blockchain (Cell is an enhanced version of UTXO), and the TEST token information is directly stored in the Cell, with the verification work completed by miners on the CKB blockchain, eliminating the need for Bob to perform it himself (of course, he can choose to verify himself).
Using a Turing-complete UTXO blockchain (like Nervos CKB) instead of client-side validation not only simplifies user operations but also brings other benefits to RGB++, such as solving the client data silo problem, the unowned contract problem, P2P network issues, and more.
Conclusion#
The innovative application of Single-Use-Seal and Client-side Validation technologies brings more possibilities to the Bitcoin network. RGB and RGB++, as outstanding representatives of this technology, are paving new paths for the Bitcoin ecosystem. They not only expand Bitcoin's functionality but also provide secure and efficient solutions for asset issuance and smart contract implementation.
Let us look forward to RGB, RGB++, and other innovative protocols that may emerge in the future, further expanding the boundaries of Bitcoin!
References: