banner
CKB 中文

CKB 中文

CKB 是理想的比特币 Layer 2

The cornerstone of RGB and RGB++ protocols: one-time sealing and client verification

In the Bitcoin ecosystem, various scaling solutions have emerged like mushrooms after rain to address the many 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++ are focusing on another important area—issuing assets on the Bitcoin layer one network and expanding Bitcoin's programmability.

The cornerstone of RGB and RGB++ protocols is 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 Single-Use-Seal and Client-side Validation technology, 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.

img

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 pursue 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 make it easier to understand, we can simply 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 it with a seal, while spending a UTXO is equivalent 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 can inherit the security of the Bitcoin blockchain 100%.

Protocols for issuing assets on Bitcoin layer one, such as RGB and RGB++, cleverly utilize this characteristic of UTXO, treating it as a container for asset and transaction information. This information is attached to specific Bitcoin UTXOs in the form of Commitments. When related information needs to be updated, the UTXO must be spent, and a new UTXO with the updated asset information must be specified in the new transaction.

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 one asset issuance protocols based on Single-Use-Seal and Client-side Validation, but they each have their unique implementation features.

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++, proposed by Nervos CKB co-founder Cipher in February this year and deployed on the mainnet in early April, further upgraded to RGB++ Layer in July, aiming to bring homomorphic binding, smart contract capabilities, and bridge-less cross-chain functionality 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, uses 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:

  1. 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).
  2. 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.
  3. Upon receiving it, Bob carefully checks each TEST token and its history to ensure they are genuine and valid. After confirming, Bob generates a "confirmation signature" and returns it to Alice.
  4. 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:

  1. Bob just needs to send his BTC address to Alice (this step can be skipped if Alice already knows it).
  2. Alice directly transfers 40 TEST tokens to Bob via 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, transferred 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 CKB blockchain miners, eliminating the need for Bob to perform it himself (though 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 technology brings more possibilities to the Bitcoin network. As outstanding representatives of this technology, RGB and RGB++ 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:

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.