Vernacular instructions:

Understanding RGB and RGB++ protocol design in one article

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. However, everyone realizes that to understand RGB++, you must first understand the RGB protocol.

The original RGB protocol is somewhat obscure in terms of technical structure, and the reference materials are relatively scattered. So far, there are not many systematic and easy-to-understand reference materials.

RGB protocol: users need to verify data 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 need to run the client themselves 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 asset sender's transfer statement 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 necessary? 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, an 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 "Alice to Bob" transfer information, she must first send the transfer information and the asset data involved to Bob, and let him check it personally. Only after confirming 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 the data, replacing the traditional consensus algorithm.

But without consensus, the data received and stored by different RGB clients are inconsistent. Everyone only stores their own asset data 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 the token to be transferred to you is correct. 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.

The above process takes place under the Bitcoin chain, and these processes alone cannot directly link RGB to the Bitcoin network. In response to this, the RGB protocol adopts an idea called "single use seal" to bind RGB assets to UTXO on the Bitcoin chain. As long as the Bitcoin UTXO is not double-spent, the bound RGB assets will not be double-spent. In this way, the Bitcoin network can be used to prevent the "re-organization" of RGB assets. Of course, this requires publishing a Commitment on the Bitcoin chain and using the OP_Return opcode.

Here is a summary of the workflow of the RGB protocol:

1. RGB assets are bound to Bitcoin UTXOs, and Bob owns some Bitcoin UTXOs. 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.

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

* After Bob confirms that the data is correct locally, he sends a receipt to Alice, telling her that the transaction can be approved.

* Alice constructs 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.

* If someone wants to confirm in the future that the above "Alice to Bob" transfer actually 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 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 verification and one-time sealing, the RGB protocol has extremely high security; because 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 extremely strong anti-censorship, and this organizational form is more censorship-resistant than large public chains such as Ethereum.

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. During this process, at least three messages must be transmitted between the two parties. This "interactive transfer" is seriously inconsistent with the "non-interactive transfer" that most people are accustomed 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 receiving 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 a problem that the RGB protocol cannot avoid.

RGB++: Client-side validation becomes optimistic hosting

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 platform verification". As long as you trust public chains such as CKB, Cardano, Fuel, etc., if you don’t trust them, you can also switch back to the traditional RGB mode.

Theoretically, RGB++ and the original RGB protocol are compatible with each other, and it is not that one must be exclusive of the other.

To achieve the effects mentioned above, 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".

For example, suppose Alice owns 100 RGB tokens and UTXO A on the Bitcoin chain. She also has a UTXO on the CKB chain, which is marked with "RGB Token Balance: 100". The unlocking condition is related to UTXO A.

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

Afterwards, 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 of network nodes such as CKB or Cardano, without the intervention of Bob. At this point, CKB and Cardano act as the verification layer and DA layer under the Bitcoin chain.

Everyone's RGB asset data is stored on the CKB or Cardano chain, which has the characteristics of global verifiability, which 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, ZK can be used to achieve private transactions)

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 the consensus protocol, is reliable and correct. If you do not 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. They 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 issue Commitments on the Bitcoin chain. After many RGB transfers are completed, a Commitment can be aggregated and sent to the Bitcoin chain. This is called the "transaction folding" function, which can reduce the cost of use.