Author: Shew & Faust, Geek web3

Advisors: CyberOrange, Unipass

Summary (long):

• The RGB protocol is a promising BTC expansion protocol, essentially a layer-2 off-chain computing system. It adopts a similar approach to the Lightning Network: users personally verify and authorize asset changes related to themselves (Verify by yourself), submitting the results/commitments approved by the transaction initiator to the Bitcoin chain.

• The RGB protocol utilizes a concept similar to colored coins and Mastercoin, associating "parasitic assets" with Bitcoin UTXOs. It stores the Commitment of off-chain transaction data on the Bitcoin chain, rather than publishing complete DA data like the Ordinals protocol. Based on the Commitment values recorded on the Bitcoin chain, the RGB client can verify whether the historical data provided by other clients is valid.

• Additionally, the hash/Commitment alone cannot reveal the underlying data, protecting privacy. Compared to plaintext, only submitting commitments to the chain can save space. From a third-party perspective, they do not know exactly what the RGB client has done.

• RGB also leverages the one-time spend characteristic of Bitcoin UTXOs, associating RGB asset ownership with Bitcoin UTXOs through a concept called "one-time sealing." This allows the strong security of Bitcoin to prevent double spending of RGB assets (as long as the Bitcoin UTXO is not double spent, the RGB assets will not be double spent).

• However, as a smart contract system implemented on the Bitcoin chain, RGB relies on different clients to store historical data locally, and different clients (users) only store data relevant to themselves, unable to see others' asset status. This "data island" protects privacy but presents challenges for large-scale adoption, resembling more of a P2P network composed of OTC traders.

• The concept of RGB++ is to use Cells on the CKB chain to express the ownership relationship of RGB assets. It moves the asset data originally stored locally in the RGB client to the CKB chain in the form of Cells, establishing a mapping relationship with Bitcoin UTXOs, allowing CKB to act as a public database for RGB assets and an off-chain pre-settlement layer, replacing the RGB client and achieving more reliable data hosting and RGB contract interaction. For other UTXO-based Layer2 solutions, this "homogeneous binding" is a trend.

• The RGB protocol itself only supports an interactive transfer process, requiring frequent communication between the transacting parties. This mode is not conducive to supporting DeFi scenarios and RGB asset issuance. After CKB replaces the independent client, it can achieve non-interactive RGB transactions, facilitating the implementation of DeFi and airdrop functions, and supporting the interaction between BTC assets and assets on the CKB chain without the need for cross-chain transactions.

• Essentially, RGB++ trades privacy for usability, bringing about scenarios that the RGB protocol cannot achieve. If users value product simplicity and completeness, they will favor RGB++. If they prioritize privacy and the security of "Verify by yourself," they will prefer the traditional RGB protocol. Ultimately, it depends on the user's own preferences. (In theory, privacy issues in RGB++ can also be addressed through methods such as ZK.)

Principles and Pros and Cons of the RGB Protocol

The RGB protocol itself is a rather complex solution. We will use a specific example of an RGB asset transfer to explain how the RGB protocol works.

Suppose there is a token, TEST, that complies with the requirements of the RGB protocol. Alice wants Bob to transfer 100 TEST tokens to her, in other words, she wants to initiate a transfer of tokens from Bob to Alice.

Here, it is important to note that the RGB protocol adopts the concept of "one-time sealing." On the surface, it appears that Bob is transferring tokens to Alice, but in reality, Bob controls the UTXO A on the Bitcoin chain, and UTXO A is associated with some RGB assets through certain methods.

If Bob declares that he wants to transfer a portion of the RGB assets associated with UTXO A to Alice, he can make the following declaration: transfer 30 TEST tokens associated with UTXO A to UTXO B. Since Alice is the owner of UTXO B, she then owns the associated 30 TEST tokens.

(Image Source: Discoco Labs)

In fact, the ownership records on the Bitcoin chain are all implemented through UTXOs. Declaring that UTXO B is eligible to control a certain amount of RGB assets is equivalent to saying that the owner of UTXO B can control a certain amount of RGB assets. This is unique to UTXO-based public chains like Bitcoin and differs from the account address model we are accustomed to.

With this understanding, let's examine the working process of the RGB protocol, which highlights the differences from colored coins and Mastercoin, and the parasitic assets of Bitcoin UTXOs:

1. According to the principles of the RGB protocol, Alice needs to issue an invoice for the transfer transaction, indicating her intent. The invoice includes the following information:

