Speed Pass RGB and RGB++ Protocol Design: Vernacular Instructions

Original title: "A quick guide to the design of RGB and RGB++ protocols in a few minutes: a plain language manual"

Original author: Faust, co-founder of Geek web3 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 Geek web3 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 understand RGB and RGB++ better and more intuitively.

RGB protocol: users must do data verification themselves

RGB protocol is a special P2P asset protocol, a computing system under the Bitcoin chain, which is similar to payment channels in some aspects: users must 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 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 sending and receiving assets. 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 we use the idea called "client verification" (Verify by yourself). 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 verify the validity of the data themselves, replacing the traditional consensus algorithm.

But without consensus, the data received and stored by different RGB clients are inconsistent. Everyone only stores the 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 believe him?

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

(Image source: Coinex)

The above process occurs under the Bitcoin chain, and these processes alone cannot make RGB directly associated with the Bitcoin network. In response to this, the RGB protocol adopts the 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, so that 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 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: Geek web3/ GeekWeb3）

1. Alice constructs an RGB asset transfer data of "Alice to Bob", and gives it to Bob to verify with the historical source of these assets.

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

3. 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.

4. If someone wants to confirm in the future that the above "Alice to Bob" transfer really happened, he needs to do two things: get the complete transfer information of "Alice to Bob" under the Bitcoin chain, and then check whether there is a corresponding Commitment (hash of 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, 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.

（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 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 verification becomes optimistic custody

The protocol called 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 for 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 that one is the other and the other is not the other.

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, which is the essence of "isomorphic binding".

（Image source: RGB++ LightPaper）

For example, suppose Alice has 100 RGB tokens and UTXO A on the Bitcoin chain. At the same time, she has 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 under her control.

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 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.

（Image source: RGB++ LightPaper）

All 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 condition of the Cell container to be associated with a certain Bitcoin address/Bitcoin UTXO. If both parties of RGB asset transactions 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 Geek web3’s previous article "RGB++ and Isomorphic Binding: How CKB, Cardano and Fuel Empower the Bitcoin Ecosystem";

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

· Use the UTXO model or similar state storage solution;

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

· There is a UTXO-related state space that can store asset status;

· There is a Bitcoin-related bridge or light node;

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia