Partnered With:

RGB++: Adding bricks and tiles to the Layer 2 of the orthodox Bitcoin.

Read this article in 8 Minutes

Although RGB++ is still in the whitepaper stage, theoretically it could bring new vitality to the RGB protocol and awaken the CKB network.

The content you provided is:

Original author: DaPangDun

On February 13th, Cipher, co-founder of CKB, proposed the RGB extension protocol: RGB++. This immediately caught the attention of many people in the market and to some extent affected the secondary market price of CKB.

Before this agreement came out, I had several in-depth discussions with Cipher about the embryonic idea of the RGB protocol. Therefore, I wrote a short article to explain my popular understanding and personal opinions on the RGB++ protocol, as well as what I think its possible role might be.

1. Overview of RGB++: Expanding the Usage Scenarios of RGB Technology

Generally speaking, understanding RGB++ can be summarized as follows:

1.1 It is an RGB-based extension protocol

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

1.2 It expands the capabilities of the current RGB protocol

Solved the technical problems of the RGB protocol in practical implementation, and provided more possibilities, such as "verification link", "contract programmability", "Turing complete virtual machine", etc.

1.3 It is achieved through UTXO isomorphic mapping

Map Bitcoin UTXOs to Cells on Nervos CKB, and use script constraints on the CKB and Bitcoin chains to verify the correctness of state computation and the validity of ownership changes. I believe this isomorphic mapping approach has strong scalability.

2. Why propose the RGB++ protocol?

My friends who are familiar with me know that I am a researcher who specializes in the RGB protocol and have been keeping up with the development and ecosystem of the RGB protocol. During my continuous research, I found that although the RGB protocol is well-designed, there are some problems in its actual implementation process:

2.1 RGB development is relatively slow

One reason is that the majority of the designs are new concepts or form a new standard, which requires meticulous global thinking and a completely new code implementation.

The second reason is that there are fewer developers involved in the entire protocol layer, as can be seen from the personnel composition of LNP/BP and the number of current ecological projects.

2.2 RGB development will be affected by some uncontrollable factors

For example: RGB generally needs to be built on the Lightning Network. However, the current bolt-ln cannot support RGB contracts well. Therefore, the LNP/BP Association has proposed a new Lightning Network standard called bifrost. But this requires a lot of work to be done, and even waiting for the overall development of the Lightning Network.

For example, in the transfer of RGB, the transmission of invoice and committee is involved. Currently, it can be done through networks such as web2 (Twitter, Telegram, etc.) or P2P. However, if we look at it from a unified perspective, a standard transmission protocol is needed. This is where the Storm node comes in, but building such a network requires a lot of work to be done.

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

That is to say, even if v0.11 is completely released now, it still takes a lot of time to verify the performance and reliability of the virtual machine, and it also takes a lot of time to accumulate experience and even standard libraries through AluVM development code.

These issues make RGB somewhat of an outlier in this fast-paced market, much like the development status of BTC in its early days. This will bring about a lot of uncertainty, including the impact of market cycles (missing out on bull markets), emotional influence, and the impact of other new technology integrations (the combination of other technologies with some of RGB's technologies to achieve a "head start").

In summary, RGB has great potential for growth, but the full implementation of the protocol will take a long time and is uncertain.

This is the background and problem to be solved proposed by the RGB++ protocol.

3、RGB++ Solution Technical Focus: Isomorphic Mapping

Therefore, in the early communication, the focus was on "how to solve these problems in the implementation of RGB" and "whether existing CKB technologies can be utilized to solve this problem to some extent".

Cipher creatively utilizes the core point "UTXO" of RGB and the underlying architecture of CKB, and proposes the "isomorphic mapping" scheme, gradually laying out the protocol content of "RGB++".

Please refer to the following image. He combined two key points in the RGB protocol with the architecture of CKB:

1) UTXOs that serve as RGB containers can be mapped to CKB cells through the lock in the cell.

2) The off-chain client verification used for validation can be transformed into on-chain public validation for CKB, and the validated data and state can correspond to the data and type in the Cell.