This article will interpret the design principles of the Bitcoin asset issuance protocols RGB and RGB++ in simple terms, hoping to help more community enthusiasts better and more intuitively understand RGB and RGB++.
With the popularity of RGB++ and related asset issuance, discussions about the principles of the RGB and RGB++ protocols have gradually become a topic of concern for more people. However, it is realized that in order to understand RGB++, one must first understand the RGB protocol.
The original RGB protocol is a special P2P asset protocol that is a computing system under the Bitcoin chain. In some ways, it is similar to payment channels: users need to personally execute the client and verify the transfer behavior related to themselves (Verify by yourself). Even if you are just an asset recipient, you still need to ensure that the transfer declaration of the asset sender is correct before this transfer declaration can take effect. Obviously, this is completely different from the traditional form of asset transfer and receipt. We call this “interactive transfer.”
Why is this necessary? The reason is that in order to protect privacy, the RGB protocol does not use the “consensus protocol” in traditional blockchains such as Bitcoin and Ethereum (once the data goes through the consensus protocol, it will be observed by almost all nodes in the network, and privacy cannot be guaranteed). If there is no consensus process involving a large number of nodes, how can the security of asset changes be guaranteed? This is where the idea of “client verification” (Verify by yourself) comes in. You need to execute the client yourself and personally verify the asset changes related to you.
Let’s assume there is an RGB user named Bob. He knows Alice, and Alice wants to transfer 100 TEST tokens to Bob. After Alice generates the transfer information for “Alice to Bob,” she needs to send the transfer information and the relevant asset data to Bob for him to check and confirm. Only then can this transfer declaration become effective. Therefore, the RGB protocol allows users to personally verify the data validity, replacing the traditional consensus algorithm.
However, without consensus, the data received and stored by different RGB clients is inconsistent. Everyone only stores asset data related to themselves and does not know the asset status of others. 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 tokens 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, tracing the history of the assets from the initial issuance to multiple transfers, and confirming that the tokens to be transferred to you are valid. It is like when you receive banknotes of unknown origin, you ask the other party to explain the history of these banknotes and whether they were produced by the designated issuer in order to avoid counterfeit money.
The above process occurs under the Bitcoin chain and these processes alone cannot directly associate RGB with the Bitcoin network. To address this, the RGB protocol adopts the idea of “single-use seal” and 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 experience double spending. In this way, the Bitcoin network is used to prevent “reorganization” of RGB assets. Of course, this requires the release of Commitment on the Bitcoin chain and the use of the OP_Return opcode.
Here is a summary of 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, so before receiving the assets, Bob needs to inform Alice which Bitcoin UTXO of his should be linked to these RGB assets.
Alice constructs a “Alice to Bob” RGB asset transfer data and provides the transaction history of these assets to Bob for verification.
After Bob confirms that the data is correct, he sends a receipt to Alice, informing her that the transaction can proceed.
Alice constructs the “Alice to Bob” RGB transfer data into a Merkle Tree and releases the Merkle Root to the Bitcoin chain as a Commitment, which can be understood as the hash of the transfer data.
If someone wants to verify in the future whether 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 if there is a corresponding Commitment (hash of the transfer data) on the Bitcoin chain.
Bitcoin acts as the historical log of the RGB network, but the log only records the hash/Merkle root of transaction data, not the transaction data itself. Due to the use of client verification and one-time sealing, the RGB protocol has high security. Since the RGB network is composed of dynamic user clients in a P2P and consensus-free form, you can change transaction counterparts at any time without sending transaction requests 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 like Ethereum.
However, the high security, resistance to censorship, and privacy protection come at a cost: users need to execute client verification themselves. If someone sends you assets with a long transaction history and many transfers, you still need to verify all of them under pressure.
In addition, each transaction requires multiple communications between the parties involved. The recipient needs to verify the origin of the sender’s assets and then send a receipt to approve the sender’s transfer request. In this process, at least three message exchanges are required between the parties. This “interactive transfer” is significantly different from the “non-interactive transfer” that most people are used to. Can you imagine someone sending you money and having to send you the transaction data for you to check and only complete the transfer process after receiving your receipt?
Furthermore, as mentioned earlier, the RGB network does not have 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 above problems has become an unavoidable issue for the RGB protocol.
RGB++, a protocol that combines RGB protocol with UTXO-supporting public chains like CKB, Cardano, and Fuel, proposes a new approach. In this approach, the UTXO-supporting public chains serve as the verification layer and data storage layer for RGB assets, transferring the data verification work that was originally done by users to third-party platforms/chains like CKB. This means replacing “client verification” with “third-party decentralized platform verification.” As long as you trust CKB, Cardano, Fuel, and other public chains, you can adopt the RGB++ mode. If you don’t 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, the idea of “homomorphism binding” is needed. CKB, Cardano, and other public chains have their own extended UTXOs, which have programmability beyond UTXOs on the BTC chain. “Homomorphism binding” is the process of writing the parameters of RGB assets into these containers on the CKB, Cardano, and Fuel chains and displaying them directly on the blockchain. When an RGB asset transaction occurs, the corresponding asset container can also exhibit similar characteristics, like the relationship between a physical object and its shadow. This is the essence of “homomorphism binding.”
For example, if Alice owns 100 RGB tokens and a Bitcoin UTXO A, and there is a UTXO on the CKB chain marked with “RGB Token Balance:100” 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 to Bob (30 tokens) and transfer 70 tokens to another UTXO controlled by Alice. After that, Alice spends UTXO A on the Bitcoin chain, releases the above declaration, and then initiates a transaction on the CKB chain to consume the UTXO container that holds 100 RGB tokens, generating two new containers: one container holds 30 tokens (for Bob) and the other container holds 70 tokens (controlled by Alice). During this process, the task of verifying the validity of Alice’s assets and transaction declarations is completed by consensus among CKB, Cardano, and other network nodes, without the involvement of Bob. At this point, CKB and Cardano serve as the verification layer and data availability layer for the Bitcoin chain.
The RGB data of everyone’s assets is stored on the CKB or Cardano chain, which has the characteristics of globally verifiable, facilitating the implementation of DeFi scenarios such as liquidity pools and asset pledging protocols. Of course, this approach sacrifices privacy. It is essentially a trade-off between privacy and 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 functionality of CKB, Cardano, and other public chains, privacy transactions can be achieved using ZK.)
It should be emphasized here that RGB++ introduces an important trust assumption: users should optimistically believe that CKB/Cardano and other chains or network platforms composed of a large number of nodes through consensus protocols are reliable and error-free. If you don’t trust CKB, you can also follow the interactive communication and verification process in the original RGB protocol and execute the client yourself.
Under the RGB++ protocol, users can directly use their Bitcoin accounts to operate their RGB asset containers on UTXO chains such as CKB/Cardano without 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 to be associated with a specific Bitcoin address/Bitcoin UTXO. If the RGB asset transaction parties trust the security of CKB, they don’t even need to frequently release Commitments on the Bitcoin chain. They can perform many RGB transfers before sending a summarized Commitment to the Bitcoin chain. This is called the “transaction folding” function, which can reduce costs.
However, it is worth noting that the “containers” used in homomorphism binding need to be supported by UTXO model public chains or have similar features in terms of state storage infrastructure. EVM chains are not very suitable and encounter many challenges.
In summary, public chains/functional expansion layers suitable for implementing homomorphism binding should have the following characteristics:
– Use the UTXO model or a similar state storage scheme.
– Have sufficient UTXO programmability to allow developers to write unlocking scripts.
– Have a UTXO-related state space to store asset status.
– Have a Bitcoin-related bridge or light node.
Related Reports:
– Bitcoin Assets Soaring! People Pay Attention to the Old “RGB Protocol” Again
– Bitcoin Layer2 About to Explode? In-depth Analysis of Ecological Development, On-chain Applications, and Expansion Solutions
– Beyond BRC20 Ambitions? Understanding the Past and Present of the Bitcoin Rune Protocol Runes