On February 23, CELL Studio founder/Nervos CKB co-founder/RGB++ protocol author Cipher, Web3 Chinese KOL Huajiao, RGB Chinese evangelist Da Pangdun, geek Web3 founder Fasut, CKB Ecological Fund CMO/SeeDAO initiator Baiyu and CKB community ambassador CyberOrange talked with everyone about the past and present of the RGB++ protocol.

The following is the key content organized according to the audio:

The development history of RGB protocol

The RGB protocol can be traced back to the client verification proposed by Peter Todd in 2016. The core idea is that we don’t need everything to be on the chain, we only need the blockchain to do what it can do, such as light Quantitative verification. This is a generation.

The second generation was Giacomo Zucco, who was inspired by Peter Todd's ideas and initially conceptualized the RGB protocol, but this MVP was very incomplete.

The Sandaime is now Maxim Orlovsky. More than 90% of the code of the RGB protocol was contributed by Dr. Maxim. He did not raise funds and relied entirely on donations and out-of-pocket expenses. However, donations can only solve some personal economic problems and do not have enough funds to recruit a large number of engineers. In addition, Dr. Maxim also established the LNP/BP Standards Association to promote the RGB protocol towards practical applications.

For more information about the RGB protocol and the LNP/BP Standard Association, welcome to watch the series of popular science videos produced by Web3 Chinese KOL Huajiao.

RGB Chinese evangelist Da Pangdun added that RGB is regarded as a more orthodox Bitcoin expansion plan and has many people’s hopes. However, the LNP/BP Standard Association is non-profit and mainly relies on donations. It does not have enough funds to recruit developers, resulting in slow progress of the RGB protocol. There is currently no roadmap and there are many uncertainties, which will further slow down other projects. The development progress of RGB-based projects forms a "vicious cycle".

In addition, the current control of RGB and its association mainly lies with Dr. Maxim alone. Big Fat Dun believes that the association should be more open.

The birth background of RGB++

Cipher said that he saw an article introducing RGB a few months ago. The article mentioned that the RGB protocol has disadvantages in data transmission and user interaction. For example, RGB transfer requires both parties to be online at the same time and requires interactive operations. The sender It is also necessary to provide historical data proof of the assets, etc. Cipher believes that the RGB protocol is very elegant, but the user experience is not friendly enough and even troublesome, and there are many problems in practice at the application layer. For example, RGB data is scattered in everyone’s hands, making it very difficult to build applications such as DeFi or DEX. .

As a product manager, he is keenly aware that these difficulties or disadvantages of the RGB protocol can actually be solved directly on the blockchain, such as P2P networks that do not rely on anyone, shared data, virtual machines that can verify transactions, and non-interactive style operating experience. This is also the earliest core idea of ​​RGB++, which is to entrust the client verification outside the RGB protocol chain to a Turing-complete blockchain based on the UTXO model and PoW consensus mechanism.

RGB++ has many advantages, such as enabling non-interactive transactions, transaction folding, and a very friendly user experience. The disadvantage is that privacy is not as good as RGB itself, but it is only reduced to the privacy protection level of the Bitcoin blockchain. In addition, it should be pointed out that RGB's privacy protection is not perfect, because the sender needs to provide all historical proof of the asset, and the receiver can see the sender's previous transaction records. On CKB, the Mimblewimble protocol can actually be used to hide transaction amounts and cut off transaction history, giving RGB++ better privacy. However, the team in the first stage did not have the energy to do this.

In addition, Cipher also mentioned some controversies about the RGB++ protocol on X. He believes that everyone can have academic discussions, but they should not call it a scam right away.

Finally, Cipher also touched on compatibility issues. RGB uses AIuVM, and the first version of RGB++ uses CKB-VM, which is technically incompatible. However, thanks to CKB-VM using the RISC-V instruction set, AIuVM can be compiled into CKB-VM in the future. , make an RGB compatible layer. In addition, assets can also be connected through jump.

What differentiates the RGB++ protocol from RGB

CyberOrange mentioned that the two most important technologies of RGB are one-time sealing and client verification. The former allows RGB assets to be protected by the Bitcoin blockchain, and the latter mainly verifies transactions of RGB assets. The RGB++ protocol, in addition to allowing RGB users to use client-side verification, also gives them an additional option - CKB on-chain verification. If the transaction amount is not very large, users do not need to do a complete client verification themselves, but choose CKB script verification.

The second point is privacy. The RGB++ protocol puts data on the CKB chain and lets CKB act as the DA layer. Its privacy is lower than the original RGB protocol, which Cipher has introduced in detail earlier. Just like a coin has two sides, using CKB as the DA layer will make it much simpler to design DEX or other DeFi applications.

The third point is the difference in expansion capabilities. Theoretically, RGB's expansion capability may be stronger because its client verification does not require a blockchain, but in fact, the RGB++ protocol can also use other mechanisms to achieve expansion.

Finally, CyberOrange mentioned that RGB++ and RGB are also compatible. RGB supports jump-like operations, allowing RGB assets to jump from one UTXO chain to another UTXO chain, and the CKB blockchain can also support this function, thus opening up RGB assets and RGB++ assets.

Fasut, the founder of "Geek Web3", mentioned that many concepts of RGB are similar to state channels, and they all need to be verified by yourself. The RGB network is like a network composed of countless OTC players. Transfers do not require the consensus of everyone, only the consent of both parties to the transaction is enough, and the content of the transaction is only known to both parties to the transaction.

