This article will provide a concise and straightforward interpretation of the design principles behind the Bitcoin asset issuance protocols RGB and RGB++. It aims to help more community enthusiasts better and more intuitively understand RGB and RGB++.
With the growing popularity of RGB++ and related asset issuance, discussions about the principles of the RGB and RGB++ protocols have become a topic of increasing interest. However, it is realized that in order to understand RGB++, one must first understand the RGB protocol.
The original RGB protocol is somewhat obscure in its technical structure, and there are few systematic and easy-to-understand reference materials available. Although Geek Web3 has previously published two systematic interpretation articles about RGB and RGB++, feedback from community members suggests that these articles are too lengthy and complicated.
In order to help more people understand the RGB and RGB++ protocols more quickly, the author of this article hastily completed a brief and straightforward interpretation of RGB and RGB++ during a Hong Kong event. It can be read in a few minutes and is intended to assist more community enthusiasts in better and more intuitive understanding of RGB and RGB++.
RGB Protocol: Users need to personally validate the data
The RGB protocol is a special P2P asset protocol and a computational system under the Bitcoin chain. It is similar to payment channels in some aspects: users need to personally execute the client and validate the transfer behavior related to themselves (Verify by yourself). Even if you are just an asset receiver, you need to first ensure that the transfer declaration of the asset sender is correct before the transfer declaration can take effect. Obviously, this is different from the traditional form of asset transfer and reception, and we call it “interactive transfer.”
Why is it like this? The reason is that in order to protect privacy, the RGB protocol does not adopt the “consensus protocol” used in traditional blockchains such as Bitcoin and Ethereum (once data goes through the consensus protocol, it will be observed by almost all nodes on the network, and privacy cannot be guaranteed). Without a consensus process involving a large number of nodes, how can we ensure the security of asset changes? This is where the idea of “client validation” (Verify by yourself) comes in. You need to execute the client yourself and personally validate the asset changes related to you.
Let’s say there is an RGB user named Bob, and he knows Alice. Alice wants to transfer 100 TEST tokens to Bob. After Alice generates the transfer information “Alice to Bob,” she needs to send the transfer information and the relevant asset data to Bob for him to personally check and verify. Only when it is confirmed to be correct can the transfer declaration take effect. Therefore, the RGB protocol is to allow users to personally validate the data’s validity, replacing traditional consensus algorithms.
However, without consensus, the data received and stored by different RGB clients is inconsistent. Everyone only stores asset data related to themselves locally and does not know the status of other people’s assets. This not only protects privacy but also creates a “data island.” If someone claims to have 1 million TEST tokens and wants to transfer 100,000 to you, how can you trust them?
In the RGB network, if someone wants to transfer assets to you, they must first present asset proof, trace the history of the asset from its initial issuance to multiple transfers, and confirm that the Token to be transferred to you is fine. This is similar to when you receive cash from an unknown source, you ask the other party to explain the history of the cash and whether it was produced by the designated issuer to avoid counterfeit money.
The above process occurs under the Bitcoin chain, and only these steps are not enough to establish a direct relationship between RGB and the Bitcoin network. To address this, the RGB protocol adopts the idea of “single-use seal,” which links RGB assets to UTXOs on the Bitcoin chain. As long as the Bitcoin UTXO is not double-spent, the linked RGB assets will not have double payments, thus preventing “re-organization” of RGB assets with the help of the Bitcoin network. Of course, this requires the release of Commitment on the Bitcoin chain and the use of the OP_Return opcode.
To summarize the workflow of the RGB protocol:
1. RGB assets are linked to Bitcoin UTXOs, and Bob owns some Bitcoin UTXOs. Alice wants to transfer 100 tokens to Bob, and before receiving the assets, Bob informs Alice in advance which Bitcoin UTXO should be linked to these RGB assets.
Alice constructs a “Alice to Bob” RGB asset transfer data and provides the history of these assets to Bob for verification.
After confirming that the data is correct locally, Bob sends a receipt to Alice, telling her that the transaction can proceed.
Alice constructs a Merkle Tree for the “Alice to Bob” RGB transfer data and releases the Merkle Root on the Bitcoin chain as Commitment. Commitment can be simply understood as the hash of the transfer data.
If someone wants to verify in the future that the “Alice to Bob” transfer actually occurred, they need to do two things: obtain the complete transfer information of “Alice to Bob” under the Bitcoin chain and check whether the corresponding Commitment (hash of the transfer data) exists on the Bitcoin chain.
Bitcoin acts as a historical log for the RGB network, but the log only records the hash/Merkle root of the transaction data, not the transaction data itself. Due to the use of client validation and single-use sealing, the RGB protocol has high security. As the RGB network is composed of dynamic user clients in a P2P and non-consensus form, you can change the counterparty at any time without having to send the transaction request to a limited number of nodes. Therefore, the RGB network has strong resistance to censorship, and this organizational form is more resistant to censorship than large public chains such as Ethereum.
However, the high security, resistance to censorship, and privacy protection come at a cost: users need to personally execute client validation of the data. If someone sends you assets with a long transaction history and many transfers, you need to bear the pressure of validating all of them.
In addition, each transaction requires multiple communications between the parties involved. The recipient needs to validate the asset source of the sender and then send a receipt to approve the sender’s transfer request. In this process, at least three message exchanges need to take place between the parties. This “interactive transfer” is significantly different from the “non-interactive transfer” that most people are accustomed to. Can you imagine someone sending you money and sending you the transaction data to check, and the transfer process can only be completed after receiving your receipt message?
Furthermore, as mentioned earlier, the RGB network lacks consensus, and each client is isolated, which is not conducive to migrating complex smart contract scenarios from traditional public chains to the RGB network. This is because Defi protocols on Ethereum or Solana rely on globally visible and data-transparent ledgers. How to optimize the RGB protocol, improve user experience, and solve the aforementioned problems become unavoidable challenges for the RGB protocol.
RGB++: Optimistic custodianship replacing client validation
RGB++ proposes a new approach that combines the RGB protocol with UTXO-supporting public chains such as CKB, Cardano, and Fuel. The latter serves as the validation layer and data storage layer for RGB assets, transferring the data validation work originally performed by users to third-party platforms/chains such as CKB. This effectively replaces “client validation” with “validation by decentralized third-party platforms.” As long as you trust CKB, Cardano, Fuel, and other public chains, you can adopt RGB++ mode. If you do not trust them, you can switch back to the traditional RGB mode.
RGB++ and the original RGB protocol are theoretically compatible and not mutually exclusive.
To achieve the above-mentioned effect, it requires the use of an idea called “homomorphic binding.” CKB and Cardano and other public chains have their own extended UTXOs, which have programmability beyond UTXOs on the BTC chain. “Homomorphic binding” is the process of writing the parameters of RGB asset data into the “containers” of these UTXOs on the CKB, Cardano, or Fuel chain and displaying them directly on the blockchain. Whenever an RGB asset transaction occurs, the corresponding asset container can also exhibit similar characteristics. It is like the relationship between a physical object and its shadow, which is the essence of “homomorphic binding.”
For example, if Alice owns 100 RGB tokens and a Bitcoin UTXO A, as well as a UTXO on the CKB chain, and this UTXO is marked as “RGB Token Balance: 100,” with unlocking conditions associated with UTXO A.
If Alice wants to send 30 tokens to Bob, she can first generate a Commitment, with the corresponding declaration being: transfer the RGB tokens associated with UTXO A, transferring 30 to Bob and 70 to another UTXO controlled by Alice.
Afterward, Alice spends UTXO A on the Bitcoin chain, releases the above-mentioned declaration, and then initiates a transaction on the CKB chain to consume the UTXO container carrying 100 RGB tokens, generating two new containers, one containing 30 tokens (for Bob) and one containing 70 tokens (controlled by Alice). In this process, the task of verifying the validity of Alice’s assets and transaction declarations is completed by the CKB, Cardano, or other network nodes through consensus, without the involvement of Bob. At this time, CKB and Cardano act as the validation layer and DA layer for the RGB assets.
Everyone’s RGB asset data is stored on the CKB or Cardano chain, with global verifiability, making it conducive to implementing scenarios in Defi, such as liquidity pools and asset pledging protocols. Of course, this approach sacrifices privacy. It is essentially a trade-off between privacy and product usability. If you pursue ultimate security and privacy, you can switch back to the traditional RGB mode. If you don’t care about these, you can confidently adopt the RGB++ mode, depending on your personal needs. (In fact, with the powerful and complete functionality of CKB and Cardano and other public chains, privacy transactions can be achieved with the help of ZK.)
It is important to note that RGB++ introduces an important trust assumption: users need to optimistically believe that CKB/Cardano and other chains or network platforms composed of a large number of nodes through consensus are reliable and error-free. If you don’t trust CKB, you can also follow the interactive communication and validation process in the original RGB protocol and execute the client yourself.
Under the RGB++ protocol, users can directly operate their RGB asset containers on UTXO chains such as CKB/Cardano using their Bitcoin accounts, without the need for cross-chain transactions. They only need to rely on the characteristics of UTXOs in the aforementioned public chains and set the unlocking conditions of the cell container associated with a specific Bitcoin address/Bitcoin UTXO. If both parties of the RGB asset transaction trust the security of CKB, they may not need to frequently release Commitment on the Bitcoin chain. Instead, they can send a summary Commitment to the Bitcoin chain after many RGB transfers have taken place. This is called the “transaction folding” feature, which reduces costs.
However, it should be noted that the “containers” used in homomorphic binding require UTXO model-supporting public chains or infrastructures with similar features in terms of state storage. EVM chains are not suitable and will encounter many obstacles.
In summary, the public chains/function extension layers suitable for implementing homomorphic binding should have the following characteristics:
1. Use UTXO models or similar state storage schemes.
2. Have sufficient UTXO programmability, allowing developers to write unlocking scripts.
3. Have a state space related to UTXOs to store asset statuses.
4. Have Bitcoin-related bridges or light nodes.
Related Reports
Bitcoin Asset Issuance Protocol “RGB” Explained in One Article
Will Bitcoin Layer 2 Explode? In-depth Analysis of Ecological Development, On-chain Applications, and Expansion Solutions
Beyond BRC20? Understanding the Past and Present of Bitcoin Rune Protocol “Runes” in One Article