Author: Shew & Faust, geek web3

Summary (longer):·The RGB protocol is a relatively promising BTC expansion protocol. It is essentially an off-chain computing system that uses the Lightning Network. Similar idea: users personally verify and authorize asset changes related to themselves (Verify by yourself), and submit the results/commitments approved by the transaction initiator to the Bitcoin chain.

·The RGB protocol uses ideas similar to those of colored coins and Mastercoin, and is associated with Bitcoin UTXO "Parasitic Assets". It stores the Commitment "commitment" of off-chain transaction data on the Bitcoin chain, instead of publishing complete DA data like the Ordinals protocol. Based on the commitment value recorded on the Bitcoin chain, the RGB client can verify whether the RGB historical data provided by other clients is valid.

·At the same time, hash/Commitment alone cannot restore the original image behind it, and the outside world cannot directly observe the chain. Upload the off-chain data corresponding to the commitment value, which can protect privacy. Compared with the inscription, only putting the promise on the chain can save space. From a third party's perspective, he actually doesn't know what the RGB client does.

·RGB also takes advantage of the one-time spending feature of Bitcoin UTXO, and associates RGB asset ownership with Bitcoin UTXO through an idea called "one-time sealing" stand up. This can take advantage of the strong security of Bitcoin to avoid "double spending/double spending" of RGB assets (as long as Bitcoin UTXO is not double spent, RGB assets will not be double spent).

·But RGB, as a smart contract system implemented under the Bitcoin chain, relies on different customers The client stores historical data locally, and different clients (users) only store data related to themselves and cannot see the asset status of others. Although this "data island" protects privacy, it also makes RGB face trouble in large-scale adoption, making it more like a P2P network composed of OTC traders.

·The idea 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 on the RGB client to the CKB chain and expresses it in the form of Cell, establishing a mapping relationship with Bitcoin UTXO, allowing CKB to act as a public database and off-chain pre-settlement layer for RGB assets. Replaces the RGB client to achieve more reliable data hosting and RGB contract interaction. For other UTXO-based Layer 2, this "isomorphic binding" is a trend.

·The RGB protocol itself only supports interactive transfer processes. Both parties to the transaction need to communicate frequently. This model is difficult to support Defi scenarios and is not conducive to the issuance of RGB assets. After CKB replaces the independent client, it can realize non-interactive RGB transactions, which is conducive to functions such as Defi landing and airdrops, and supports BTC assets without cross-chain interaction with assets on the CKB chain.

·The essence of RGB++ is to trade privacy for ease of use, while bringing about scenarios that cannot be achieved by the RGB protocol. If users value the ease of use and complete functions of the product, they will favor RGB++. If they pursue privacy and the security of Verify by yourself, they will favor the traditional RGB protocol. It all depends on the user's own choice. (Theoretically, RGB++ can also solve privacy issues through ZK and other methods)

The principles of the RGB protocol and its advantages and disadvantages

The RGB protocol itself is a relatively complex solution. Let’s take a specific RGB asset transfer as an example to explain RGB to everyone. How the protocol works.

Suppose there is a token that meets the requirements of the RGB protocol, called TEST. Alice hopes that Bob will transfer 100 TEST tokens to herself. In other words, she hopes to generate a token transfer from Bob to Alice.

Let me explain here first. The RGB protocol adopts an idea called "one-time encapsulation". On the surface, it is said that Bob transfers money to Alice. What actually means is that Bob controls 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 part of the RGB assets associated with UTXO A to Alice, he can declare as follows: transfer the 30 associated with UTXO A TEST tokens are transferred to UTXO B for association. Since Alice is the owner of UTXO B, she owns the associated 30 TEST tokens.

(Source: Discoco Labs)

In fact, the ownership recording method on the Bitcoin chain is through UTXO Realized, stating that UTXO B is qualified to control xx amount of RGB assets is equivalent to saying that the owner of UTXO B can control xx amount of RGB assets. This is not consistent with the account address model we are used to, and is unique to UTXO public chains such as Bitcoin. Unique attributes.

