RGB++: Contribute to the orthodox Bitcoin L2

Author: Twitter@DaPangDunCrypto; Source: SevenUp DAO

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 and is not strictly an RGB ecological project, but it expands the usage scenarios of RGB technology;

1.2 It expands the capabilities of the current RGB protocol

Solve the practical problems of the current RGB protocol Technical issues in implementation and provide more possibilities, such as "verification link", "contract programmability", "Turing complete virtual machine", etc.;

1.3 It is implemented throughUTXOisomorphic 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 ownership change. I think this idea of ​​isomorphic mapping has strong scalability.

2. Why is the RGB++ protocol proposed?

Familiar My friends know that I am a researcher who is 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.1RGB development Relatively slow

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

The second reason is that the number of developers participating in the entire protocol layer is small, from the personnel composition of LNP/BP to the current The number of ecological projects is evident.

2.2 The development of RGB is affected by some uncontrolled factors

For example: RGB is generally built on the Lightning Network, but the current bolt-In cannot support RGB contracts very well, so the LNP/BP Association proposed a new Lightning Network standard bifrost, but this requires A lot of work needs to be done, and we even need to wait for the overall development of the Lightning Network;

Another example: RGB transfer will involve the transfer of invoice and committee. Currently, it can It is carried out through networks such as web2 (Twitter, tg, etc.) or p2p, but if you look at it from a unified level, it needs a standard transmission standard. This is a storm node, but building such a network also requires a lot of work. To do.

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

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

These problems make RGB seem somewhat alien in this competitive market, much like the development status of BTC in the early era, 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, 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 and problems to be solved by the RGB++ protocol.

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 fact that the core point of RGB "UTXO" and the underlying architecture of CKB have the same origin, and proposes a "isomorphic mapping" solution, and The protocol content of “RGB++” has gradually been 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 to CKB's Cell through the lock in Cell

2) As a verification, off-chain client verification can be transformed into CKB’s on-chain public verification, and the verification data and status can correspond to Data and type in Cell

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

Through "isomorphic mapping", the process of parsing by committee on RGB on CKB is realized, and with compatibility, users can still parse on RGB. , which 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 (please refer to the white paper for details):

3.1 Transaction Folding

Using the programmability of CKB Cell, you can Multiple CKB transactions correspond to one Bitcoin RGB++ transaction, so that the low-speed and low-throughput Bitcoin chain can be expanded with a high-performance CKB chain.

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

3.2 Ownerless contract

Unowner 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 foundation for complex contract methods such as AMM

3.3 Non-interactive transfer

A point to note about RGB protocol transfer is that both 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 and place interactive behaviors in the ckb environment, using 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 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.

Four. The role of the 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 may be caused by RGB++. 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 shine 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 put forward a point of view that benefited me very much:

The key point in the Bitcoin L2 debate is L1

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

Digression: About "orthodox" L2

L2 It is said that the concept of relatively mature concept is developed from ETH. With the development of various L2 solutions and modularization, the definition of L2 is becoming more and more blurred. On ETH, it is closer to the pragmatic idea. The so-called " The concept of "orthodoxy" is slowly fading.

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 paths to achieve the three are There are essential differences, and the target points are also different. At the current level of development, the Lightning Network is relatively the most mature, followed by RGB, and finally BitVM

2 ) Sidechain

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

The side chain 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 "L2 of cross-chain protocols", "L2 based on EVM", etc., I basically agree with Teacher Aiian's views

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 to be 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/np_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.