Author: Nervos Byte Metaverse

On February 13, Cipher, the co-founder of CKB, proposed an extension protocol for RGB: RGB++. This immediately attracted a lot of attention in the market and also influenced the secondary market price of CKB to some extent.

Before this protocol was released, I had several in-depth discussions with Cipher regarding the RGB protocol and the initial conceptualization of this protocol. Therefore, I am writing a short piece to explain my popular understanding, personal views, and what I believe could be the potential role of the RGB++ protocol.

1. Overview of RGB++: Expanding the Use Cases of RGB Technology

In summary, understanding RGB++ can be broken down into the following points:

1.1 It is an extension protocol based on RGB

It utilizes some technologies from the RGB protocol and does not strictly belong to the RGB ecosystem, but it expands the use cases of RGB technology.

1.2 It enhances the capabilities of the current RGB protocol

It addresses technical issues in the practical implementation of the current RGB protocol and provides more possibilities, such as "verification stages," "contract programmability," and "Turing-complete virtual machines."

1.3 It is achieved through UTXO isomorphic mapping

It maps Bitcoin UTXO to Cells on Nervos CKB and uses script constraints on both the CKB chain and the Bitcoin chain to verify the correctness of state calculations and the validity of ownership changes. I believe this isomorphic mapping approach has strong scalability.

2. Why Propose the RGB++ Protocol?

Friends familiar with me know that I am a researcher deeply engaged in the RGB protocol, continuously following its development and the evolution of its ecosystem. Through ongoing research, I found that despite the RGB protocol being beautifully designed, there are some issues in its practical implementation:

2.1 RGB development is relatively slow

One reason is that most of the designs are new concepts or form a new standard, which requires detailed global thinking and new code implementation. Another reason is that the number of developers involved in the entire protocol layer is relatively small, as can be seen from the composition of LNP/BP personnel and the current number of ecosystem projects.

2.2 RGB development may be affected by some uncontrolled factors

For example, RGB generally needs to be built on the Lightning Network; however, 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 and may even need to wait for the overall development of the Lightning Network. Another example is that the transfer of RGB involves the transmission of invoices and committees, which can currently be done through web2 (Twitter, TG, etc.) or peer-to-peer networks, but from a unified perspective, a standard transmission protocol is needed, which is the storm node, and building such a network also requires a lot of work.

2.3 The AluVM virtual machine of RGB currently lacks complete development tools and practical code

In other words, even if v0.11 is fully released now, it will still take considerable time to verify the performance and reliability of the virtual machine and to accumulate experience and even standard libraries for developing code through AluVM. These issues make RGB seem somewhat out of place in this time-sensitive market, resembling the development state of BTC in its early days, which brings a lot of uncertainty, market cycle impacts (missing the funding bull market), emotional influences, and the integration of other new technologies (the combination of other technologies with some RGB technologies to achieve "running ahead"). In summary: RGB has great growth potential, 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 address.

3. Technical Focus of the RGB++ Solution: Isomorphic Mapping

Therefore, in early discussions, the focus was on "how to solve these issues in the implementation of RGB" and "whether existing CKB technologies can be utilized to address this problem to some extent." Cipher creatively utilized the core point of RGB, "UTXO," and the shared characteristics of CKB's underlying architecture to propose an "isomorphic mapping" solution, gradually laying out the content of the "RGB++" protocol. As shown in the figure below, he combined two key points of the RGB protocol with the CKB architecture: 1) The UTXO serving as the RGB container can be mapped to the Cell of CKB, achieved through the lock in the Cell. 2) The off-chain client verification for validation can be transformed into on-chain public verification on CKB, where the verified data and state 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 RGB committee on CKB is realized, and, with compatibility, users can still parse on RGB, which is a very interesting effect. If we analyze further, Cipher has effectively "parsed" and "modularized" RGB technology, then considered whether a certain module could have other technical routes or alternative options, thus deriving more possibilities. After "isomorphic mapping," scalability naturally arises, enabling various expansion functions (please refer to the white paper for specifics):

3.1 Transaction Folding

Utilizing the programmability of CKB Cells, multiple CKB transactions can correspond to a single Bitcoin RGB++ transaction, thus allowing the low-speed, low-throughput Bitcoin chain to be scaled using the high-performance CKB chain. If we further expand "transaction folding," in principle, not every state change needs to be synchronized on Bitcoin, effectively adding an "off-chain verification" option to CKB.

3.2 Unowned Contracts

