jakiro
Author: Faust, Geek Web3 & AMP; Btceden.org Lianchuang
With the popularity of RGB ++ and related assets, discussions on the principles of RGB and RGB ++ protocols have gradually become a topic for more attention.But everyone realized that to understand RGB ++, we 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. So far, there are not many systematic and more easy -to -understand reference materials.Although the Geek Web3 has previously published two systematic interpretation articles about RGB and RGB ++ (you can see the historical records of our public account), according to the feedback of community members, the aforementioned article is relatively long and too brain -burning.
In order to allow more people to understand the RGB and RGB ++ protocol faster, the author of this article has completed a temporary work during the Hong Kong event.Regarding the brief vernacular interpretation of RGB and RGB ++, you can read it in a few minutes. I hope to help more community enthusiasts better and more intuitive to understand RGB and RGB ++Essence
RGB protocol: Users must do data verification in person
The RGB protocol is a special P2P asset protocol, a computing system under the Bitcoin chain. It is similar to the payment channel in some aspects:Users should run the client in person to verify the Verify By YOURSELF by themselves.Even if you are just an asset receiver, you must first determine that there is no error in the transfer statement of the asset sender, and then this transfer statement can take effect.Obviously, this is very different from the traditional form of asset sending and receiving. We call it “interactive transfer”.
Why do you want to do this?The reason is,In order to ensure privacy, the RGB protocol does not use the “consensus agreement” in traditional blockchains such as Bitcoin and Ethereum(Once the data goes through the consensus agreement, it will be observed by almost all nodes in the network, and privacy is not guaranteed).If there are no consensus processes involved in a large number of nodes, how to ensure that asset changes are safe?Here I use the idea called “Client Verification” (VERIFY BY Yourself),You have to run the client yourself and verify the changes related to your related assets in person.
Assuming that there is a RGB user called Bob, he knows Alice, Alice wants to transfer 100 TEST tokens for BOB.After Alice generates the transfer information of “Alice To Bob”, it is necessary to send the transfer information and the asset data involved to the Bob first, let him check it in person, it will be correct to enter the follow -up process, and eventually become an effective RGB transfer.Therefore,The RGB protocol is to allow users to verify the effectiveness of the data and replace the traditional consensus algorithm.
But there is no consensus, the data received and stored in different RGB clients are inconsistent.Everyone only stores the asset data related to themselves, and does not know the asset status of others.While protecting privacy, it also constitutes the “Data Island”.If someone claims that there are 1 million TEST tokens, you want to transfer to you 100,000, how can you believe him?
In the RGB networkIf someone wants to transfer you, he must show him the asset certificate first, and the historical source from the initial issuance of the assets from the initial issuance to the multiple transfers.For example, when you receive unknown banknotes, you ask the other party to explain whether the historical source of these banknotes is made by the designated issuer to avoid counterfeit currency.
(Picture source: coinex)
The above process occurs under the Bitcoin chain, and the RGB cannot be directly associated with the Bitcoin network alone.To this,The RGB protocol adopts the idea of ”Single Use Seal”, and binds the RGB assets with the UTXO on the Bitcoin chain.As long as the Bitcoin UTXO is not dual-consumption, the binding RGB assets will not have dual payment, so that the Bitcoin network can be used to prevent RGB assets from “Re-Organization”.Of course, thisYou need to publish the Commitment on the Bitcoin chain and use the OP_RETURN operating code.
Here, we can sort out the workflow of the RGB protocol:
1. RGB assets have a binding relationship with Bitcoin UTXO, and BOB has some bitcoin UTXO.Alice has to transfer 100 tokens for BOB. Before receiving assets, BOB told Alice in advance that Bob’s Bitcoin UTXO binds these RGB assets.
(Image source: Geek Web3/ Geekweb3)
-
Alice constructs a “Alice to Bob” RGB asset transfer data, which comes with the historical sources of these assets to Bob to verify.
-
After Bob confirmed that the data is okay, he sends a rebate to Alice and told her: This transaction can be passed.
-
Alice builds this “Alice To Bob” RGB transfer data into a Merkle Tree, and publishes Merkle Root to the Bitcoin chain as the Commission. We can simpment simpment simply as HASH of the transfer data.
-
If someone wants to determine in the future, the transfers of the above “Alice to Bob” have happened, and he needs to do two things: obtaining the complete transfer information of “Alice to Bob” under the Bitcoin chain, and then check whether there is a corresponding correspondence on the Bitcoin chain.Commitment (hash for transfer data) is fine.
-
Use the UTXO model or a similar state storage solution;
-
It has considerable UTXO programming, allows developers to write unlocking script;
-
There is an UTXO -related state space that can store asset status;
-
There are Bitcoin -related bridges or light nodes;
Bitcoin acts as the historical log of the RGB network, but the log/merkle root of trading data is only 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;Since the RGB network is composed of dynamic user clients in P2P and unintentional form, you can replace the transaction opponent at any time without having to send the transaction request to some limited number of nodes, soThe RGB network has a strong anti -reviewabilityThis organizational form is more anti -review than large public chains such as Ethereum.
(Picture source: btceden.org)
certainly,The cost and privacy protection of extremely high security and anti -review, and privacy protection are also obvious:Users should run the client to verify the data by themselves. If some assets with tens of thousands of times and long historical records are sent to the opposite side, you must also verify all the pressure;
In addition, each transaction requires the two parties to communicate multiple times. The receiver must first verify the source of the sender’s assets, and then send the return to the dealer to approve the transfers of the sender.In this process, at least three news transmission is generated between the two sides.This “interactive transfer” and the “non -interactive transfer” used by most people are not in line withCan you imagine that others have to transfer money to you, and send you the transaction data to check it. After getting your return information, can you complete the transfer process?
In addition, we mentioned that the RGB network has no consensus. Each client is an islands, which is not conducive to migrating the complex smart contract scenarios on the traditional public chain to the RGB network.Visible and data transparent ledger.How to optimize the RGB protocol, improve user experience and solve the above problems?This has become an issue that cannot be around the RGB protocol.
RGB ++: Client verification becomes optimistic hosting
The agreement named RGB ++ proposes new ideas. It combines the RGB protocol with CKB, Cardano, Fuel and other public chains that support UTXO.Verification work, handed over to third -party platforms/public chains such as CKB, which is equivalent to replacing client verification into “third -party decentralized platforms for verification”, as long as you trust CKB, Cardano, Fuel and other public chains, if youIf you do not trust them, you can also switch back to the traditional RGB mode.
RGB ++ and the original RGB protocol are theoretically compatible with each other, not that he has no self.
To achieve the effect mentioned above, you need to use a idea called “homogeneous binding”.The public chain such as CKB and Cardano has its own UTXO, which is more programmed than UTXO on the BTC chain.The “homogeneous binding” is to use the extended UTXO on the CKB, Cardano, and FUEL chain as the “container” of RGB asset data, write the parameters of RGB assets into these containers, and directly display it on the blockchainEssenceWhenever RGB asset transactions occur, the corresponding asset container can also present similar features, just like the relationship between entities and shadows.This is the essence of “homogeneous binding”.
(Picture source: RGB ++ LIGHTPAPER)
For Example, if Alice has 100 RGB tokens and UTXO A on the Bitcoin chain, there is an UTXO on the CKB chain. This UTXO is marked with “RGB Token Balance: 100”.Essence
If Alice wants to give 30 tokens to BOB, you can form a commitment. The corresponding statement is to transfer 30 pieces of RGB tokens associated with UTXO A to BOB and 70 to other UTXO controlled by yourself.
After that, Alice spent UTXO A on the Bitcoin chain, issued the above statement, and then launched a transaction on the CKB chain to consume 100 UTXO containers carrying 100 RGB tokens, generate two new containers, one to hold 30 tokens (Give Bob), a 70 token (Alice control).In the process, the task of verifying Alice’s asset validity and transaction declaration effectiveness is completed by consensus by network nodes such as CKB or Cardano, and no BOB intervention is required.At this time, CKB and Cardano served as the verification layer and DA layer under the Bitcoin chain.
(Picture source: RGB ++ LIGHTPAPER)
Everyone’s RGB asset data is stored on the CKB or Cardano chain. It has the characteristics of global verification, which is conducive to the realization of the DEFI scenario, such as the liquidity pool and the asset pledge agreement.Of course, the above practices also sacrificed privacy. The essence is to make a choice between privacy and product ease of use.If you are pursuing the ultimate security and privacy, you can switch back to the traditional RGB mode; if you don’t care about this, you can use the RGB ++ mode, depending on your personal needs.(In fact, with the powerful functional integrity of public chain such as CKB and Cardano, you can use ZK to achieve privacy transactions)
It is important to emphasize that RGB ++ has introduced an important trust assumption:Users should be optimistic that the CKB/Cardano chain, or a network platform consisting of a large number of nodes by consensus protocol, is reliable.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 use Bitcoin account without cross -chain to operate themselves on the RGB asset container on the UTXO chain such as CKB/Cardano.You only need to use the characteristics of UTXO in the above public chain to set the unlocking conditions of the Cell container to associate with a bitcoin address/Bitcoin UTXO.If both parties to RGB asset transactions believe the security of CKB, it does not even need to publish the Commission on the Bitcoin chain.After many pens RGB transfers, a summary will be sent to send a Community to the Bitcoin chain, which is called “transaction fold” function, Can reduce the cost of use.
But pay attention,The “container” adopted by the same binding needs to support the public chain of the UTXO model, or an infrastructure with similar features on the state storage. The EVM chain is not suitable and will encounter many pits.(This topic can be written alone, and there are more content involved. Interested readers can refer to the previous article of Geek Web3Items
Take a comprehensive,Suitable for the public chain/functional expansion layer that is suitable for homogeneous binding, it should have the following characteristics:
