With the growing popularity of RGB++ and related asset issuance, discussions on the principles of RGB and RGB++ protocols have gradually become a topic of interest for more people. However, it’s realized that to understand RGB++, one must first grasp RGB protocol. The original RGB protocol is somewhat technical in structure, with scattered reference materials, and there hasn’t been much systematic and easily understandable reference material to date. Geek Web3 has previously published two systematic interpretations of RGB and RGB++ (available in our public account’s history), but according to community feedback, these articles were lengthy and too complex. In order to enable more people to quickly understand the RGB and RGB++ protocols, the author of this article hastily completed a brief layman’s interpretation of RGB and RGB++ during an event in Hong Kong. It can be read in just a few minutes, aiming to help more community enthusiasts better and more intuitively understand RGB and RGB++.

RGB Protocol: Users Need To Personally Verify The Data

RGB Protocol is a special type of P2P asset protocol, operating under the Bitcoin chain’s computational system. In some ways, it’s similar to payment channels: Users need to run their client personally and verify the transfer actions related to themselves (“Verify by yourself”). Even if you’re just a recipient of assets, you must first confirm that the transfer statement from the sender is correct before the transfer can take effect. This approach, known as “interactive transfer,” is markedly different from traditional asset transfer and reception methods. Why is this necessary? The reason is that the RGB protocol, in order to safeguard privacy, does not use the “consensus protocol” found in traditional blockchains like Bitcoin and Ethereum (where data, once in the consensus protocol, is observed by almost all nodes in the network, making privacy hard to protect). Without a consensus process involving a large number of nodes, how can asset changes be ensured to be safe? This is where the idea of “client verification” (“Verify by yourself”) comes in. You have to run your client and personally verify asset changes related to you.

For instance, let’s consider an RGB user named Bob who knows Alice. Alice wants to transfer 100 TEST tokens to Bob. After generating the “Alice to Bob” transfer information, Alice sends the transfer information and related asset data to Bob for him to check personally. Only when Bob confirms that everything is correct does the transfer proceed to become a valid RGB transfer. So, the RGB protocol requires users to verify the validity of data themselves, replacing traditional consensus algorithms. However, without consensus, the data received and stored by different RGB clients are inconsistent. Everyone only stores asset data relevant to themselves locally and doesn’t know about others’ asset statuses. While this protects privacy, it also creates “data islands.” If someone claims to have 1 million TEST tokens and wants to transfer 100,000 to you, how do you trust them? In the RGB network, if someone wants to transfer assets to you, they must first provide proof of assets, tracing the history of assets from initial issuance to multiple transfers, ensuring that the tokens they want to transfer to you are legitimate. It’s like when you receive unexplained banknotes, you ask the sender to explain the history of these banknotes, whether they were issued by the designated issuer, to avoid counterfeit money.

(Image source: Coinex)

The above process occurs under the Bitcoin chain, and these steps alone do not establish a direct connection between RGB and the Bitcoin network. To address this, the RGB protocol employs the concept of “single-use seals,” which bind RGB assets to UTXOs (Unspent Transaction Outputs) on the Bitcoin chain. As long as the Bitcoin UTXO is not double-spent, the bound RGB assets will not be subject to double payment, thus leveraging the Bitcoin network to prevent “Re-organization” of RGB assets. Of course, this requires the publishing of Commitments on the Bitcoin chain and the use of the OP_Return opcode.

Let’s outline the workflow of the RGB protocol:

1. RGB assets are bound to Bitcoin UTXOs, and Bob owns certain Bitcoin UTXOs. Alice wants to transfer 100 tokens to Bob. Before receiving the assets, Bob informs Alice which Bitcoin UTXO of his should be used to bind these RGB assets.

(Image source: Geekweb3/GeekWeb3)

1. Alice constructs transaction data for the “Alice to Bob” RGB asset transfer, along with the history of these assets, and gives it to Bob for verification.
2. After Bob confirms that the data is correct locally, he sends a receipt to Alice, informing her that the transaction can proceed.
3. Alice constructs the “Alice to Bob” RGB transfer data into a Merkle Tree and publishes the Merkle Root to the Bitcoin chain as a Commitment. We can simply understand Commitment as the hash of the transfer data.
4. If someone in the future wants to confirm 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 then verify whether the corresponding Commitment (the hash of the transfer data) exists on the Bitcoin chain.

Bitcoin serves as the historical log for the RGB network, but the log only records the hash/Merkle root of transaction data, not the transaction data itself. Due to the adoption of client-side verification and single-use seals, the RGB protocol offers extremely high security. Since the RGB network is composed of dynamic user clients in a P2P, consensus-free manner, you can change transaction counterparties at any time without needing to send transaction requests to a limited number of nodes. Therefore, the RGB network exhibits strong censorship resistance. This organizational structure makes it more resistant to censorship compared to large-scale public chains like Ethereum.

(Image source: BTCEden.org)

Certainly, the high security, censorship resistance, and privacy protection brought by the RGB protocol also come with significant costs. Users need to run their client to verify data. If someone sends you assets with a long transaction history involving thousands of transfers, you’ll need to verify them all, which can be quite burdensome.

