RGB++: Contributing to Orthodox Bitcoin L2

Author: DaPangDun (X@DaPangDunCrypto)

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

Before this agreement came out, I had several in-depth exchanges with Cipher about the RGB protocol and discussed the prototype concept of the agreement, so I wrote a short article Explain my popular understanding of the RGB++ protocol, personal opinions and what I think the possible role of this protocol is.

1. Overview of RGB++: Expanding the usage scenarios of RGB technology

In summary, understanding RGB++ is divided into the following points:

1.1 It is an extended protocol based on RGB

It utilizes some technologies in the RGB protocol. Strictly speaking, it is not entirely an RGB ecological project, but it expands the usage scenarios of RGB technology.

1.2 It extends the capabilities of the current RGB protocol

It solves the technical problems of the actual implementation of the current RGB protocol and provides more possibilities, such as "verification link", "contract programmability", "Turing complete virtual machine", etc.

1.3 It is implemented through UTXO isomorphic mapping

Map Bitcoin UTXO to the Cell of Nervos CKB, and use script constraints on the CKB chain and Bitcoin chain to verify the correctness of the state calculation and the validity of the changed ownership. I think this idea of ​​isomorphic mapping has strong scalability.

2. Why is the RGB++ protocol proposed?

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 the development of the ecosystem. During the ongoing research, I found that although the RGB protocol is very beautiful in design, there are some problems in the actual implementation process:

2.1 RGB development Relatively slow

One ​​of the reasons is that most designs are new concepts or form a new standard, which require detailed Global conception and new code implementation.

The second reason is that the number of developers participating in the entire protocol layer is relatively small, which can be seen from the personnel composition of LNP/BP and the number of current ecological projects.

2.2 The development of RGB will be affected by some uncontrolled factors

For example: RGB is generally built on the Lightning Network. However, the current bolt-ln cannot support the RGB contract well, so the LNP/BP Association proposed a new Lightning Network standard bifrost, but This again requires a lot of work, and even needs to wait for the overall development of the Lightning Network.

Another example: RGB transfer involves the transfer of invoice and committee. Currently, it can be done through networks such as web2 (Twitter, tg, etc.) or p2p To carry out, but if you look at it from a unified level, you need a standard transmission standard to carry out, which is the storm node, but building such a network also requires a lot of work.

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

In other words, even if v0.11 is now fully released, it still takes a lot of time to test the performance and reliability of the virtual machine, and it also takes a lot of time to accumulate experience in developing code through AluVM and even the standard library. .

These problems make RGB somewhat alien in this competitive market, much like the development status of BTC in the early days, which will bring a lot of uncertainty. The impact of market cycles (missing the capital bull market period), the impact of emotions, the impact of the integration of other new technologies (the combination of other technologies and some RGB technologies to achieve a "jump start"), etc.

To sum it up in one sentence, it is:RGB has great potential for growth, but the complete implementation of the protocol will take a long time and be uncertain.

This is the background raised by the RGB++ protocol and the problems to be solved.

3. Technical focus of RGB++ solution: isomorphic mapping

Therefore, in the early exchanges, the focus was on "how to solve these problems in RGB implementation" and "whether CKB's existing technology can be used to solve this problem to a certain extent."

Cipher creatively takes advantage of the homologous characteristics of RGB's core point "UTXO" and CKB's underlying architecture, proposes a "isomorphic mapping" solution, and The protocol content of “RGB++” was gradually laid out.

See the picture below, which combines two key points in the RGB protocol with the CKB architecture:

1. As an RGB container, UTXO  can be mapped with CKB's Cell  through the lock in Cell.

2. As verification, off-chain client verification can be transformed into CKB's on-chain public verification , the verified data and status can correspond to the data and type in Cell.

Source: https://talk.nervos.org/t/rgb-protocol-light-paper/7733

Through "isomorphic mapping", the process of parsing committee on RGB on CKB is realized, and with compatibility, users can still perform parsing on RGB Analysis, this is a very interesting effect.

If you analyze it further, Cipher actually "analyzes" and "modularizes" RGB technology, and then thinks about whether a certain module can have other technical routes or alternative options, thus creating more possibilities.

After "isomorphic mapping", scalability comes naturally, and various extended functions can be realized:

3.1 Transaction folding

Using the programmability of CKB Cell, multiple CKB transactions can be combined with one Corresponds to every Bitcoin RGB++ transaction, so that the low-speed and low-throughput Bitcoin chain can be expanded using the high-performance CKB chain.

If "transaction folding" is expanded, in principle, not every state change needs to be synchronized on Bitcoin, which is equivalent to adding "transaction folding" to CKB. Off-chain verification” option.

3.2 Ownerless contract

