A quick guide to RGB and RGB++ protocol design in a few minutes: a vernacular guide

Author: Faust, co-founder of Geekweb3 & BTCEden.org

With the hot issuance of RGB++ and related assets, the discussion on the principles of RGB and RGB++ protocols has gradually become a topic of concern for more people. But everyone realizes that to understand RGB++, you must first understand the RGB protocol.

The original RGB protocol is slightly obscure in terms of technical structure, and the reference materials are relatively scattered. There are not many systematic and easy-to-understand reference materials. Although Geekweb3 has previously published two systematic interpretation articles on RGB and RGB++ (you can see the history of our official account), according to feedback from community members, the aforementioned articles are too long and too brain-burning.

In order to make more people understand the RGB and RGB++ protocols faster, the author of this article rushed to complete a brief vernacular interpretation of RGB and RGB++ during the Hong Kong event. It can be read in a few minutes, hoping to help more community enthusiasts better and more intuitively understand RGB and RGB++.

RGB protocol: users must do data verification themselves

The RGB protocol is a special P2P asset protocol and a computing system under the Bitcoin chain. It is similar to a payment channel in some aspects: Users must run the client in person and verify the transfer behavior related to themselves (Verify by yourself). Even if you are just an asset receiver, you must first make sure that the transfer statement of the asset sender is correct before the transfer statement can take effect. Obviously, this is completely different from the traditional form of asset sending and receiving. We call it "interactive transfer".

Why is this so? The reason is that, in order to protect privacy, the RGB protocol does not adopt 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 is not easy to protect). If there is no consensus process involving a large number of nodes, how can we ensure that asset changes are safe? Here, the idea called "client verification" (Verify by yourself) is used. You have to run the client yourself and personally verify the asset changes related to you.

Suppose there is an RGB user named Bob, who knows Alice, and Alice wants to transfer 100 TEST tokens to Bob. After Alice generates the transfer information of "Alice to Bob", she must first send the transfer information and the asset data involved to Bob, and let him check it personally. Only when he is sure that it is correct will it enter the subsequent process and eventually become a valid RGB transfer. Therefore, the RGB protocol allows users to personally verify the validity of data, replacing the traditional consensus algorithm.

However, without consensus, the data received and stored by different RGB clients are inconsistent. Everyone only stores asset data related to themselves locally, and does not know the asset status of others. This protects privacy while also forming a "data island". If someone claims to have 1 million TEST tokens and wants to transfer 100,000 to you, how can you trust him?

In the RGB network, if someone wants to transfer money to you, you must ask him to show proof of assets first, trace back the historical source of the assets from initial issuance to multiple transfers, and confirm that there is no problem with the token to be transferred to you. This is like, when you receive banknotes of unknown origin, you ask the other party to explain the historical source of these banknotes and whether they are made by the designated issuer, so as to avoid counterfeit money.

（Image source: Coinex）

The above process takes place under the Bitcoin chain, and these processes alone cannot make RGB directly associated with the Bitcoin network. In this regard, the RGB protocol adopts the idea called "single use seal" to bind RGB assets to UTXO on the Bitcoin chain. As long as Bitcoin UTXO is not double-consumed, the bound RGB assets will not be double-spent, so that the Bitcoin network can be used to prevent the "Re-organization" 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 bound to Bitcoin UTXO, and Bob owns some Bitcoin UTXO. Alice wants to transfer 100 tokens to Bob. Before receiving the assets, Bob tells Alice in advance which Bitcoin UTXO of Bob should be used to bind these RGB assets.

（Image source: Geekweb3/ GeekWeb3）

2. Alice constructs an "Alice to Bob" RGB asset transfer data, and gives the historical sources of these assets to Bob for verification.

3. After Bob confirms that the data is correct locally, he sends a receipt to Alice, telling her that the transaction is OK.

4. Alice builds the RGB transfer data of "Alice to Bob" 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.

5. If someone wants to confirm in the future that the above "Alice to Bob" transfer really happened, he needs to do two things: obtain the complete transfer information of "Alice to Bob" under the Bitcoin chain, and then check whether there is a corresponding Commitment (hash of the transfer data) on the Bitcoin chain.

Bitcoin serves as the historical log of the RGB network, but the log only records the hash/Merkle root of the transaction data, rather than the transaction data itself. Due to the use of client verification and one-time sealing, the RGB protocol has extremely high security; Since the RGB network is composed of dynamic user clients in a P2P, non-consensus form, you can change the counterparty at any time, and there is no need to send the transaction request to a limited number of nodes, so the RGB network has a strong anti-censorship, and this organizational form is more censorship-resistant than large public chains such as Ethereum.

（Image source: BTCEden.org ）

Of course, the extremely high security, anti-censorship and privacy protection also come at an obvious cost:Users have to run the client to verify the data themselves. If the other party sends you some assets that have been transferred tens of thousands of times and have a long history, you have to verify them all under pressure;

