Quickly pass RGB and RGB++ protocol design in a few minutes:plain instructions

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 need to run the client themselves and verify their own transfer behavior (Verify by yourself). Even if you are just an asset recipient, you must first make sure there are no errors in the asset sender’s transfer statement 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 should this be so? The reason is that in order to ensure privacy, the RGB protocol does not adopt the “consensus protocol” in traditional blockchains such as Bitcoin and Ethereum.(Once the data passes through the consensus protocol, it will be observed by almost all nodes in the network, and privacy is not guaranteed). How to ensure that asset changes are safe without a consensus process involving a large number of nodes? The idea called “Client Verification” (Verify by yourself) is used here.You need 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 to make sure it is correct before entering the subsequent process, and finally it becomes a valid RGB transfer. In this way, the RGB protocol allows users to personally verify the validity of 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. While protecting privacy, this also constitutes a “data island”. If someone claims to have 1 million TEST tokens and wants to transfer 100,000 to you, how can you believe it? In RGB network, if someone wants to transfer money to you, he must first show proof of assets, trace back the historical source of the assets from initial issuance to multiple changes of hands, and make sure that the Token to be transferred to you is clean.This is like when you receive banknotes of unknown origin and you ask the other party to explain the historical source of these banknotes and whether they were made by the designated issuer, so as to avoid counterfeit currency.

(Image source: Coinex)

The above processes occur under the Bitcoin chain, and these processes alone cannot make RGB directly related to the Bitcoin network. In this regard,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-consumed, the bound RGB assets will not be double-spended. In this way, the Bitcoin network can be used to prevent “Re-organization” of RGB assets. Of course, this Commitment needs to be published on the Bitcoin chain and the OP_Return opcode is used.

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

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

(Image source: Geekweb3/GeekWeb3)

1. Alice constructs a “Alice to Bob” RGB asset transfer data, along with the historical sources of these assets, and gives them to Bob for verification.
2. After Bob locally confirms that the data is OK, he sends a receipt to Alice, telling her that the transaction can go through.
3. 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 the Commitment as the hash of the transfer data.
4. If someone wants to confirm in the future that the above-mentioned “Alice to Bob” transfer actually occurred, 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 transaction on the Bitcoin chain Commitment (hash of transfer data), that’s it.

Bitcoin here acts as the historical log of the RGB network, but only the hash/Merkle root of the transaction data is recorded in the log.rather than the transaction data itself. Thanks to client-side validation and one-time sealing,The RGB protocol has extremely high security;Since the RGB network is composed of dynamic user clients in a P2P, consensus-free form, you can change the counterparty at any time without sending transaction requests to a limited number of nodes, soRGB networks are extremely censorship resistant, this organizational form is more resistant to censorship than large public chains such as Ethereum.

(Image source: BTCEden.org)

Certainly,extremely high security, censorship resistance, and privacy protection come with obvious costs:Users have to run the client to verify the data themselves. If the other party sends you some assets that have changed hands 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 receiving party 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 passed 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 someone wanting to transfer money to you, but they must send you the transaction data for verification, 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 island, which is not conducive to migrating complex smart contract scenarios on the traditional public chain to the RGB network, because the Defi protocol on Ethereum or Solana relies on A globally visible and data-transparent ledger. How to optimize the RGB protocol, improve user experience and solve the above problems? This has become an unavoidable problem for the RGB protocol.

RGB++: Client-side 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 converts data originally processed by users into the verification work and is handed over to third-party platforms/public chains such as CKB. This is equivalent to replacing client verification with “third-party decentralized platform for verification”, as long as you trust public chains such as CKB, Cardano, Fuel, etc.. Even if you don’t trust them, you can also switch back to traditional RGB mode.

RGB++ and the original RGB protocol are theoretically compatible with each 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 show similar characteristics, just like the relationship between entities and shadows.This is the essence of “isomorphic binding”.

(Image source: RGB++ LightPaper)

For example, if Alice owns 100 RGB tokens and UTXO A on the Bitcoin chain, and also has a UTXO on the CKB chain, this UTXO is marked with “RGB Token Balance: 100”, and the unlocking conditions are related to UTXO A.

If Alice wants to send 30 tokens to Bob, she can first generate a Commitment. The corresponding statement is: transfer 30 of the RGB tokens associated with UTXO A to Bob, and transfer 70 to other UTXOs she controls.

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 and generate two new containers, one holding 30 tokens ( to Bob), one holds 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 network nodes such as CKB or Cardano through consensus, without Bob’s intervention. At this time, CKB and Cardano serve as the verification layer and DA layer under the Bitcoin chain.

(Image source: RGB++ LightPaper)

Everyone’s RGB asset data is stored on the CKB or Cardano chain, which has globally verifiable characteristics and is conducive to the implementation of Defi, such as liquidity pools and asset pledge protocols. Of course, the above approach also sacrifices privacy. The essence is to make a trade-off between privacy and product ease of use. If you pursue ultimate security and privacy, you can switch back to the traditional RGB mode; if you don’t care about this, you can safely use the RGB++ mode, it all depends on your personal needs. (In fact, with the powerful functional completeness of public chains such as CKB and Cardano, ZK can be used to implement 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 consensus protocols, is 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 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.Just make use of the characteristics of UTXO in the above public chain and set the unlocking condition of the Cell container to be associated with a certain Bitcoin address/Bitcoin UTXO. If both parties involved in RGB asset transactions can trust the security of CKB, they won’t even need to issue Commitments frequently on the Bitcoin chain.After many RGB transfers are made, a Commitment can be sent to the Bitcoin chain. This is called the “transaction folding” function., which can reduce usage costs.

But be careful,The “container” used in isomorphic binding needs a public chain that supports the UTXO model, or an infrastructure with similar characteristics in state storage. The EVM chain is not suitable and will encounter many pitfalls.(This topic can be written separately and involves a lot of content. Interested readers can refer to Geek Web3’s previous articles.“RGB++ and Isomorphic Binding: How CKB, Cardano and Fuel Empower the Bitcoin Ecosystem”；

in summary,A public chain/function expansion layer suitable for realizing isomorphic binding should have the following characteristics:

1. Use UTXO model or similar state storage scheme;
2. Has considerable UTXO programmability, allowing developers to write unlocking scripts;
3. There is a UTXO-related state space that can store asset status;
4. There are Bitcoin-related bridges or light nodes;

Disclaimer:

1. This article is reproduced from [Geek Web3], the original title is “RGB and RGB++ protocol design in a few minutes: plain instructions”, the copyright belongs to the original author [Faust], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team. Without referencing Gate.io, copying, distributing, or plagiarizing the translated articles is prohibited.