CKB’s co-founder Cipher recently proposed an extension protocol for RGB called RGB++, which has attracted attention. Although RGB++ is still in the white paper stage, theoretically, it could bring new vitality to the RGB protocol and inject vitality into the CKB network. This article is from the author DaPangDun and was compiled, organized, and written by BlockBeats.
Summary of RGB++: Extension Protocol for RGB Technology
RGB++ is an extension protocol based on RGB. Strictly speaking, it is not completely part of the RGB ecosystem but extends the use cases of RGB technology. It expands the current capabilities of the RGB protocol and solves technical problems encountered in its implementation, offering more possibilities such as “verification links,” “contract programmability,” and “Turing-complete virtual machines.” It is implemented through UTXO homomorphic reflection, reflecting Bitcoin UTXOs onto Nervos CKB Cells and using script constraints on the CKB and Bitcoin chains to verify the correctness of state calculations and the validity of ownership changes. This homomorphic reflection approach has strong extensibility.
Reasons for Proposing the RGB++ Protocol
The development of RGB has been relatively slow for several reasons. Firstly, most of the designs are new concepts or the establishment of a new standard, requiring meticulous global thinking and the implementation of new code. Secondly, there are fewer developers involved in the development of the protocol layer, as seen from the composition of LNP/BP personnel and the number of current ecosystem projects.
RGB’s development is also affected by 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 called bifrost. However, this requires a lot of work and even waiting for the overall development of the Lightning Network.
Another example is that RGB transfers involve the delivery of invoices and committees. Currently, this can be done through web2 (Twitter, Telegram, etc.) or peer-to-peer networks. However, from a unified perspective, a standard transmission standard is needed. This is the Storm node, but building such a network also requires a lot of work.
The AluVM virtual machine for RGB currently lacks robust development tools and implementation code. Even though v0.11 has been fully released, it still takes time to verify the performance and reliability of the virtual machine and accumulate experience and standard libraries through AluVM development code.
These problems make RGB appear somewhat unusual in this fast-paced market, similar to the development state of BTC in its early days. This brings a lot of uncertainty, including the impact of market cycles (missing the bull market), emotional influence, and the impact of the integration of other new technologies (combining other technologies with RGB to achieve “early adoption”).
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 problem that the RGB++ protocol aims to solve.
Technical Highlights of the RGB++ Solution: Homomorphic Reflection
In the early exchanges, the focus was on “how to solve the problems in the implementation of RGB” and “whether the existing CKB technology can be used to solve these problems to some extent.” Cipher creatively used the core point of RGB, “UTXO,” and the homogeneity of CKB’s underlying architecture to propose the solution of “homomorphic reflection” and gradually laid out the content of the RGB++ protocol.
By combining two key points of the RGB protocol with the CKB architecture, he reflected RGB’s UTXOs onto CKB Cells through the lock in the Cell. The validation of the chain’s off-chain client can be transformed into public validation on the CKB chain, where the validation data and state correspond to the data and type in the Cell.
Through “homomorphic reflection,” the RGB committee’s parsing process on CKB is realized. With compatibility, users can still perform parsing on RGB, which is a very interesting effect. In fact, Cipher has “analyzed” and “modularized” the RGB technology, and then considered whether a module can have other technological routes or alternative options, thereby deriving more possibilities. After “homomorphic reflection,” the extension nature naturally arises, realizing various extension functions (please refer to the white paper for details).
Other Extension Functions
1. Transaction Folding: Using the programmability of CKB Cells, multiple CKB transactions can correspond to one Bitcoin RGB++ transaction, allowing the use of the high-performance CKB chain to scale the low-speed, low-throughput Bitcoin chain. This extension function can avoid the need to synchronize every state change on Bitcoin and introduce “off-chain verification” on CKB.
2. Ownerless Contracts: Anyone can change the state as long as they meet the contract constraints, without requiring a specific digital signature provider. This type of contract provides the foundation for complex contract models such as AMM.
3. Non-Interactive Transfers: One characteristic of RGB protocol transfers is that certain information needs to be communicated between the parties to complete the transfer. This brings certain advantages (no receipt of scam tokens, etc.) but also increases the difficulty of user understanding and product complexity. RGB++ can utilize the current advantages to implement non-interactive transfer logic through a “send-receive” two-step process. This transfer logic is the basis for large-scale airdrops.
4. AMM+DEX: CKB’s grid AMM design can be introduced to achieve a UTXO-based market maker model. Although different from Uniswap’s price curve market maker model, it is a significant advancement for the UTXO model.
The Role of the RGB++ Protocol
Since the protocol has just been proposed and specific development experiments have not been completed, and many people do not have sufficient understanding of the RGB protocol itself, they are not very sensitive to the possible “chemical reactions” caused by RGB++. I will explain my views on the role of the RGB++ protocol from the following perspectives:
For CKB: RGB++ will be one of the key anchor points for CKB to compete in the Bitcoin mainstream L2 market. CKB, with its POW mechanism and enhanced “UTXO” model, enjoys “orthodoxy.” Switching to the Bitcoin L2 market this year is a significant opportunity for CKB. On the one hand, the underlying technology and infrastructure have gradually improved after years of development. On the other hand, it coincides with the current hot spot.
In a conversation with Cipher, he brought up a viewpoint that greatly benefited me: the key point of the Bitcoin L2 competition lies in L1. RGB++ creates a deeper connection between CKB and the Bitcoin main chain, bringing more “orthodoxy” to CKB. This is why I believe it is one of the key anchor points.
About “Orthodox” L2: The concept of L2 originated from ETH, and with the development of various L2 solutions and modularization, the definition of L2 has become increasingly blurred, and the concept of “orthodoxy” has gradually faded. However, for the Bitcoin network, the concept of “orthodoxy” has always been present throughout its development process. In my personal view, the strength of “orthodoxy” in L2 (from high to low) is as follows:
1) Lightning Network, RGB, BitVM: Lightning Network is currently the most mature, followed by RGB, and then BitVM. The development paths of these three have essential differences, and they target different aspects. The Lightning Network is relatively mature in terms of its development progress.
2) Sidechains: Examples include Liquid, Stacks, CKB, etc. Most of them are based on UTXO architecture, with some modifications or innovations to enhance extensibility (such as privacy and programmability) and optimize the consensus mechanism. Sidechains can be understood as experimental chains for BTC, experimenting with new features or temporarily unachievable features on the BTC main chain.
3) Others: This may include “L2 based on cross-chain protocols” and “L2 based on EVM.” I generally agree with Ajian’s view.
For RGB: RGB++ expands its potential for integration with other UTXO-based public chains. The official tweet from the LNP/BP association indicates support for interoperability with Liquid. By combining RGB technology with CKB, the “practical effectiveness” of this combination will be verified to a certain extent. Furthermore, if we further abstract the RGB++ protocol into a broader extension layer for connecting the RGB protocol with all UTXO-based public chains with certain extension capabilities, its narrative and value will be greatly enhanced. This is also the direction that Cipher is likely to strive for in the next stage. It also provides other alternatives for the development of projects in the RGB ecosystem, which are different from simple “multi-signature cross-chain bridges” and are based on a native approach.
For other Bitcoin L2 solutions: RGB++ provides technical references for integrating the RGB protocol. Cipher’s analysis of the RGB technology architecture will provide a good thinking example for other L2 technical personnel. They can combine their own project’s technical characteristics and advantages and integrate some of the necessary RGB technologies to create a new product standardization and even achieve “early adoption” (this term does not carry negative connotations). This will promote the popularity 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 could bring new vitality to the RGB protocol and potentially revive the CKB network.