• Contract ID: Alice declares which RGB asset contract to interact with.
• Interface: Informs Bob of all the contract's interaction interfaces.
• Operation: Alice instructs Bob to call the contract interface.
• Status: The contract status that Bob needs to modify, in this case, the quantity of tokens Bob transfers to Alice.
• Seal: A UTXO used for one-time sealing, which can be understood as the UTXO Alice uses to accept Bob's authorization of RGB assets.

Finally, Alice will receive an invoice with the following content:

The above invoice follows the format below:

2. Alice needs to send the invoice to Bob. Bob will verify the invoice information and generate a new RGB transaction according to Alice's intent, transferring the RGB assets to Alice.

It is crucial to note that Bob must prove that he indeed has ownership of a portion of the TEST assets. This is because the RGB protocol defaults to "no globally visible asset state records" and does not use a public custodial contract to record and process everyone's assets, unlike Ethereum.

Under the RGB protocol, different clients only record asset data relevant to themselves, including the current balance and historical sources of these assets. The data recorded by each client is basically inconsistent. As a result, no one can confirm the asset status of others, so asset proof is required when engaging in P2P transactions.

A vivid analogy is that when trading with paper money, you don't know if the other party's money is counterfeit, so you ask them to clarify where the money came from and how many people have handled it, in order to judge if they are trying to deceive you with counterfeit money.

Once both parties mutually acknowledge, they can confidently proceed with the transaction. Each RGB transaction only requires mutual acknowledgment from the participants, making it completely P2P (similar to OTC).

Clearly, this model can protect privacy because everyone's asset status and transaction records are not easily known to outsiders. It's difficult for outsiders to know what you and your trading partner are doing. It's similar to how paper money can be more untraceable than bank transfers. However, this can also cause inconvenience in user experience.

In the earlier example of Alice and Bob, after Bob receives Alice's invoice and understands her intent, he needs to select the relevant historical transfer records related to the TEST assets from the local client's historical data. He then presents these records, along with the newly generated Bob -> Alice transfer, to Alice for verification, proving that the new RGB transaction/ownership change behind the assets is valid and accurate.

Generally, the data stored locally in the client is called "Stash," containing the past data of RGB assets. We can think of Stash as the log record of RGB asset contracts.

3. When Alice receives the data from Bob and the newly declared Bob -> Alice transaction, she verifies its validity. If the verification passes, Alice generates a "confirmation signature" and returns it to Bob.

4. After receiving Alice's confirmation signature, Bob broadcasts the Commitment corresponding to the Bob -> Alice transaction to the BTC network, ultimately writing it onto the BTC chain, giving it "finality."

If in the Bob -> Alice transfer, the owner of UTXO B is to have 30 TEST tokens, Alice only needs to prove that she is the owner of UTXO B to use these TEST tokens.

5. If in the future Alice wants to transfer the TEST tokens to someone else, when presenting the historical source of these TEST tokens, the recipient can verify based on the Commitment values on the Bitcoin chain to see if the data provided by Alice corresponds to the Commitment values on the chain. This prevents data forgery.

The advantage of the RGB protocol is its ability to support complex smart contract computations off-chain. Essentially, it moves the computation steps to the BTC chain, only recording Commitments on-chain. While protecting privacy, it declares the association between Bitcoin UTXOs and RGB asset ownership off-chain, utilizing Bitcoin to record and realize changes in RGB asset ownership.

Since all transaction declarations require verification and authorization by the parties involved, its security model is based on the "rational actor assumption." As long as the parties involved are rational and Bitcoin is secure, RGB asset ownership is "basically secure."

However, the drawbacks of the RGB protocol are also evident (previously mentioned as data islands and fragmented storage issues). Firstly, to transfer to others, or even to obtain the other party's consent and confirmation, both parties basically need to be online at the same time.

Secondly, due to the lack of a globally visible data recording method, even the contract deployment in RGB uses a very peculiar form. Contract users need to obtain information about the interface functions included in the contract in advance from the contract deployer, which can be done through email or scanning a QR code. (According to the official statement, it seems that posting the contract code on the official website or pinning it on Twitter can also work.)

Let's now discuss the contract state of the RGB protocol. In the RGB protocol, the initial state (Genesis) of the contract is set by the creator when the contract is created, such as the token name and total supply in the RBG-20 contract. Subsequently, the contract's state changes with the continuous progression of RGB transactions, but this contract state evolution is nonlinear, forming a directed acyclic graph (DAG).