In addition, each transaction requires multiple communications between the two parties. The receiver must first verify the source of the sender's assets, and then send a receipt to approve the sender's transfer request. In this process, at least three message transfers must be generated between the two parties. This kind of "interactive transfer" is seriously inconsistent with the "non-interactive transfer" that most people are used to. Can you imagine that someone wants to transfer money to you, and they have to send the transaction data to you for inspection, and only after getting your receipt message can the transfer process be completed? In addition, we have mentioned that the RGB network has no consensus, and each client is an isolated island, which is not conducive to migrating complex smart contract scenarios on traditional public chains to the RGB network, because the 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? This has become an issue that the RGB protocol cannot avoid.

RGB++: Client verification becomes optimistic custody

The protocol named RGB++ proposes a new idea. It combines the RGB protocol with public chains that support UTXO, such as CKB, Cardano, and Fuel. The latter serves as the verification layer and data storage layer of RGB assets, and transfers the data verification work originally performed by users to third-party platforms/public chains such as CKB. This is equivalent to replacing client verification with "third-party decentralized platforms for verification". As long as you trust public chains such as CKB, Cardano, and Fuel, if you don't trust them, you can also switch back to the traditional RGB mode.

RGB++ and the original RGB protocol are theoretically compatible with each other, and it is not a one-for-all.

To achieve the above-mentioned effects, we need to use an idea called "isomorphic binding". Public chains such as CKB and Cardano have their own extended UTXO, which is more programmable than the UTXO on the BTC chain. "Isomorphic binding" is to use the extended UTXO on the CKB, Cardano, and Fuel chains as "containers" for RGB asset data, write the parameters of RGB assets into these containers, and display them directly on the blockchain. Whenever an RGB asset transaction occurs, the corresponding asset container can also present similar characteristics, just like the relationship between an entity and a shadow. This is the essence of "isomorphic binding".

（Image source: RGB++ LightPaper）

For example, if Alice has 100 RGB tokens and UTXO A on the Bitcoin chain, and there is a UTXO on the CKB chain, this UTXO is marked with "RGB Token Balance: 100", and the unlocking condition is related to UTXO A.

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

After that, Alice spends UTXO A on the Bitcoin chain, publishes the above statement, and then initiates a transaction on the CKB chain to consume the UTXO container carrying 100 RGB tokens, generating two new containers, one for 30 tokens (for Bob) and one for 70 tokens (controlled by Alice). In this process, the task of verifying the validity of Alice's assets and the validity of the transaction statement is completed by consensus by network nodes such as CKB or Cardano, without the need for Bob to intervene. At this point, CKB and Cardano act as the verification layer and DA layer under the Bitcoin chain.

（Image source: RGB++ LightPaper）

All RGB asset data is stored on the CKB or Cardano chain, which has the characteristics of global verifiability, and is conducive to the realization of Defi scenarios, such as liquidity pools and asset pledge agreements. Of course, the above approach also sacrifices privacy. The essence is to make a trade-off between privacy and product usability. If you pursue extreme security and privacy, you can switch back to the traditional RGB mode; if you don’t care about these, you can rest assured to use the RGB++ mode, which depends entirely on your personal needs. (In fact, with the powerful functional completeness of public chains such as CKB and Cardano, private transactions can be achieved with the help of ZK)

It should be emphasized here that RGB++ introduces an important trust assumption: Users should be optimistic that the CKB/Cardano chain, or the network platform composed of a large number of nodes relying on consensus protocols, is reliable and correct.If you don't trust CKB, you can also follow the interactive communication and verification process in the original RGB protocol and run 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.You only need to use the characteristics of UTXO in the above public chains to set the unlocking conditions of the Cell container to be associated with a certain Bitcoin address/Bitcoin UTXO. If both parties of the RGB asset transaction trust the security of CKB, they don’t even need to frequently publish Commitments on the Bitcoin chain. They can aggregate and send a Commitment to the Bitcoin chain after many RGB transfers are completed. This is called the “transaction folding” function, which can reduce the cost of use.

But please note that the “container” used by isomorphic binding needs to support the public chain of the UTXO model, or an infrastructure with similar features in state storage. The EVM chain is not suitable and will encounter many pitfalls. (This topic can be written separately, and it involves a lot of content. Interested readers can refer to Geekweb3's previous article 《RGB++ and Isomorphic Binding: How CKB, Cardano and Fuel Empower Bitcoin Ecosystem》;

On the whole, the public chain/function extension layer suitable for implementing isomorphic binding should have the following characteristics:

1. Use the UTXO model or similar state storage solution;

2. Have considerable UTXO programmability, allowing developers to write unlocking scripts;

3. There is a UTXO-related state space that can store asset status; There is a Bitcoin-related bridge or light node; There is a Bitcoin-related bridge or light node;