CKB co-founder Cipher recently proposed an extension protocol for RGB called RGB++, which has attracted attention. Although RGB++ is still in the whitepaper stage, theoretically, it may bring fresh vitality to the RGB protocol and inject energy into the CKB network. This article is sourced from the author DaPangDun, compiled, organized, and written by BlockBeats.
Summary of RGB++: An Extension Protocol for RGB Technology
RGB++ is an extension protocol based on RGB technology. Strictly speaking, it is not entirely part of the RGB ecosystem, but it extends the use cases of RGB technology.
It extends the capabilities of the current RGB protocol and solves technical issues in its practical implementation. It provides more possibilities, such as “verification process”, “contract programmability”, and “Turing-complete virtual machine”.
It is implemented through UTXO homomorphic reflection. By reflecting Bitcoin UTXOs onto Nervos CKB Cells and using script constraints on the CKB and Bitcoin chains, it verifies the correctness of state calculation and the validity of ownership changes. This homomorphic reflection approach has strong extensibility.
Why Propose the RGB++ Protocol?
The development of RGB is relatively slow. One reason is that most of the designs are new concepts or the formation of a new standard, requiring detailed global thinking and new code implementation.
Another reason is the limited number of developers involved in the protocol layer, as seen from the composition of LNP/BP personnel and the number of current ecosystem projects.
RGB development may be affected by uncontrollable factors. For example, RGB is generally built on the Lightning Network, but the current Bolt-ln does not support RGB contracts well. Therefore, the LNP/BP Association has proposed a new Lightning Network standard, Bifrost, which requires a lot of work and even needs to wait for the overall development of the Lightning Network.
Another example is that invoice and committee transmission are involved in RGB transfers, which can currently be done through web2 (Twitter, Telegram, etc.) or P2P networks. However, from a unified perspective, a standard transmission protocol is needed, which is the Storm node. But building such a network also requires a lot of work.
The AluVM virtual machine of RGB currently lacks complete development tools and practical code. Even though version 0.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.
These issues make RGB somewhat unique in this competitive market, much like the development status of Bitcoin in its early days. This brings uncertainty, influenced by market cycles (missing the bull market period), emotions, and the integration of other new technologies (the combination of other technologies and RGB technologies to achieve “lead”).
In summary, RGB has great potential for growth, but the complete implementation of the protocol takes a long time and has uncertainties. This is the background and problems that the RGB++ protocol aims to solve.
Technical Focus of the RGB++ Solution: Homomorphic Reflection
In early discussions, the focus was on “how to solve the problems in the implementation of RGB” and “whether CKB’s existing technology can be used to solve these problems to some extent.”
Cipher creatively used the core point of RGB, “UTXO,” and the underlying structure of CKB, which are homologous, to propose the solution of “homomorphic reflection” and gradually lay out the content of the RGB++ protocol.
By combining two key points of the RGB protocol with the CKB structure, he achieved:
1) Reflection of UTXOs as RGB containers onto CKB Cells, implemented through the lock in the Cell.
2) Transformation of off-chain client verification into on-chain public verification using the data and type in the Cell.
Through “homomorphic reflection,” the committee on RGB can be resolved on CKB, and users can still resolve it on RGB with compatibility, which is an interesting effect.
If analyzed further, Cipher actually “deconstructed” and “modularized” the RGB technology, and then considered whether a module could have other technical routes or alternative options to derive more possibilities.
After “homomorphic reflection,” the extensibility is naturally generated, and various extension functions can be implemented (please refer to the whitepaper for details).
Transaction Folding: By utilizing the programmability of CKB Cells, multiple CKB transactions can correspond to a single Bitcoin RGB++ transaction, enabling the use of the high-performance CKB chain for the low-speed and low-throughput Bitcoin chain.
If “transaction folding” is further extended, it is not necessary to synchronize every state change on Bitcoin, which is equivalent to adding “off-chain verification” as an option on CKB.
Ownerless Contracts: Ownerless contracts allow anyone to change the state without requiring a specified digital signature provider, creating a foundation for complex contracts such as AMM.
Non-Interactive Transfer: One characteristic of RGB protocol transfers is that they require communication of certain information between parties to complete. This brings certain advantages (avoiding scams, etc.) but also increases user understanding difficulty and product complexity. RGB++ can utilize the current advantages and implement non-interactive transfer logic through a two-step operation of sending and receiving, which forms the basis for large-scale airdrops.
AMM+DEX: CKB’s grid AMM design can be introduced to realize a UTXO-based market maker model. Although it is different from Uniswap’s price curve market maker model, it is a significant advancement for the UTXO model.
Roles of the RGB++ Protocol
Since the protocol has just been proposed, specific development experiments have not been completed yet, and many people do not have sufficient understanding of the RGB protocol itself. Therefore, they may not be sensitive to the potential “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 a key anchor point for it to compete in the mainstream Bitcoin L2 market. CKB, with its POW mechanism and enhanced “UTXO” model, enjoys “orthodoxy”. However, its network and ecosystem development did not perform well after many early investments from star institutions. Shifting towards Bitcoin L2 this year is a significant opportunity for CKB. On one hand, the underlying technology infrastructure has gradually improved after years of development. On the other hand, it coincides with the current hot trend.
In a chat with Cipher, he mentioned something that benefited me a lot: the key point of the Bitcoin L2 competition lies in L1. RGB++ creates a deeper connection between CKB and the Bitcoin main chain, thereby bringing more “orthodoxy” to CKB. This is why I think it is one of the key anchor points.
A Side Note: About “Orthodox” L2
The concept of L2 originated from Ethereum, and with the development of various L2 solutions and modularization, the definition of L2 has become increasingly blurred. On Ethereum, it leans more towards a pragmatic approach, and the concept of “orthodoxy” is gradually fading.
However, for the Bitcoin network, the concept of “orthodoxy” has always been present throughout its development process. Currently, in my personal view, the strength of “orthodoxy” for L2 (from high to low) is as follows:
1) Lightning Network, RGB, BitVM: These three are relatively well-known, and overall, they have essential differences in the implementation path and targeted points. Currently, the Lightning Network is relatively mature, followed by RGB, and finally BitVM.
2) Sidechains: Examples include Liquid, Stacks, CKB, etc. They mostly rely on the UTXO structure with certain modifications or innovations to enhance extensibility (such as privacy and programmability) and optimize consensus mechanisms. 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 category may include “L2 based on cross-chain protocols” and “L2 based on EVM”. I generally agree with Ajian’s view:
2.2 For RGB: RGB++ expands the possibility of combining it with other UTXO-based public chains. The official tweet from the LNP/BP Association indicates support for interoperability with Liquid. By combining RGB with certain technologies from CKB, it will validate the “practical effectiveness” of this combination.
To further abstract the RGB++ protocol into a broader extension layer, which serves as a technical reference for integrating the RGB protocol into all UTXO-based public chains with certain extensibility, will significantly enhance its narrative and value. This is also a potential direction that I believe Cipher may focus on in the next stage.
At the same time, this provides some alternative options for the development of projects in the RGB ecosystem. These options are different from simple “multi-signature cross-chain bridges” and are based on native methods.
For other Bitcoin L2 solutions, it provides a technical example of integrating the RGB protocol. They can combine their own project’s technical characteristics and advantages with some of the required technologies from RGB, then “assemble” them into a new product standardization and even achieve “lead” (here, “lead” is not a derogatory term, but reflects the combinability of technologies and innovation in the BTC ecosystem, and will also promote the popularization and development of the RGB protocol).
In conclusion, although RGB++ is currently only in the whitepaper stage, I am optimistic about it theoretically. It will bring new vitality to the RGB protocol and may awaken the CKB network’s energy.