After understanding this, let’s examine the workflow of the RGB protocol, and we can feel the difference between it and Bitcoin UTXO parasitic assets such as colored coins and Mastercoin:< /p>

1.According to the principles of the RGB protocol, Alice must first issue an invoice for the transfer transaction and indicate her intention. The invoice contains the following information:

Contract id:Alice declares which RGB asset contract she wants to interact with

Interface: Let Bob know all the interactive interfaces of the contract

Operation:The name of the contract interface that Alice asks Bob to call

Status:The contract status that Bob needs to modify, in this case it is the number of tokens that Bob transfers to Alice

Seal: UTXO used for one-time sealing. It can be simply understood as the UTXO used by Alice to accept Bob's RGB asset authorization.

Finally, Alice will get the following invoice content:

< img src="https://img.jinse.cn/7180016_image3.png">

The above invoice follows the following format:

2.Alice needs to send the above invoice to Bob. Bob will check the invoice information, generate a new RGB transaction according to Alice's intention, and transfer the RGB assets to Alice.

But special attention should be paid here. Bob must try to prove that he does have partial ownership of the TEST assets. As for why this is done, it is because the RGB protocol defaults to "no globally visible asset status records" and does not use a public custody contract to record and process everyone's assets like Ethereum does.

Under the RGB protocol, different clients only record asset data related to themselves, including the current balance and historical sources of these assets. The data recorded by each client is basically inconsistent. In this way, everyone cannot confirm the asset status of others, so asset certificates must be presented during P2P transactions.

To use a vivid metaphor, you and the other party are using banknotes to trade, but you don’t know whether the other party’s banknotes are yours. If you print counterfeit money, ask him to tell you clearly where he got the banknotes from and how many people they have changed hands with, so as to determine whether the other party is using counterfeit money to fool you.

After both parties recognize each other, they can make bold transactions with confidence. Each RGB transaction only requires the parties to recognize each other. It is completely P2P (similar to OTC).

Obviously, this model can protect privacy, because everyone's asset status and transaction records will not be easily known to the outside world. It is difficult for outsiders to know what has been done with the counterparty. The logic is that banknotes can be concealed better than bank transfers. But obviously, this will also cause inconvenience in the user experience.

In the case of Alice and Bob mentioned earlier, after Bob receives Alice's invoice and learns her intention, he needs to obtain the invoice from the local client. From the historical data, select the historical transfer records related to the TEST asset, together with the newly generated Bob -> Alice transfer, and hand them to Alice for verification to prove the new RGB transaction/ownership change, and the corresponding source of asset ownership behind it is Valid and error-free.

Generally speaking, the data stored locally on the client is called Stash "collection", which contains past data of RGB assets. We can think of Stash as the log record of the RGB asset contract.

3.When Alice receives the data from Bob and the newly declared Bob—> after Alice’s transaction, its validity will be verified,If the verification passes, Alice will generate a "confirmation signature" and return it to Bob.

4.After Bob receives Alice’s confirmation signature, he sends Bob —> Alice The Commitment corresponding to the transaction is broadcast to the BTC network and finally written to the BTC chain, making it "final".

(The structure diagram of Commitment is actually a merkle root)

If Bob—>Alice During the transfer, it is stated that the owner of UTXO B will own 30 TEST tokens. Alice can use these TEST tokens as long as she proves that she is the owner of UTXO B.

5.If Alice wants to transfer TEST tokens to others in the future, she should show the historical source of these TESTs At this time, the other party can verify based on the commitment value on the Bitcoin chain to see whether the data provided by Alice corresponds to the commitment value on the chain. This prevents falsification of data.

The benefit of the RGB protocol is that it can support complex smart contract calculations off-chain. It essentially moves the calculation steps off the BTC chain and only records the Commitment on the chain. While protecting privacy, it declares the difference between Bitcoin UTXO and RGB asset ownership off the chain. Association, using Bitcoin to burn and achieve ownership changes of RGB assets.