The ownerless contract refers to Anyone can change the status under the premise of meeting the constraints of the contract without requiring the designated digital signature provider to make changes.

This kind of contract creates the basis for complex contract methods such as AMM.

3.3 Non-interactive transfer

RGB protocol transfer One point to note is that the two parties need to communicate certain information to complete, which brings certain advantages (you will not receive scam tokens, etc.), but it also increases the difficulty of user understanding and the complexity of the product. RGB++ can take advantage of the current advantages to place interactive behaviors in the CKB environment and use a two-step send-receive operation to implement non-interactive transfer logic.

This transfer logic is the basis for large-scale airdrops.

3.4 AMM+DEX

Network that can introduce CKB Lattice AMM design is used to implement a UTXO-based market maker model. Although it is different from Uniswap's price curve market-making model, it is already a great progress for the UTXO model.

4. The role of RGB++ protocol

Because the protocol just It is proposed that the specific development and implementation have not been completed, and many people do not know enough about the RGB protocol itself, so they are not very sensitive to the "chemical reactions" that RGB++ may cause. I will elaborate on my understanding of the RGB++ protocol from the following levels Role perspective:

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

CKB enjoys "legitimacy" due to its POW mechanism + enhanced "UTXO" model, but its network and ecological development did not take off after the investment of many star institutions in the early stage. Eye performance.

After it switches to Bitcoin L2 this year, I think this is a major opportunity period for CKB. On the one hand, the relevant underlying technology and infrastructure have been gradually improved after several years of development. On the other hand, it has coincided with this round of hot spots.

During the chat with Cipher, he made a point that benefited me very much:The key point in the Bitcoin L2 debate lies in L1.

RGB++ creates a deeper connection between CKB and the Bitcoin main chain, thus bringing more "legitimacy" to it ”, which is why I think it’s one of the key anchors.

Digression: About "orthodox" L2

The concept of L2 is relatively mature. Developed from ETH, with the development of various L2 solutions and modularization, the definition of L2 is becoming more and more blurred, and it is closer to the pragmatic idea on ETH. The so-called "orthodox" concept is gradually Watered down.

But for the Bitcoin network, the concept of "orthodoxy" has always been presented as a relatively strong signal throughout its development process. At the moment, according to my personal opinion, the “orthodoxy” strength of L2 (from high to low) is:

1. Lightning Network, RGB , BitVM

Everyone is familiar with these three. Generally speaking, the implementation paths of the three are essentially different, and for The points are also different. The current development level of Lightning Network is relatively mature, followed by RGB, and finally BitVM.

2. Side chain

Such as Liquid, Stacks, Most of them, such as CKB, are still based on the UTXO architecture, with certain deformations or innovations to achieve improvements in scalability (such as privacy, programmability) and optimization of the consensus mechanism.

Sidechain can be understood to a certain extent as an experimental chain of BTC, experimenting with some new functions or functions that are temporarily unavailable on the BTC main chain.

3. Others

This part may include "based on "Cross-chain protocol L2", "EVM-based L2", etc., I basically agree with Teacher Ajian:

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

4.2 For RGB: RGB++ expands the possibility of combining it with other UTXO architecture public chains

The RGB protocol itself has the possibility of being combined with other UTXO architecture public chains. The official recommendation of the LNP/BP Association indicates that it will support interoperability with Liquid.

Source: https://x.com/lnp_bp/status/1747930079252951058?s=20

Through the combination of CKB and RGB partial technologies, the "practical effectiveness" of this combination will be verified to a certain extent.

Taking a closer look: if we abstract the RGB++ protocol again and turn it into a broader extension layer, used to connect the RGB protocol and all UTXO architectures And for a public chain with certain scalability, its narrative and value will be greatly enhanced. This is also the direction I think Cipher may work towards in the next stage.

At the same time, this also provides some other alternatives for the development of projects in the RGB ecosystem, which are different from the simple "multi-signature cross-chain bridge" , but based on the native method.

For other Bitcoin L2: Provides technical reference for integrating RGB protocol

Cipher's analysis of the RGB technical architecture will provide a good thinking example for other L2 technical personnel.

They can combine the technical characteristics and advantages of their own projects, integrate some of the technologies they need in RGB, and then "combine" them into a new product paradigm, or even Achieve a "front-runner" ("front-runner" here is not a derogatory term, it reflects the combination of technology and the innovation in the development of the BTC ecosystem. At the same time, "front-runner" will still promote the popularity and development of the RGB protocol) .

In general, although RGB++ is only in the white paper stage now, from a theoretical point of view, I am more optimistic about it, and it will bring more benefits to RGB. The agreement brings new blood and may also awaken the vitality of the CKB network.