Unowned contracts refer to any individual being able to change the state as long as they meet the contract's constraints, without requiring a designated digital signature provider to make changes. This type of contract creates a foundation for complex contract forms such as AMM.

3.3 Non-interactive Transfers

One point of the RGB protocol transfer is that both parties need to communicate certain information to complete the transfer, which brings certain advantages (such as not receiving scam tokens), but also increases user understanding difficulty and product complexity. RGB++ can leverage the current advantages by placing the interaction behavior within the CKB environment, using a send-receive two-step operation to achieve non-interactive transfer logic. This transfer logic is the basis for implementing large-scale airdrops.

3.4 AMM+DEX

The grid AMM design of CKB can be introduced to realize a market maker model based on UTXO. Although it differs from the price curve market-making model of Uniswap, it is already a significant advancement for the UTXO model.

4. The Role of the RGB++ Protocol

Since the protocol has just been proposed and specific development implementations have not yet been completed, along with many people not being sufficiently familiar with the RGB protocol itself, there is still a lack of sensitivity to the "chemical reactions" that RGB++ may trigger. I will elaborate on my views regarding the role of the RGB++ protocol from the following perspectives:

4.1 For CKB: RGB++ will be one of its key anchors in competing for the Bitcoin orthodox L2 market

CKB enjoys "orthodoxy" due to its POW mechanism and enhanced "UTXO" model, but its network and ecosystem development did not perform outstandingly after early investments from many star institutions. Its shift to Bitcoin L2 this year represents a significant opportunity for CKB. On 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 topics. In a conversation with Cipher, he presented a very beneficial viewpoint: The key point in the Bitcoin L2 competition lies in L1. RGB++ creates a deeper connection between CKB and the Bitcoin main chain, bringing more "orthodoxy," which is why I believe it is one of the key anchors. As a side note: Regarding "orthodox" L2 The concept of L2 has relatively matured from its development on ETH. As various L2 solutions and modular developments progress, the definition of L2 has become increasingly blurred. On ETH, it is more aligned with a pragmatic approach, and the concept of "orthodoxy" is gradually fading. However, for the Bitcoin network, the concept of "orthodoxy" has consistently presented a strong signal throughout its development. Currently, in my personal view, the strength of L2's "orthodoxy" (from high to low) is as follows: 1) Lightning Network, RGB, BitVM These three are relatively well-known, and overall, the paths they take to achieve their goals are fundamentally different, targeting different points. Currently, the Lightning Network is the most mature, followed by RGB, and finally BitVM. 2) Sidechains Such as Liquid, Stacks, CKB, etc., most of them are still based on UTXO architecture, with certain transformations or innovations to enhance scalability (such as privacy and programmability) and optimize consensus mechanisms. Sidechains can be understood as experimental chains for BTC, testing some new features or temporarily unachievable functions on the BTC main chain. 3) Others This part may include "L2 based on cross-chain protocols," "L2 based on EVM," etc. I generally agree with Professor Ajian's view:

Source: https://twitter.com/AurtrianAjian/status/1755121187741720964

4.2 For RGB: RGB++ expands its potential for integration with other UTXO architecture public chains

The RGB protocol itself has the potential to integrate with other UTXO architecture public chains, and the official Twitter of the LNP/BP Association indicates support for interoperability with Liquid.

Source: https://x.com/lnp_bp/status/1747930079252951058?s=20 Through the combination of CKB and some RGB technologies, the "practical effectiveness" of this integration will be validated to some extent. Furthermore, if we abstract the RGB++ protocol into a broader extension layer for connecting the RGB protocol with all UTXO architecture public chains that have certain scalability, its narrative and value will be greatly enhanced. This is also a direction I believe Cipher may strive for in the next phase. At the same time, this provides some alternative options for project development within the RGB ecosystem, which differ from simple "multi-signature cross-chain bridges" and are based on native methods.

For other Bitcoin L2: Providing a technical reference for integrating the RGB protocol

Cipher's parsing of the RGB technical architecture will provide a good thinking model for technical personnel of other L2s. They can combine the technical characteristics and advantages of their own projects with some of the technologies they need from RGB, then "combine" them into a new product paradigm, even achieving "running ahead" (here, "running ahead" is not a derogatory term; it reflects the combinability of technologies and the innovation within the BTC ecosystem, while "running ahead" will also promote the popularization and development of the RGB protocol). In summary, although RGB++ is currently only at the white paper stage, I am relatively optimistic about it from a theoretical perspective. This could bring new vitality to the RGB protocol and potentially awaken the energy of the CKB network.