Since all transaction statements need to be verified and authorized by the parties, its security model is based on the "rational person assumption",< /strong>As long as the parties involved are rational and as long as Bitcoin is safe, RGB asset ownership is "basically safe."

But the shortcomings of the RGB protocol are also obvious (the issues of data islands and fragmented storage were mentioned earlier) . First of all, if you want to transfer money to another person, you must even obtain the other party’s consent and confirmation first, and both parties must be online at the same time;

Secondly, due to the lack of globally visible data recording methods, RGB’s contract publishing even adopts a very strange form. Contract users must obtain the information from the contract publisher in advance. At this point, you can learn the interface functions contained in the contract. The specific method of learning can be through email or scanning the QR code. (Looking at the current official rhetoric, it is estimated that the contract code can be posted on the homepage of the official website or pinned to the top of Twitter)

Let’s discuss the contract status 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, total amount, etc. in the RBG-20 contract. Then,the status of the contract changes with the continuous progression of RGB transactions, but this contract status evolution is non-linear, forming a directed acyclic graph DAG.

(In the picture, owner1’s field of view is the blue and green parts, Owner2’s field of view is the blue and yellow parts)

For example, when Bob transfers money to Alice, only part of the transfer record from contract initialization to Bob obtaining the token is shown, and the data path included is relatively narrow. Alice can only know the transaction information contained in this path branch, and it is difficult to know other people's transfer information. Although this protects the privacy of RGB users, it also bringsundesirable consequences: it is difficult for users to know the global status of the RGB contract, such as how many RGB assets each person has. This can cause a lot of trouble.

For example, when Bob —> Alice’s transfer reaches the final step, its commitment value is written to the BTC chain and After it is irreversible, Bob can delete some data locally - if Bob gives all his TEST tokens to others, he can directly delete the data related to the TEST tokens stored locally to reduce storage pressure.

As the recipient of the token, Alice needs to record all the data involved in this transaction locally. (If Bob deletes the local TEST token data and Alice’s client node is completely damaged due to an accident, will Alice’s assets be permanently frozen at this time? Because there is no other place Store Alice's TEST asset data, unless it is backed up in advance.)

This can essentiallybe attributed to DA and data storage issues ,That is, the new data of the RGB protocol cannot be disseminated in a reliable and globally visible way, which will eventually cause different clients to become "data islands." The Plasma solution, which had previously flourished in the Ethereum ecosystem but was later abandoned, was stillborn because it could not solve the DA problem.

In addition, the RGB protocol also requires a lot of communication between the two parties to the transaction, many communication steps rely on centralized facilities , the detailed description in this area is not yet mature, and the official even said that communication can be carried out through email.

Obviously, the design of the RGB protocol is not very friendly to long-tail users who pursue ease of use.Although large users with more assets and higher pursuit of privacy will be happy to do data backup and client maintenance, for long-tail users, these burdens are still too heavy and will seriously hinder large-scale adoption. Even so far, most people believe that there are no phenomenal RGB assets.

In the figure below, we give a flow chart of RGB asset transfer. Readers can have a deeper understanding of the overall transfer process based on this figure.

In short, the RGB protocol uses Bitcoin UTXO to realize the ownership change of RGB assets, and by publishing the commitment value (Commitment) on the BTC chain, it ensures that the off-chain data cannot be tampered with by the client privately. . In fact, RGB's so-called "one-time seal" is to associate Bitcoin UTXO and RGB asset ownership through off-chain RGB transaction statements, thereby ensuring the security of RGB assets with the help of Bitcoin's powerful security . However, due to DA and data storage issues, the usability and UX of the original RGB protocol are relatively poor, and assets are easily frozen (unusable) due to data loss.

RGB++: an enhanced version of the RGB protocol based on CKB

In the above, we summarized the advantages and disadvantages of the RBG system. Among them, the client data island and the contract status cannot be globally visible, which constitute the most important factors affecting the ease of use of the RGB protocol.

In fact, the RGB protocol has obvious advantages and disadvantages, and has a higher pursuit of privacy and security. People will tend to run the client themselves and make data backups, but long-tail users obviously do not have this patience (for example, most Lightning Network users will rely on third-party nodes instead of running the client themselves).

Based on this reason, Nervos Lianchuang Cipher proposed a plan called RGB++, trying to release RGB's asset status and contracts Transaction verification is entrusted to the CKB public chain. CKB acts as a third-party data hosting and computing platform,no longer requiring users to run the RGB client themselves.

Since CKB itself is an extended UTXO model (Cell), the off-chain information of RGB assets can be written into the Cell and A one-to-one mapping relationship is established between Cell and Bitcoin UTXO to implement a CKB-based RGB asset data custody and verification solution to solve the ease-of-use problem and serve as an enhanced supplement to the original RGB solution.

This passage may be a bit confusing to read, so let’s explain it further:

As mentioned earlier in the article, the essence of the RGB protocol is to link Bitcoin UTXO and RGB asset ownership by issuing on-chain commitments and off-chain statements. However, the data of the RGB asset contract is fragmented and stored locally on different clients, without a globally visible view.

RGB++ uses CKB's expanded version of UTXO - Cell to map the relationship between Bitcoin UTXO and the corresponding RGB assets. , displayed directly on the CKB chain, and the CKB public chain replaces the user's P2P client to verify the validity of each RGB transfer.

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

(The transaction process of RGB++ is to write the RGB asset information into the Cell, then associate the Cell with the Bitcoin UTXO, and finally combine the RGB++ transactions that occurred on CKB and the RGB++ assets associated with them. Bitcoin UTXO, included in the commitment, and then write the commitment value to the Bitcoin chain)

Maybe someone The first thing that came to mind was EVM. Can we use EVM to carry RGB state and validation? The answer is: It’s very troublesome, because RGB assets are essentially parasitic on Bitcoin UTXO and have a 1-to-1 mapping relationship with Bitcoin UTXO. If you want to establish a mapping relationship between Bitcoin UTXO and EVM contract data, the technical implementation is not smooth. It is better to directly choose a UTXO public chain.

Moreover, the "assets" on Ethereum are often public goods in peer-to-peer pools, and countless people are recorded on one contract. The contract controller has absolute power over the asset data. This asset processing method seriously conflicts with the Bitcoin UTXO and RGB protocols. The design idea of ​​the latter two is to completely realize the privatization of assets. Everyone Completely control your own assets (think about the difference between banknotes and WeChat payment), without having to consider the problems that have always existed in Ethereum and EVM chains: asset contract owners abuse their power, contract bugs lead to capital damage, and it is troublesome to migrate the data of asset contracts And other issues.

(From Geek Web3’s past article: "Celebrity Thief in the Technology Circle: It is difficult to create new things in high-performance public chains, and smart contracts involve power distribution") strong>

So, if you want to express the mapping relationship between Bitcoin UTXO and off-chain RGB assets more smoothly, the best choice is Through the UTXO chain. CKB supports the extended UTXO-Cell, and the instruction set of CKB VM is based on RISC-V, which is more compatible with different cryptographic algorithms than EVM, including Bitcoin’s public and private key verification algorithm, so it is more It is conducive to realizing the technical solution proposed by RGB++.

Technical implementation of RGB++

RGB++ uses CKB's extended UTXO - Cell. A Cell contains the following fields:

Capacity represents the on-chain space owned by this Cell, and data refers to the data set contained in the Cell, which can be read or modified.

Type is the program code bound to this Cell, which limits the modification conditions of data data. For example, if your Cell contains data of 100 TEST tokens, but you declare to transfer 110 TEST tokens to others, this does not meet the restrictions specified in Type and will be rejected.

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

We can understand Cell as an upgraded version of UTXO, with two additional fields: Type and Capacity, and data can be customized. Type, as for the way of changing the ownership of Cell, it is similar to that of Bitcoin UTXO, both are achieved through unlocking scripts.

The idea 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 on the RGB client to the CKB chain and expresses it in the form of Cell, allowing CKB to serve as a public database for RGB assets. The Cell representing RGB assets will have a 1-to-1 mapping relationship with the UTXO on the Bitcoin chain. This mapping relationship will be directly displayed in the Lock field of the Cell.

For example, assuming that a certain RGB asset is associated with Bitcoin UTXO A, the corresponding mapped version of Cell can be The ownership verification conditions are set to be consistent with Bitcoin UTXO A (that is, the Lock script is set 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. Of course, CKB will verify whether you are the owner of UTXO A.

The CKB chain will implement Bitcoin light nodes and synchronize Bitcoin block headers. When you declare an RGB transaction and want to operate the Cell corresponding to the RGB asset, you must first prove that you are the controller of Bitcoin UTXO A. The proof is divided into two steps:

1. Prove to the Bitcoin light node implemented on the CKB chain that UTXO A exists on the Bitcoin chain and Merkle Proof needs to be presented;

2. Show the digital signature to prove that you are the owner of UTXO A.

In theRGB++ solution, after the user declares an RGB asset transfer on the front end, a transaction will be triggered on the CKB chain , rewrite the Cell that records RGB asset data and change its ownership. Originally, the controller of Bitcoin UTXO 1 might own this Cell. After the ownership change, the controller of Bitcoin UTXO 2 became the new owner of the Cell. This is all visible on the CKB chain.

What should be noted here is that the workflow related to the commitment on the BTC chain is still carried out on the BTC main network, which meansRGB++ still has to issue Commitment on the Bitcoin chain,Associated with RGB asset transaction records that occurred on CKB. This step is no different from traditional RGB protocols.

But the difference is that in the traditional RGB protocol, the work that the client is responsible for off-chain is all handled by CKB ,For example, the counterparty needs to verify the source of assets, the client needs to store asset source data locally, RGB contract release needs to be through third-party channels, etc. These cumbersome burdens can be solved by CKB and do not require users to run them themselves. client.

This solves the problem of RGB client data islanding and also solves the defect that the contract status cannot be globally visible. At the same time, the RGB contract can be directly deployed on the CKB chain and is globally visible for reference by the RGB Cell. This avoids a series of strange operations when the RGB protocol contract is released.

In summary, CKB uses the programmability of Cell script to first confirm that the initiator of the RGB transfer indeed owns the Bitcoin UTXO associated with the RGB asset. If the verification is passed, the user is allowed to transfer. Transfer the Cell recording RGB asset data to others.

In short, CKB acts as a public data hosting platform for RGB assets, providing data storage and globally visible contract release. function, and also provides ownership verification and calculation functions. To put it more concisely, CKB replaces the client in RGB and solves other problems incidentally.

Of course, since RGB++ achieves globally visible data release, privacy is bound to be lower than that of the RGB protocol, but the advantage is that it is easy to Usability has been greatly improved.

SoRGB++ essentially trades privacy for ease of use, and at the same time can bring about scenarios that cannot be achieved by the RGB protocol. If users value the simplicity, ease of use and complete functions of the product, they will favor RGB++. If they pursue privacy and the security of Verify by yourself, they will favor the traditional RGB protocol. It all depends on the user’s own choice< /strong> (The idea is similar to what Vitalik expressed when he commented on Ethereum Layer 2. If you pursue security, use Rollup, and if you pursue low cost, use non-Rollup solutions such as Validium and Optimium.) Of course, according to the RGB++ white paper, private transaction solutions can also be implemented on the CKB chain in the future to hide the user’s identity and transfer amount.

Additional features of RGB++

Non-interactive nature of transactions (very important)

Original RGB protocol An important issue is that the payee must first send a message to the payer (the check mentioned above), indicating that one of its UTXOs must be bound to the RGB asset, so that the RGB transfer can be implemented smoothly. This requires multiple interactive communications between the payee and the payer to complete an ordinary transaction, which obviously increases the difficulty of users' understanding and the complexity of the product. RGB++ takes advantage of the characteristics of CKB as a data hosting and computing platform, allowing counterparties to complete transfers through asynchronous and non-interactive methods.

When A transfers money to B, he only needs to know B’s address in advance and declare the transfer to that address. No payee is required. To communicate or provide data online. After that, the payee can collect the assets by himself, and the script code on the CKB chain will verify whether the payee is the one designated by the payer. Obviously, this model is closer to the habits of most people. Models that are not originally supported in the RGB protocol, such as airdrops and reward distribution, can also work, which is also conducive to RGB asset issuance.

In addition, the working mode of the RGB protocol is naturally not conducive to the development of Defi scenarios. For example, Uniswap, a typical many-to-many, non-interactive transaction pool, has almost no use in the original RGB protocol. It cannot be expanded, and RGB++ implements non-interactive transactions, and the state is globally visible and verifiable. As long as Cell is used to implement an "ownerless contract" in which "all those who meet the conditions can modify its state," many Defi scenarios can be implemented.

Of course, an ownerless contract in which everyone can modify its state is prone to state contention/read-write conflicts, even if several people If you want to modify the contract status at the same time, this will lead to chaos. In order to solve this problem, RGB++ plans to use an Intent Cell implemented on the chain as a "sequencer" to sort different requests.

Transaction folding (commitment release that aggregates multiple transactions)

Transaction folding is easier to understand, that is, CKB is used as an "off-chain pre-settlement layer". After multiple RGB transfers occur, a batch of transactions are aggregated to generate a Commitment corresponding to the batch transaction. Published to the Bitcoin chain at one time.

The specific performance is the following flow chart:

BTC Assets do not need to cross-chain to directly interact with assets on the CKB chain

RGB++ realizes the integration between Bitcoin UTXO and CKB Cell After the association mapping between them, cross-chain interoperability without the need for assets can be directly realized.You can transfer your Bitcoin UTXO to others through the RGB++ transaction statement, and the other party can transfer the ownership of its CKB assets to you. This model has a lot of room for imagination. Combined with the previously mentioned transaction folding (batch transactions), it can theoretically achieve asset interoperability on the BTC-CKB chain without the need for BTC assets to cross-chain.

Summary

RGB++ converts asset data stored locally in different RGB clients , directly expressed using the Cell on the CKB chain, and then associating the Cell with the UTXO on the Bitcoin chain. Users can interact with their RGB++ assets on the CKB chain through Bitcoin accounts/assets. This method is relatively simple andsolves the problems in the RGB protocol, such as the need for prior communication between both parties for transfer, difficulty in supporting globally visible status, fragmentation of data storage, and unfriendly smart contracts and Defi.

RGB++ can realize interoperability between BTC and CKB without cross-chain assets, and facilitates RGB assets and Defi The combination of scenes greatly solves the ease of use problem of the RGB protocol. But for the niche RGB players who pursue a high degree of privacy, the essence of RGB++ is to trade privacy for ease of use, and everything depends on the user's choice. But in theory, privacy issues can be solved on the CKB chain by introducing ZK and other methods.

Overall, RGB++ demonstrates the potential of CKB as a settlement layer/computing layer under the Bitcoin chain, and this idea will be In the future, it will be adopted by more and more Bitcoin Layer 2 or asset protocols. It is foreseeable that competition among third-party settlement layers under the Bitcoin chain may begin soon. CKB, which focuses on POW and UTXO and has many years of technology accumulation, may be able to show its technical advantages in this competition for modular blockchains.