Author: DaPangDun（X@DaPangDunCrypto）
Original link: https://mirror.xyz/dapangdun.eth/ow12nfLreKWBkVpznN6DC2L10-6gY1mW-Gz8V08NS-w
On February 13th, Cipher, co-founder of CKB, proposed the extension protocol for RGB, called RGB++. This immediately drew a lot of attention in the market and to some extent affected the secondary market price of CKB.
Before the release of this protocol, I had several in-depth discussions with Cipher regarding the embryonic concept of the RGB protocol. Therefore, I wrote a short article to explain my popular understanding of the RGB++ protocol, my personal opinions, and the potential impact of this protocol.
1. Overview of RGB++: Expanding the use cases of RGB technology
In summary, understanding RGB++ involves the following points:
1.1 It is an extension protocol based on RGB
It utilizes some of the technologies in the RGB protocol and strictly does not belong entirely to the RGB ecosystem, but it expands the use cases of RGB technology.
1.2 It extends the capabilities of the current RGB protocol
It addresses the technical issues in the practical implementation of the current RGB protocol and provides more possibilities, such as "verification process," "contract programmability," and "Turing-complete virtual machine."
1.3 It is achieved through UTXO isomorphic mapping
It maps Bitcoin UTXO to Nervos CKB Cells and uses script constraints on the CKB chain and Bitcoin chain to verify the correctness of state calculation and the validity of ownership changes. I believe this isomorphic mapping approach has strong scalability.
2. Why propose the RGB++ protocol?
My friends who are familiar with me know that I am a researcher deeply involved in the RGB protocol and have been following the development of the RGB protocol and its ecosystem. In my continuous research, I found that despite the excellent design of the RGB protocol, there are some problems in its practical implementation:
2.1 Slow development of RGB
One reason is that the majority of the design involves new concepts or the establishment of a new standard, which requires careful overall thinking and the implementation of entirely new code.
Another reason is that there are relatively few developers involved in the development of the entire protocol layer, as can be seen from the composition of LNP/BP personnel and the current number of ecosystem projects.
2.2 RGB development is affected by some uncontrollable factors
For example: RGB generally needs to be built on the Lightning Network, but the current bolt-ln does not support RGB contracts well. Therefore, the LNP/BP Association proposed a new Lightning Network standard, bifrost, but this requires a lot of work to be done, and even requires waiting for the overall development of the Lightning Network.
Another example: The transfer of RGB involves the transmission of invoices and committees, which can currently be done through web2 (Twitter, Telegram, etc.) or peer-to-peer networks. However, from a unified perspective, a standard transmission standard is needed, which is the storm node. But building such a network also requires a lot of work.
2.3 RGB's AluVM virtual machine currently lacks comprehensive development tools and practical code
In other words, even though v0.11 has been fully released, it still takes a considerable amount of time to verify the performance and reliability of the virtual machine, as well as to accumulate experience in developing code through AluVM and even standard libraries.
These issues make RGB somewhat unique in this fiercely competitive market, much like the development status of BTC in its early days. This brings about a lot of uncertainty, the impact of market cycles (missing the bull market period), emotional impact, and the impact of the integration of other new technologies (the combination of other technologies with some RGB technologies to achieve "sprinting"), and so on.
In summary, RGB has great potential for growth, but the complete implementation of the protocol will take a long time and has uncertainties.
This is the background and the problems that the RGB++ protocol aims to solve.
3. Technical focus of the RGB++ solution: Isomorphic mapping
Therefore, in the early discussions, the focus was on "how to solve these problems in the implementation of RGB" and "whether existing CKB technologies can be used to some extent to solve this problem."
Cipher creatively used the core point of RGB, "UTXO," and the inherent characteristics of CKB's underlying architecture to propose the "isomorphic mapping" solution, gradually laying out the content of the "RGB++" protocol.
Referring to the figure below, he combined two key points of the RGB protocol with the architecture of CKB:
1) The UTXO as an RGB container can be mapped to the Cell of CKB through the lock in the Cell.
2) The validation of the off-chain client in RGB can be transformed into the on-chain public validation of CKB, and the validation data and state can correspond to the data and type in the Cell.
Source: https://talk.nervos.org/t/rgb-protocol-light-paper/7733
Through "isomorphic mapping," the process of parsing the committee on RGB in CKB is achieved, and with compatibility, users can still parse on RGB, which is a very interesting effect.
Upon further analysis, in fact, Cipher "deconstructed" and "modularized" the technology of RGB, and then considered whether a module could have other technical routes or alternative options, thereby deriving more possibilities.
After "isomorphic mapping," scalability naturally arises, enabling various extension functions (please refer to the white paper for details):
3.1 Transaction folding
By utilizing the programmable capability of CKB Cells, multiple CKB transactions can correspond to a single Bitcoin RGB++ transaction, allowing the use of the high-performance CKB chain to expand the low-speed, low-throughput Bitcoin chain.
If "transaction folding" is further extended, in principle, not every state change needs to be synchronized on Bitcoin, which is equivalent to adding options such as "off-chain validation" on CKB.
3.2 Ownerless contract
Ownerless Contract
An ownerless contract refers to a situation where anyone can change the state without requiring a specified digital signature provider, as long as the contract constraints are met. This type of contract creates a foundation for complex contract methods such as AMM.
Non-Interactive Transfer
One of the drawbacks of the RGB protocol transfer is the need for both parties to communicate certain information to complete the transfer. While this brings certain advantages (such as avoiding receiving scam tokens), it also increases user understanding difficulty and product complexity. RGB++ can leverage the current advantages to implement non-interactive transfer logic within the CKB environment using a send-receive two-step operation.
This transfer logic forms the basis for large-scale airdrops.
AMM+DEX
Introducing CKB's grid AMM design can enable a UTXO-based market maker model, which, although different from Uniswap's price curve market model, represents significant progress for the UTXO model.
Role of the RGB++ Protocol
As the protocol has just been proposed and the specific development implementation has not been completed, and many people do not have sufficient understanding of the RGB protocol itself, the potential "chemical reaction" that RGB++ may cause is not yet very sensitive. I will explain my views on the role of the RGB++ protocol from the following perspectives:
For CKB: Key Anchor Point in the Battle for Bitcoin's Orthodox L2 Market
CKB, with its POW mechanism and enhanced "UTXO" model, enjoys "orthodoxy," but its network and ecosystem development did not perform impressively after early investments from many star institutions.
Its shift to Bitcoin L2 this year is a significant opportunity for CKB. On the one hand, the underlying technology and infrastructure have gradually improved over the past few years, and on the other hand, it coincides with the current hot topic.
In a conversation with Cipher, he presented a viewpoint that greatly benefited me: the key point of the battle for Bitcoin L2 lies in L1.
RGB++ deepens the connection between CKB and the Bitcoin main chain, bringing it more "orthodoxy," which is why I believe it is one of the key anchor points.
For RGB: Expanding Possibilities for Integration with Other UTXO-Based Public Chains
The RGB protocol itself has the potential to integrate with other UTXO-based public chains, as indicated by the official announcement of LNP/BP Association supporting interoperability with Liquid.
By combining CKB with some RGB technologies, it will to some extent verify the "practical effectiveness" of this integration.
Furthermore, if we abstract the RGB++ protocol further to become a more general extension layer for integrating the RGB protocol with all UTXO-based public chains with a certain degree of scalability, its narrative and value will be greatly enhanced. This may also be the direction that Cipher may strive for in the next stage.
At the same time, this provides some alternative options for the development of projects in the RGB ecosystem, different from simple "multi-signature cross-chain bridges," but based on native methods.
For Other Bitcoin L2 Solutions: Providing Technical References for Integrating the RGB Protocol
Cipher's deconstruction of the RGB technology architecture will provide a good thinking example for other L2 technical personnel.
They can combine their project's technical characteristics and advantages with some of the technologies they need from RGB, and then "combine" them into a new product paradigm, or even achieve "sprinting" (here, "sprinting" is not a derogatory term, but reflects the combinatory nature of technology and the innovativeness in the development of the BTC ecosystem, while still promoting the popularization and development of the RGB protocol).
In conclusion, although RGB++ is currently only in the white paper stage, theoretically, I am optimistic about it. It may bring new vitality to the RGB protocol and possibly awaken the CKB network.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