However, Fasut mentioned that since the RGB transaction sender needs to provide all historical records of the asset, if the asset changes hands a lot and the amount of data is large, it may cause storage pressure and transmission pressure. In addition, RGB also has the problem of fragmented asset storage. Everyone only stores asset data related to themselves, and everyone's client stores different data. If there is a problem with a user's client, the data is not backed up. , then his assets will never be touched. So Fasut believes RGB sacrifices usability for privacy.

In Fasut's view, RGB++ is more like "optimistic RGB", similar to Optimistic Rollup, which requires users to believe that the third party (here, the CKB blockchain) will not do evil. RGB++ puts all RGB data on the CKB chain, and at the same time, CKB nodes verify RGB asset transactions, achieving availability and saving a lot of trouble in the traditional RGB protocol. Regarding RGB and RGB++, "Geek Web3" has published a very comprehensive article "From RGB to RGB++: How CKB empowers the Bitcoin Ecological Asset Protocol". Friends who have not read it yet are welcome to click on the link to read it.

However, in CyberOrange's view, RGB++ does not force users to trust CKB, but provides an additional choice. Of course, users can also use the RGB client to verify all transactions.

Regarding the data storage pressure mentioned earlier, Huajiao clarified that this is no longer a problem. Dr. Maxim has considered this before, and there are wallets with embedded local databases, so users no longer need to run RGB nodes individually. Regarding the invoice of RGB transactions, Huajiao consulted RGB developers. Offline transactions can be realized on the main network, but not in the Lightning Network channel. Both parties to the transaction must be online at the same time. Regarding ownerless contracts, RGB has no global state, so it will be difficult to make DeFi applications based on RGB. Dr. Maxim designed Bifrost for this purpose, which is equivalent to a sub-version of the Lightning Network. Each Bifrost channel is equivalent to a Layer3 can achieve expansion in more senses.

RGB++ schedule

Cipher hopes to complete the MVP of the first version of the RGB++ protocol by the end of March this year, including the launch of RGB++ on the main network, a DEX on Layer 2 that supports fungible tokens and NFTs, and the corresponding wallets and browsers.

In addition, Cipher is also recruiting developers familiar with Rust and C language for the RGB++ protocol. Interested partners can contact him individually.

Q&A session

Q1: How friendly is RGB++ to developers?

Cipher: Whether it is RGB or RGB++, the main work of developers is off-chain, not on the Bitcoin chain. For RGB, most of the work of developers is how to assemble RGB transactions, how to generate RGB certificates, how to write contracts on RGB, etc. What needs to be done on RGB++ is the same, but many things CKB blockchain It was solved directly. Taking DEX as an example, on CKB it becomes how to make a DEX that can accept RGB++ assets. Its development difficulty is not much different from that of developing other contracts on CKB. At present, the development tools on CKB are relatively complete. A skilled developer can probably get started after a few days of study.

Q2: What is the relationship between RGB++ and CKB tokens?

Cipher: Every RGB++ transaction will simultaneously send out a Bitcoin transaction and a CKB transaction. Every user in the RGB++ ecosystem will have a corresponding UTXO (Cell) on the CKB chain for their transactions, assets or status, which will occupy and use part of the CKB. In addition, developers will also develop contracts on the CKB chain.

Q3: After CKB obtains RGB transactions, will it be compressed?

Cipher: "RGB++ Protocol Light Paper" mentions transaction folding, which can correspond to multiple CKB transactions and one Bitcoin RGB++ transaction, so that the low-speed and low-throughput Bitcoin chain can be expanded with a high-performance CKB chain.

The other is state compression. The CoTA protocol has been implemented very early. No matter how many tokens you hold, they can be compressed into a 32-byte space. Whether RGB++ can achieve similar state compression has not been done much research yet, but this is a good direction.

Q4: If I develop on CKB, are there supporting tools like Subgraph, Oracle, etc.? Or do you need to wait for third party support?

CyberOrange: The oracle is currently not available on the CKB chain. For some other interfaces, CKB has a data encoding and decoding standard. You can use that standard to parse data, but you may need to write something manually.

Q5: What is the tps of CKB?

CyberOrange: If it is a simple transfer, CKB’s tps can reach more than 300.

Q6: The article on RGB++ security mentioned that Bitcoin requires 6 blocks to be confirmed before it is almost impossible to be reverted, and CKB requires about 20 blocks. Will this have an impact on the user experience of RGB++? Maybe the user doesn’t want to wait that long?

Cipher: If you just send a layer one transaction, it will send a CKB transaction simultaneously. This mainly depends on the speed of Bitcoin’s block production. You don’t need to wait for so many block confirmations. It is actually the same as Bitcoin’s The transfer experience is the same. You mentioned that you need to wait for 6 blocks to be confirmed. This is because the assets are jumped from Bitcoin Layer 1 to CKB. In order to ensure security, 6 Bitcoin blocks are required to be confirmed before the jumped assets can be unlocked on CKB. operate. This is controlled by smart contracts and does not require multiple signatures or third parties. For subsequent operations on the CKB chain, you only need to wait for the ten-second block time on CKB. If you want to jump back to the Bitcoin chain, you need to wait for more than 20 CKB block confirmations to ensure security. Jump operations are not frequent, so the impact on user experience is not that big, and other cross-chain solutions often require a relatively long wait.

Q7: Will the DEX planned to be released before the end of March support assets such as Bitcoin Inscription?

Cipher：是的。

$CKB #RGB