Additionally, every transaction requires multiple communications between parties. The recipient needs to verify the sender’s asset source and then send a receipt to approve the sender’s transfer request. This process involves at least three message exchanges between parties. This “interactive transfer” is vastly different from the “non-interactive transfer” that most people are accustomed to. Imagine someone needing to send you money and having to send you the transaction data for your inspection, waiting for your receipt message before completing the transfer process.

Furthermore, as we mentioned earlier, the RGB network lacks consensus, and each client operates in isolation, making it difficult to migrate 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 transparent ledgers. How to optimize the RGB protocol, improve user experience, and address these challenges becomes an unavoidable issue for the RGB protocol.

RGB++ Introduces An Optimistic Custody Approach, Replacing Client-Side Verification.

The protocol called RGB++ introduces a new approach by combining the RGB protocol with UTXO-supported public chains such as CKB, Cardano, and Fuel. In this setup, the latter serves as the validation and data storage layer for RGB assets, transferring the data verification tasks originally performed by users to third-party platforms/chains like CKB. This effectively replaces client-side verification with “third-party decentralized platform verification.” As long as you trust platforms/chains like CKB, Cardano, or Fuel, you’re good to go. If you don’t trust them, you can always switch back to the traditional RGB mode.

RGB++ and the original RGB protocol are theoretically compatible with each other; it’s not a case of one or the other, but rather they can coexist.

To achieve the mentioned effect, we need to leverage a concept called “homomorphic bindings.” Public chains like CKB and Cardano have their own extended UTXO models, which offer more programmability compared to UTXOs on the Bitcoin chain. “Homomorphic binding” is the idea of using the extended UTXOs on chains like CKB, Cardano, and Fuel as the “containers” for RGB asset data. The parameters of RGB assets are written into these containers and directly displayed on the blockchain. Whenever an RGB asset transaction occurs, the corresponding asset container can also exhibit similar characteristics, akin to the relationship between entities and shadows. This is the essence of “homomorphic binding.”

(Image source: RGB++ LightPaper)

For example, if Alice owns 100 RGB tokens and a UTXO (let’s call it UTXO A) on the Bitcoin chain, as well as a UTXO on the CKB chain marked with “RGB Token Balance: 100” and unlocked conditions associated with UTXO A:

If Alice wants to send 30 tokens to Bob, she can first generate a Commitment with the corresponding statement: transfer 30 RGB tokens associated with UTXO A to Bob and transfer 70 tokens to another UTXO controlled by herself.

Next, Alice spends UTXO A on the Bitcoin chain, publishes the above statement, and then initiates a transaction on the CKB chain. This transaction consumes the UTXO container holding 100 RGB tokens, creating two new containers: one holding 30 tokens (for Bob) and another holding 70 tokens (controlled by Alice). During this process, the task of verifying the validity of Alice’s assets and transaction statements is completed by consensus among nodes on networks like CKB or Cardano, without Bob’s involvement. At this point, CKB and Cardano act as the validation layer and DA (Data Availability) layer, respectively, under the Bitcoin chain.

(Image source: RGB++ LightPaper)

All individuals’ RGB asset data is stored on the CKB or Cardano chain, providing a globally verifiable characteristic that facilitates the implementation of DeFi scenarios such as liquidity pools and asset staking protocols. Of course, the above approach also sacrifices privacy. It essentially involves a trade-off between privacy and product usability. If you prioritize utmost security and privacy, you can switch back to the traditional RGB mode. If you don’t mind these trade-offs, you can confidently adopt the RGB++ mode, depending entirely on your personal needs. (In fact, leveraging the powerful functionality of public chains like CKB and Cardano, privacy transactions can be achieved through the use of ZK.)

It’s important to emphasize that RGB++ introduces a significant trust assumption: users need to optimistically believe that the CKB/Cardano chain or the network platform consisting of a large number of nodes through consensus protocol is reliable and error-free. If you don’t trust CKB, you can follow the interactive communication and verification process in the original RGB protocol by running your client yourself.

Under the RGB++ protocol, users can directly use their Bitcoin accounts to operate their RGB asset containers on the CKB/Cardano UTXO chains without the need for cross-chain transactions. They simply need to leverage the characteristics of UTXOs in the aforementioned public chains and set the unlock conditions of the Cell container to be associated with a specific Bitcoin address/UTXO. If the parties involved in RGB asset transactions trust the security of CKB, they may not even need to frequently publish Commitments on the Bitcoin chain. Instead, they can aggregate and send a Commitment to the Bitcoin chain after several RGB transfers have occurred. This is known as the “transaction folding” feature, which can reduce transaction costs.

It’s important to note that the “containers” used in homomorphic bindings need to be supported by public chains that use the UTXO model or have similar features in their state storage infrastructure. EVM-based chains are not very suitable for this purpose and may encounter many challenges. (This topic could be covered in a separate article, as it involves a lot of content. Interested readers can refer to previous articles by Geek Web3 titled “RGB++ and Homomorphic Bindings: How CKB, Cardano, and Fuel Empower the Bitcoin Ecosystem.“)

In summary, public chains or functionality extension layers suitable for implementing homomorphic bindings should have the following characteristics:

1. Utilize the UTXO model or similar state storage schemes.
2. Offer sufficient UTXO programmability, allowing developers to write unlock scripts.
3. Have a state space related to UTXOs that can store asset states.
4. Have Bitcoin-related bridges or light nodes available.

Disclaimer：

1. This article is reprinted from [极客 Web3], All copyrights belong to the original author [Faust]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.