On February 23rd, CELL Studio founder/Nervos CKB co-founder/RGB++ protocol author Cipher, Web3 Chinese KOL Huajiao, RGB Chinese evangelist Big Fat Dun, Geek Web3 founder Fasut, CKB ecosystem fund CMO/SeeDAO initiator Baiyu, and CKB community ambassador CyberOrange, held a live event at X Space to discuss the past and present of the RGB++ protocol.
The live event lasted for an hour and a half, with a lot of valuable content. If you haven't listened to the audio playback yet, you can click the link below: https://twitter.com/ckbcell/status/1760995772840268105?s=61&t=IYlGL8YIKMjrbZkcBRmuJA
Here are the key points from the audio:
1. The development history of the RGB protocol#
The RGB protocol can be traced back to Peter Todd's client-side validation proposal in 2016. The core idea is that we don't need to put everything on the chain, we only need the blockchain to do what it can do, such as lightweight validation. This is the first generation.
The second generation is Giacomo Zucco, who was inspired by Peter Todd's ideas and initially conceptualized the RGB protocol, but the MVP was very incomplete.
The third generation is Maxim Orlovsky. Dr. Maxim contributed over 90% of the code for the RGB protocol. He did not receive any funding and relied solely on donations and personal funding. However, donations can only solve some personal financial problems and there is not enough funding to recruit a large number of engineers. In addition, Dr. Maxim also established the LNP/BP standard association to promote the practical application of the RGB protocol.
For more information about the RGB protocol and the LNP/BP standard association, please watch the series of YouTube videos produced by Web3 Chinese KOL Huajiao: https://www.youtube.com/playlist?list=PL9_Eoig1ztix_j6N6hqswuvDv3FDiSoJO
RGB Chinese evangelist Big Fat Dun added that RGB is considered a more orthodox Bitcoin scaling solution and is highly anticipated by many people. However, the LNP/BP standard association is non-profit and relies mainly on donations. There is not enough funding to recruit developers, which has led to slow progress in the RGB protocol. Currently, there is no roadmap and there is a lot of uncertainty, which further slows down the development progress of other projects based on RGB, forming a "vicious cycle".
In addition, the control of RGB and its association is mainly in the hands of Dr. Maxim alone. Big Fat Dun believes that the association should be more open.
2. The background of the birth of RGB++#
Cipher mentioned that a few months ago, he read an article introducing RGB, which mentioned the disadvantages of the RGB protocol in terms of data transmission and user interaction, such as the need for both parties to be online for RGB transfers, interactive operations, and the sender needing to provide historical data proof of assets, etc. Cipher believes that the RGB protocol is elegant, but the user experience is not friendly enough, and even troublesome. There are also many problems in practical application, such as the data of RGB being scattered in the hands of each person, making it very difficult to do DeFi or DEX applications.
As a product manager, he keenly realized that these difficulties or disadvantages of the RGB protocol can be directly solved on the blockchain, such as not relying on any P2P network, sharing data, a virtual machine that can verify transactions, and non-interactive operation experience. This was the core idea of RGB++ in the early days, delegating the tasks of client-side validation outside the RGB protocol to a Turing-complete blockchain based on the UTXO model and PoW consensus mechanism, which is CKB.
RGB++ has many advantages, such as achieving non-interactive transactions, transaction folding, and a very user-friendly experience. The disadvantage is that the privacy is not as good as RGB itself, but it is only reduced to the level of privacy protection in the Bitcoin blockchain. In addition, it should be noted that the privacy protection of RGB is not perfect because the sender needs to provide all the historical proofs of the assets, and the recipient can see the sender's previous transaction records. On CKB, Mimblewimble protocol can be used to hide transaction amounts and break transaction history, allowing RGB++ to have better privacy. However, the team does not have the resources to do this in the first phase.
In addition, Cipher also mentioned some controversies about RGB++ on X. He believes that academic discussions can be made, but it should not be labeled as a scam right away. Click here to see Cipher's response to the controversy.
Finally, Cipher also talked about compatibility. RGB uses AIuVM, and the first version of RGB++ uses CKB-VM, which are technically incompatible. However, thanks to the RISC-V instruction set used by CKB-VM, AIuVM can be compiled onto CKB-VM in the future to create a compatibility layer for RGB. In addition, asset interoperability can be achieved through jumps.
3. The differences between RGB++ and RGB#
CyberOrange mentioned that the two most important technologies of RGB are one-time sealing and client-side validation. The former protects RGB assets on the Bitcoin blockchain, and the latter mainly verifies the transactions of RGB assets. In addition to allowing RGB users to use client-side validation, the RGB++ protocol also gives them an additional choice - CKB chain validation. If the transaction amount is not large, users can choose CKB script validation instead of doing a complete client-side validation.
The second point is privacy. RGB++ puts the data on the CKB chain and allows CKB to act as the DA layer. The privacy of RGB++ is lower than that of the original RGB protocol, as detailed by Cipher earlier. Just like a coin has two sides, using CKB as the DA layer makes it much easier to design DEX or other DeFi applications.
The third point is the difference in scalability. Theoretically, RGB may have stronger scalability because its client-side validation does not require the blockchain. However, in practice, RGB++ can also achieve scalability through other mechanisms.
Finally, CyberOrange mentioned that RGB++ and RGB can be compatible. RGB supports operations similar to jumps, allowing RGB assets to jump from one UTXO chain to another UTXO chain. CKB blockchain also supports this functionality, allowing the connection of RGB assets and RGB++ assets.
Fasut, the founder of Geek Web3, mentioned that many of the concepts of RGB are similar to state channels, both requiring verification by yourself. The RGB network is like a network composed of countless OTC players, where transfers do not require consensus from everyone, only the agreement of the two parties involved in the transaction, and only the two parties know the content of the transaction.
However, Fasut mentioned that due to the sender of the RGB transaction needing to provide all the historical records of the assets, if the asset has been transferred many times and has a large amount of data, it may bring storage and transmission pressure. In addition, RGB also has the problem of fragmented storage of assets, with each person only storing asset data related to themselves. If a user's client has a problem and the data is not backed up, their assets will be stuck forever. Therefore, Fasut believes that RGB sacrifices usability for privacy.
In Fasut's view, RGB++ is more like "Optimistic RGB", similar to Optimistic Rollup, which requires users to trust a third party (in this case, the CKB blockchain) not to act maliciously. RGB++ puts all the data of RGB on the CKB chain and verifies the transactions of RGB assets through CKB nodes, achieving usability and saving a lot of trouble for the traditional RGB protocol. Geek Web3 has published a comprehensive article about RGB and RGB++, which is highly recommended for those who haven't read it yet. Click here to read the article.
However, CyberOrange believes that RGB++ does not force users to trust CKB, but provides an additional choice. Users can also use the RGB client to verify all transactions.
Regarding the storage pressure mentioned earlier, Huajiao clarified that this is no longer a problem. Dr. Maxim had already considered this, and the wallet has an embedded local database, so users no longer need to run an RGB node separately. Regarding the invoice for RGB transactions, Huajiao consulted the RGB developers. Offline transactions can be realized on the mainnet, but not in Lightning Network channels. Both parties to the transaction must be online simultaneously. Regarding masterless contracts, RGB does not have a global state, so it is difficult to build DeFi applications based on RGB. Dr. Maxim designed Bifrost for this purpose. It is like a subversion of the Lightning Network, where each Bifrost channel is like a Layer3, allowing for more meaningful scalability.
4. RGB++ timeline#
Cipher hopes to complete the first version of the RGB++ protocol MVP by the end of March this year, including the launch of RGB++ on the mainnet, a DEX on Layer2 that supports fungible tokens and NFTs, as well as corresponding wallets and browsers.
In addition, Cipher is also recruiting developers familiar with Rust and C languages for the RGB++ protocol. Interested individuals can contact him separately.
5. Q&A session#
Q1: How developer-friendly is RGB++?
Cipher: Whether it's RGB or RGB++, the main work for developers is off-chain, not on the Bitcoin chain. For RGB, most of the work for developers is how to assemble RGB transactions, generate RGB proofs, and write contracts on RGB, etc. The same tasks need to be done on RGB++. The difference is that many things are directly solved by the CKB blockchain. For example, for DEX, it becomes how to make a DEX that can accept RGB++ assets on CKB. The development difficulty is not much different from developing other contracts on CKB. Currently, the development tools on CKB are relatively complete. After a few days of learning, a skilled developer can get started.
Q2: What is the relationship between RGB++ and CKB tokens?
Cipher: For every RGB++ transaction, a corresponding Bitcoin transaction and CKB transaction will be sent out simultaneously. Each user in the RGB++ ecosystem will have a corresponding UTXO (Cell) on the CKB chain for their transactions, assets, or states, which will occupy and use a portion of CKB. In addition, developers will also develop contracts on the CKB chain.
Q3: Will CKB compress RGB transactions?
Cipher: The RGB++ Protocol Light Paper mentions transaction folding, which can combine multiple CKB transactions with one Bitcoin RGB++ transaction, allowing the low-speed and low-throughput Bitcoin chain to be scaled using the high-performance CKB chain.
Another aspect is state compression, which has already been implemented in the CoTA protocol. Regardless of the amount of tokens held, they can be compressed into a 32-byte space. Whether RGB++ can achieve similar state compression has not been studied extensively, but it is a good direction.
Q4: Are there tools like Subgraph and Oracle for CKB development, or do we need to wait for third-party support?
CyberOrange: Currently, there are no oracles on the CKB chain. Some other interfaces can be decoded using the CKB data encoding and decoding standards, but some manual work may be required.
Q5: What is the TPS of CKB?
CyberOrange: If it's a simple transfer, the TPS of CKB can reach over 300.
Q6: In the article about the security of RGB++](https://talk.nervos.org/t/rgb-1/7798), it is mentioned that almost no reverts occur after 6 confirmations on Bitcoin, while CKB requires about 20-something blocks. Will this affect the user experience of RGB++? Users may not want to wait that long.
Cipher: If you only send a single-layer transaction, it will synchronize a CKB transaction along with a Bitcoin RGB++ transaction. This mainly depends on the speed of Bitcoin block generation and does not require waiting for so many block confirmations. It is similar to the transfer experience on Bitcoin. The 6-block confirmation you mentioned is for assets jumping from Bitcoin Layer1 to CKB. To ensure security, it requires 6 Bitcoin block confirmations before the assets can be unlocked and operated on CKB. This is controlled by smart contracts and does not require multisig or third parties. Subsequent operations on CKB only require waiting for the 10-second block generation time on CKB. If you want to jump back to the Bitcoin chain, for security reasons, you need to wait for about 20-something CKB block confirmations. Jump operations are not frequent, so they do not have a significant impact on the user experience. Moreover, other cross-chain solutions often require waiting for a long time as well.
Q7: Will the DEX planned to be released by the end of March support assets like Bitcoin Script?
Cipher: Yes.