白话说明书：一文读懂RGB与RGB++协议设计

Original author: Faust, Geek web3 BTCEden.org Lianchuang (X: @faustliu1997)

Original source:Geek Web3

With the popularity of the issuance of RGB++ and related assets, the discussion on the principles of RGB and RGB++ protocols has gradually become a topic of concern to 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 scattered. There are not many systematic and easy-to-understand reference materials so far. Although geek web3 has previously published two systematic interpretation articles about RGB and RGB++ ( You can see the history of our official account), but according to feedback from community members, the aforementioned article is too long and too brain-burning.

In order to allow more people to understand the RGB and RGB++ protocols faster, the author of this article rushed to complete a short vernacular interpretation of RGB and RGB++ during the event in Hong Kong. It can be read in a few minutes and hopes to help more community interests. Readers can 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 off the Bitcoin chain. It is similar to a payment channel in some aspects: users have 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 senders 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 is this 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 goes 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 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 to make sure it is correct before entering the subsequent process, and finally it becomes a valid RGB transfer. Therefore, the RGB protocol allows users to personally verify the validity of data, replacing the traditional consensus algorithm.

But there is no consensus, and the data received and stored by different RGB clients is 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 believe him?

In the 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 OK. This is like when you receive When you receive unidentified banknotes, you ask the other party to explain the historical origin 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 off the Bitcoin chain, and these processes alone do not allow RGB to have a direct connection with 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 doubled. Payment, so that the Bitcoin network can be used to prevent Re-organization of RGB assets. Of course, this requires issuing 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 certain Bitcoin UTXOs. Alice wants to transfer 100 tokens to Bob. Before receiving the assets, Bob tells Alice in advance which of Bobs Bitcoin UTXOs should be used to bind these RGB assets.

(Image source: Geek web3/ Geek Web3)

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

• After Bob locally confirms that the data is OK, he sends a receipt to Alice, telling her that the transaction can go through.

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

• If someone wants to confirm in the future that the above-mentioned transfer of Alice to Bob 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 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, 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, without Transaction requests are sent to a limited number of nodes, so the RGB network is extremely censorship-resistant. This organizational form is more censorship-resistant than large public chains such as Ethereum.

(Image source: BTCEden.org)

Of course, the cost of extremely high security, censorship resistance, and privacy protection is also obvious: users have to run the client to verify the data themselves. If the other party sends some assets that have changed hands tens of thousands of times and have a long history, you You also have to verify everything under pressure;

In addition, each transaction requires multiple communications between the two parties. The receiving party must first verify the source of the senders assets and then send a receipt to approve the senders 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 that if someone wants to transfer money to you, they have to send you the transaction data to check and get your receipt? Can the transfer process be completed only after receiving the message?

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 traditional public chains to the RGB network because the Defi protocols on Ethereum or Solana all rely 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 validation becomes optimistic hosting

The protocol called RGB++ puts forward 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 performed by users The verification work 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., if you If you dont 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, you 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 Alices assets and the validity of the transaction statement is completed by network nodes such as CKB or Cardano through consensus, without Bobs intervention. At this time, CKB and Cardano serve as the verification layer and DA layer under the Bitcoin chain.

(Image source: RGB++ LightPaper)

Everyones RGB asset data is stored on the CKB or Cardano chain, which has globally verifiable characteristics and is conducive to the implementation of Defi scenarios, 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 dont care about this, you can safely use RGB++. The mode 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 realize private transactions)

It should be emphasized here that RGB++ introduces an important trust assumption: users must 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 dont 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 Bitcoin accounts to operate their own 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. Just set it to be associated with a certain Bitcoin address/Bitcoin UTXO. If both parties to the RGB asset transaction trust the security of CKB, they do not even need to frequently publish Commitments on the Bitcoin chain. After many RGB transfers are completed, they can then send a Commitment to the Bitcoin chain. This is called transaction folding. ” function can reduce usage costs.

However, it should be noted that 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 articleRGB++ and Isomorphic Binding: How CKB, Cardano and Fuel Empower the Bitcoin Ecosystem；

Taken together, a public chain/function expansion layer suitable for implementing isomorphic binding should have the following characteristics:

• Use UTXO model or similar state storage scheme;

• It has considerable UTXO programmability, allowing developers to write unlocking scripts;

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

• There are Bitcoin-related bridges or light nodes;