For example, when Bob transfers to Alice, he only presents a narrow part of the data path containing the transfer records from the contract initialization to Bob obtaining the tokens. Similarly, Alice can only obtain the transaction information contained in this branch of the path, making it difficult to obtain the transfer information of others. While this protects the privacy of RGB users, it also brings adverse consequences: users find it difficult to obtain the global state of the RGB contract, such as how much RGB assets each person has. This can cause many problems.

For instance, when the Bob -> Alice transfer reaches the final step, and its Commitment value is written onto the BTC chain and becomes irreversible, Bob can delete some data locally. For example, if Bob has given all his TEST tokens to someone else, he can directly delete the locally stored TEST token-related data to reduce storage pressure.

As the recipient of the tokens, Alice needs to record all the data involved in this transaction locally. (If Bob deletes the locally stored TEST token data and Alice's client node is completely damaged due to an accident, then at this point, are Alice's assets permanently frozen? Because there is no other place to store Alice's TEST asset data, unless it was backed up in advance.)

This essentially boils down to DA and data storage issues, where the new data of the RGB protocol cannot be reliably and globally disseminated, ultimately causing different clients to become "data islands." This was previously seen in the thriving Ethereum ecosystem but was later abandoned in the Plasma solution due to the inability to solve the DA problem, ultimately resulting in failure.

Additionally, the RGB protocol requires a significant amount of communication between the two parties involved in the transaction, and many communication steps rely on centralized facilities. The details in this area are not yet mature, and the official even suggests that communication can be done through email.

It is quite apparent that the design of the RGB protocol is not very user-friendly for long-tail users who seek ease of use. While large holders with high privacy requirements may be willing to back up data and maintain client software, this burden is too heavy for long-tail users, posing a serious obstacle to widespread adoption. Up to now, most people believe that there have been no phenomenal RGB assets.

In the following figure, we provide a flowchart of the RGB asset transfer process, which readers can use to gain a deeper understanding of the overall transfer process based on this diagram.

In summary, the RGB protocol uses Bitcoin UTXOs to change the ownership of RGB assets and ensures that off-chain data cannot be tampered with by clients by publishing Commitments on the BTC chain. In fact, the so-called "one-time sealing" of RGB is achieved by associating Bitcoin UTXOs and RGB asset ownership through off-chain RGB transaction declarations, leveraging the strong security of Bitcoin to safeguard RGB assets. However, due to DA and data storage issues, the original RGB protocol has poor usability and UX, and assets are prone to freezing (unavailability) due to data loss.

RGB++: Enhanced RGB Protocol Based on CKB

In the previous section, we summarized the advantages and disadvantages of the RBG system, where client data islands and the inability to globally view contract states are the main factors affecting the usability of the RGB protocol.

In fact, the advantages and disadvantages of the RGB protocol are quite obvious. Those who prioritize privacy and security tend to run their own clients and back up data, but long-tail users clearly lack this patience (for example, most Lightning Network users rely on third-party nodes rather than running their own clients).

For this reason, Cipher, a co-founder of Nervos, proposed a solution called RGB++, attempting to delegate the asset status, contract deployment, and transaction verification of RGB to the CKB public chain. CKB acts as a third-party data hosting and computing platform, eliminating the need for users to run RGB clients themselves.

Since CKB itself is an extended UTXO model (Cell), it can write off-chain information of RGB assets into Cells and establish a one-to-one mapping relationship between Cells and Bitcoin UTXOs, realizing a data hosting and verification solution for RGB assets based on CKB to address the usability issues as a strong complement to the original RGB solution.

This paragraph may seem a bit convoluted, so let's further explain:

As mentioned earlier in the article, the RGB protocol essentially associates Bitcoin UTXOs and RGB asset ownership through on-chain commitments and off-chain declarations. However, the fragmented data of RGB asset contracts is stored locally in different clients, without a globally visible view.

RGB++ uses CKB's extended UTXO—Cell to directly display the mapping relationship between Bitcoin UTXOs and their corresponding RGB assets on the CKB chain. Additionally, CKB replaces the user's P2P client to verify the validity of each RGB transfer.

With such a globally visible record of RGB data, many scenarios that are difficult to implement in the RGB protocol will become easier to implement.

Some may immediately think of EVM. Can we use EVM to host the state and verification of RGB? The answer is: it's very troublesome because RGB assets are essentially parasitic on Bitcoin UTXOs and have a one-to-one mapping relationship with Bitcoin UTXOs. If we were to establish a mapping relationship between Bitcoin UTXOs and EVM contract data, it would not be smooth from a technical implementation standpoint, and it would be better to choose a UTXO-based public chain directly.

Furthermore, the "assets" on Ethereum are often public goods in a point-to-pool manner, where a contract records the assets of countless people, and the contract controller has absolute power. This asset handling method conflicts significantly with the design principles of Bitcoin UTXOs and the RGB protocol, which aim to completely privatize assets, with each person fully controlling their assets (think of the difference between paper money and WeChat Pay). There is no need to consider the perennial issues on Ethereum and EVM chains such as abuse of authority by asset contract owners, funds being compromised due to contract bugs, and the complexity of data migration for asset contracts.

Therefore, the best choice for expressing the mapping relationship between Bitcoin UTXOs and off-chain RGB assets is through a UTXO-based chain. CKB supports an extended UTXO—Cell, and CKB VM's instruction set is based on RISC-V, making it easier to accommodate different cryptographic algorithms, including Bitcoin's public-private key verification algorithm, compared to EVM. This makes it more conducive to implementing the technical solution proposed by RGB++.

Technical Implementation of RGB++

RGB++ utilizes CKB's extended UTXO—Cell. A Cell contains the following fields:

Capacity represents the size of the on-chain space that this Cell possesses, data refers to the data set contained within the Cell, which can be read or modified.

Type is the program code bound to this Cell, restricting the conditions for modifying the data. For example, if your Cell contains data for 100 TEST tokens, but you declare to transfer 110 TEST tokens to someone else, this does not comply with the restrictions specified in the Type and will be rejected.

Lock represents the ownership verification logic of the Cell, similar to the unlocking script of a Bitcoin UTXO.

We can understand a Cell as an upgraded version of UTXO, with the addition of the Type and Capacity fields, and the ability to customize the data type. As for the ownership change method of the Cell, it is similar to that of a Bitcoin UTXO, achieved through an unlocking script.

The idea behind RGB++ is to use Cells on the CKB chain to express the ownership relationships of RGB assets. It moves the asset data that was originally stored locally in RGB clients to the CKB chain in the form of Cells, allowing CKB to act as a public database for RGB assets. The Cells representing RGB assets will have a one-to-one mapping relationship with Bitcoin UTXOs on the Bitcoin chain, and this mapping relationship will be directly displayed in the Lock field of the Cell.

For example, suppose a certain RGB asset is associated with Bitcoin UTXO A. The corresponding mapping Cell can set its ownership verification conditions to be consistent with Bitcoin UTXO A (i.e., setting the Lock script to the unlocking condition of Bitcoin UTXO A). If you are the controller of UTXO A, you can directly operate the mapping Cell on CKB, and CKB will verify if you are the owner of UTXO A.

CKB will implement a Bitcoin light node on the chain, synchronizing Bitcoin block headers. When you declare an RGB transaction and need to operate the Cell corresponding to the RGB asset, you must first prove that you are the controller of Bitcoin UTXO A. The proof process consists of two steps:

1. Provide a Merkle Proof to the Bitcoin light node on CKB to demonstrate the existence of UTXO A on the Bitcoin chain.
2. Provide a digital signature to prove that you are the owner of UTXO A.

In the RGB++ solution, when a user declares an RGB asset transfer in the frontend, it triggers a transaction on the CKB chain to modify the Cell recording the RGB asset data and change its ownership. The original controller of Bitcoin UTXO 1, for example, may have owned this Cell, but after the ownership change, the controller of Bitcoin UTXO 2 becomes the new owner of the Cell. All of this is visible on the CKB chain.

It is important to note that the workflow related to commitments on the BTC chain still occurs on the BTC mainnet. This means that RGB++ still needs to publish Commitments on the Bitcoin chain to associate with the RGB asset transaction records on CKB. This step is no different from the traditional RGB protocol.

However, unlike the traditional RGB protocol where the client is responsible for off-chain work, RGB++ delegates these tasks to CKB. For example, the verification of asset sources by the transaction counterparty, the local storage of asset source data by the client, and the RGB contract deployment through third-party channels are all handled by CKB, relieving users from the burden of running their own clients.

This approach solves the problem of client data islands in RGB and also addresses the inability to globally view contract states. Additionally, RGB contracts can be directly deployed on the CKB chain, making them globally visible and available for reference by RGB Cells, thus avoiding the series of peculiar operations required for RGB protocol contract deployment.

In summary, CKB utilizes the programmability of Cell scripts to first verify that the initiator of the RGB transfer indeed owns the Bitcoin UTXO associated with the RGB asset. If the verification passes, the user is allowed to transfer the Cell recording the RGB asset data to someone else.

In simple terms, CKB acts as a public data hosting platform for RGB assets, providing data storage, globally visible contract deployment, ownership verification, and computing functions. In even simpler terms, CKB replaces the client in RGB and also solves other problems.

Of course, since RGB++ achieves globally visible data publishing, privacy is inevitably reduced compared to the RGB protocol. However, the benefit is a significant improvement in usability.

Therefore, RGB++ essentially trades privacy for usability while enabling scenarios that the RGB protocol cannot achieve. Users who value simplicity and completeness of functionality will favor RGB++, while those who prioritize privacy and security will prefer the traditional RGB protocol. Ultimately, it depends on the user's preferences. According to the RGB++ whitepaper, privacy transaction schemes can also be implemented on the CKB chain in the future to hide user identities and transaction amounts.

Additional Features of RGB++

Non-interactive Transactions (Very Important)

An important issue with the original RGB protocol is that the recipient must first send a message to the sender (the previously mentioned "cheque") to bind one's UTXO with the RGB asset before an ordinary transaction can be completed. This requires multiple rounds of interactive communication between the sender and recipient, increasing user understanding and product complexity. However, RGB++ leverages CKB as a data hosting and computing platform, allowing transactions to be completed between parties asynchronously and non-interactively.

When A transfers to B, A only needs to know B's address in advance and declare the transfer to that address. The recipient does not need to communicate online or provide data. Subsequently, the recipient can claim the assets themselves, and the script code on the CKB chain will verify if the recipient is the one specified by the sender. This mode is more in line with the habits of most people, and previously unsupported modes such as airdrops and reward distribution in the RGB protocol can also be implemented, which is beneficial for RGB asset issuance.

Additionally, the working mode of the RGB protocol is naturally not conducive to the development of DeFi scenarios. For example, typical multi-to-multi, non-interactive trading pools like Uniswap are almost impossible to implement in the original RGB protocol, but RGB++ enables non-interactive transactions with globally visible and verifiable states, allowing many DeFi scenarios to be implemented by using a "ownerless contract" in a Cell to meet certain conditions.

However, with an ownerless contract that anyone can modify, it is easy to encounter state contention/read-write conflicts, where multiple people want to modify the contract state simultaneously, leading to confusion. To address this issue, RGB++ plans to use an on-chain implemented Intent Cell as a "sorter" to prioritize different requests.

Transaction Folding (Aggregation of Commitments for Multiple Transactions)

Transaction folding is the aggregation of a batch of transactions into a single Commitment, which is then published on the Bitcoin chain. This process is illustrated in the following flowchart:

Direct Interaction between BTC Assets and CKB Chain Assets without Cross-Chain Operations

After RGB++ establishes the mapping relationship between Bitcoin UTXOs and CKB Cells, it can directly achieve interoperability between assets without the need for cross-chain operations. Through RGB++ transaction declarations, you can transfer your Bitcoin UTXO to someone else, and the recipient can transfer their CKB asset ownership to you. This mode has great potential and, combined with the previously mentioned transaction folding (batch transactions), can theoretically achieve interoperability between BTC and CKB chain assets without the need for BTC asset cross-chain operations.

Conclusion

RGB++ directly expresses the asset data stored locally in different RGB clients using Cells on the CKB chain and associates Cells with Bitcoin UTXOs on the Bitcoin chain. Users can interact with their RGB++ assets on the CKB chain through their Bitcoin accounts/assets. This approach is relatively simple and solves the problems of prior communication between both parties, the inability to support globally visible states, fragmented data storage, and the unfriendliness of smart contracts and DeFi in the RGB protocol.

RGB++ achieves interoperability between BTC and CKB assets without the need for cross-chain operations, making it suitable for combining RGB assets with DeFi scenarios and significantly addressing the usability issues of the RGB protocol. However, for RGB enthusiasts who prioritize high privacy, RGB++ essentially trades privacy for usability, and it ultimately depends on the user's preferences. In theory, privacy issues can be addressed on the CKB chain by introducing methods such as ZK.

Overall, RGB++ demonstrates the potential of CKB as a settlement layer/computing layer under the Bitcoin chain, and this approach is likely to be adopted by more Bitcoin Layer2 or asset protocols in the future. It is foreseeable that the competition between third-party settlement layers under the Bitcoin chain will soon unfold. With its focus on POW, UTXO, and years of technical accumulation, CKB may be able to demonstrate its technological advantages in this modular blockchain competition.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。