RGB++: New ideas for Bitcoin L2 assets

Author: Trustless Labs Source: X, @TrustlessLabs

The popularity of the Bitcoin Layer 2 track continues unabated. Among many L2 projects, CKB is unique. On the one hand, the team is originated from the well-known public chain Nervos and has been deeply involved in the POW mechanism; on the other hand, after announcing After adjusting its positioning to the BTC second-layer network, the team proposed a groundbreaking solution, RGB++, using Ce on the CKB chain to "isomorphic binding" the UTXO of the original Bitcoin chain. The market response to CKB has also been very enthusiastic.

On February 22, Trustless Labs invited RGB++ author and CKB co-creator Cipher and ecological leader Baiyu to share their understanding of Bitcoin L2, RGB++ Mechanism, RGB++ assets and CKB ecological construction ideas. The following is a text summary of twitter space content.

1. Nervos is a POW public chain that has been around for a long time. Why has it always insisted on POW and not transformed into a POS chain? How did the idea of ​​transforming BTCKB come about?

Nervos chose to stick to POW rather than transform into a POS chain. This decision is rooted in our deep understanding of technology and the market. We believe that the decentralization and security brought by the POW (Proof of Work) mechanism are irreplaceable. Furthermore, our technology choices—including the UTXO model and adoption of the RISC-V architecture—while running counter to prevailing trends at the time, were based on considerations of long-term sustainability and technical advantage.

From the beginning of the project in 2018 to its launch in 2019, we have experienced many fluctuations in the cryptocurrency market, but we have never changed our direction. At that time, smart contracts and POS mechanisms were considered the direction of the future, while POW was viewed as an outdated technology. Nonetheless, our insistence on POW is not only due to technical preference, but also because we believe that the UTXO model and POW mechanism can provide unique security and decentralization features that are difficult to replace by other technical solutions.

About the idea of ​​transforming BTCKB, this actually comes from our deep insight into the market narrative. Although our narrative seemed to be suppressed by the narrative of POS and account models over the past few years, starting last year, with the expansion of Bitcoin on Layer 1 and the emergence of emerging applications for the UTXO model, we saw an opportunity. These changes not only expand the scope of Bitcoin use, but also enhance users' understanding and acceptance of UTXO and POW. In addition, as the environmental impact of POW is re-evaluated and the model of off-chain computing and on-chain verification is increasingly recognized, we believe that now is the best time to launch new protocols based on the POW UTXO model, such as RGP+.

I believe that with the renaissance of Bitcoin and the market's renewed understanding of the value of the POW and UTXO models, Nervos and BTCKB will be at the forefront of cryptocurrency development. Our insistence on POW is not without reason, but based on our understanding of the true value of technology and our deep insight into future trends.

2. What is the Nervos team’s understanding of BTC expansion and BTC L2, and why did they choose the RGB protocol?

As for the Nervos team’s understanding of BTC expansion and BTC L2, and why they chose the RGB protocol, my opinion is based on the characteristics of our team and Past technology accumulation. We had an in-depth discussion about whether we should pursue TVL, or choose the EVM-compliant Layer 2 path. After careful consideration, we decided that it would be to our advantage to stick to the technical side, even if it meant taking a different path than the mainstream. Our technology choices and strategies, especially the choice of the RGB protocol, are based on our understanding of the conservative attitude of the Bitcoin community and our pursuit of technological innovation.

We know that directly competing with Bitcoin and Ethereum is a difficult road. In the past, we tried to position CKB as a Layer 1 public chain similar to Bitcoin and Ethereum, aiming to become a value storage platform. But this positioning puts us in an awkward position - it is not completely in line with the conservative standards of the Bitcoin community, but also conflicts with the development direction of Ethereum. This unique positioning makes us feel out of place in both communities.

Faced with such challenges, we decided to embrace our identity and adhere to the original technical vision. This includes in-depth exploration and innovation of the UTXO model, as well as research into Bitcoin’s second-layer solutions. We believe that by focusing on our technical strengths and innovation, we can find a path that is both consistent with the spirit of Bitcoin and brings value to the community.

During the transformation process, we realized that the market's acceptance of the UTXO model is gradually increasing, which provides a favorable opportunity for our transformation. We decided to clearly express CKB’s positioning as a second-layer solution for Bitcoin, which not only aligns with our technical philosophy but also provides new growth opportunities for the Bitcoin ecosystem. Overall, our decisions are based on a deep understanding of the nature of technology and a keen insight into market trends. We believe that by focusing on our core strengths and adhering to technological innovation, we can find our unique position in the world of cryptocurrency.

3. In terms of technology selection, BTCKB chose the RGB protocol and proposed the RGB++ protocol. Let me briefly explain this solution to you (where is the DA? layer, client validation, is there an open source index, what VM)?

Baiyu: I will first introduce our background and decision-making process at that time. We believe that the key to Bitcoin’s second-level competition lies in the first level, while the core of the first-level competition lies in new protocols. We divide the new protocols into two categories: those that use the UTXO feature and those that do not. On this basis, we chose protocols with UTXO characteristics, such as atomic, RGB and taproot assets.

Specifically, we decided to choose the RGB protocol because Cipher personally has a strong interest in RGB and conducted in-depth research with Teacher Ajian. We propose an isomorphic binding approach to derive RGB++. In the future, CKB's core direction will be to promote RGB++-related technologies, but it needs to be clear that RGB++ and RGB are two different concepts. RGB was primarily proposed by the Impbp Association, Dr. Maxim, and originally by Peter who extended it using the concept of disposable sealing strips. RGB++ introduces more about the possibility that other UTXO chains can serve as RGB++ clients. Its core contribution lies in the concept of isomorphic binding. From CKB's standpoint, we plan to be compatible with more protocols in the future.

Cipher: When discussing technology selection, let me first explain what the RGB protocol is. RGB is actually a one-time seal and client verification technology that uses Bitcoin to bind RGB transaction status outside the chain through Bitcoin's UTXO model, thus realizing an asset protocol on Bitcoin Layer 1. This design allows when validating a transaction to only focus on the transaction path related to the UTXO, without the need to check all transactions to confirm balance or status like other models.

For data availability (DA), we often discuss its storage location in Layer 1 or Layer 2 in the Ethereum ecosystem and its impact on security. But in the Bitcoin ecosystem, this concept is different from Ethereum, especially for protocols like RGB that leverage the characteristics of UTXO. In the RGB protocol, only user-related data needs to be verified, and these data theoretically do not need to be stored in a specific DA layer, because both parties to the transaction can directly exchange the necessary information.

RGB++ protocol is an extension of RGB. RGB itself needs to exchange transaction history and data through the P2P network, which includes using new virtual machines and defining interaction logic, etc., making off-chain logic complex and slow to develop. RGB++ aims to move all "smart" components in the RGB protocol, such as P2P networks, virtual machines, smart contracts, etc., to the chain through isomorphic binding or mapping. Specifically, it puts these functions into CKB (Nervos Network) superior. The state transfer of each UTXO on CKB is constrained by the CKB smart contract, so that RGB++ contract assets and logic can be verified and run on CKB, while solving issues such as interaction, smart contract operation, and proof provision. CKB uses a RISC-V virtual machine and supports Turing-complete smart contracts, allowing users to directly view or verify asset status on CKB without sacrificing security, or when necessary, on the client authenticating.

Technical implementation:Through the RGB++ protocol, we first ensure compatibility with all RGB operations. We solved the problem of slow progress for off-chain clients by using a UTXO supply chain strategy based on Proof of Work (PoW) instead. In addition, we have implemented a mechanism that can seamlessly migrate transactions on Bitcoin to CKB (Nervos Network) for execution, making use of the high-performance execution environment provided by CKB, and then migrating the execution results back to the Bitcoin chain.

Performance Optimization:An important feature of the RGB++ protocol is to allow transactions to "jump" to the second layer (Layer 2), such as from Bit The currency chain jumps to the CKB chain. This means that transactions can be executed multiple times on CKB (such as 100 times, 1000 times), enjoying the benefits of low cost and high performance, and then "downloaded" back to the Bitcoin chain. This approach significantly improves the efficiency and performance of transactions while bypassing the performance limitations of Bitcoin itself.

Safety considerations:During the transition process, we paid special attention to security issues. This process does not rely on any trusted cross-chain bridge or multi-signature mechanism, but is based on the direct binding between two UTXOs. Based on the security standard of Proof of Work (PoW), we believe that transactions on the Bitcoin chain cannot be reversed after 6 blocks. On CKB, we use the equivalent calculation formula and it takes about 24 blocks. to achieve the same security guarantee. This approach ensures the safety of assets jumping or migrating between the two levels.

Innovation and optimization: Our approach is different from the Layer 2 logic of Ethereum or the Layer 2 logic of other cross-chain bridges , represents our innovation and optimization in blockchain technology. Through the RGB++ protocol, we not only solve the performance and cost issues, but also improve the security and reliability of the entire system.

In short, by introducing the RGB++ protocol, we have achieved significant performance improvements and strict security guarantees while maintaining compatibility with the original RGB protocol. . These optimizations and innovations demonstrate our in-depth understanding of the development of blockchain technology and exploration of future directions

4. Smart contract development of RGB protocol It is more difficult, which is one of the main reasons for the slow progress of RGB. Will RGB++ also use the same smart contract as RGB? What technology stack and support are available for developers?

First, regarding the compatibility of RGB++ with the original RGB protocol, our development process will be divided into two steps. In the first step, we will not be fully compatible with the original RGB protocol, mainly because the RGB protocol itself is still changing and is not fully perfected. In the second step, we use isomorphic binding technology to enable each RGB or RGB++ transaction to be bound to CKB’s UTXO (we call it a cell). This means that the smart contracts and states of the RGB++ protocol layer will be equivalent to those on CKB. Our toolchain and support are based on CKB’s accumulation over the past five years, although development is relatively complex.

Secondly, compare Ethereum’s account model and CKB’s UTXO model to see the intuitive differences and implementation difficulty in smart contract development. Ethereum's account model is more in line with programmers' intuition, and the result can be obtained by simply calling a function. However, it is extremely difficult to implement UTXO-based business logic (such as RGB or RGB++) under the account model because the transaction results under the account model are uncertain, which affects the feasibility of isomorphic binding.

Although programming under the UTXO model is difficult, we believe this is the only way to extend the logic of the Bitcoin protocol. The development tools and product knowledge we have accumulated over the past four or five years, including tool chains and basic designs for writing smart contracts using Rust, C, Lua and JavaScript, provide developers with rich support. We tried to implement an AMM similar to Uniswap under the UTXO model, but encountered major challenges and ultimately the project failed, which illustrates the difficulty of innovation under the UTXO architecture.

Regarding user experience, we plan to launch RGB++’s fungible and non-fungible tokens and corresponding Dex at the end of March, which will be based on CKB. The user experience is designed to be streamlined, allowing users to easily transfer assets without tedious engraving steps. The entire process handles isomorphic transactions automatically and is transparent to users, aiming to provide a seamless cross-chain interaction experience.

In terms of technology selection, we first ensured compatibility with the RGB protocol, and at the same time introduced a mechanism to allow transactions to be seamlessly migrated from the Bitcoin chain to Execute on CKB to enjoy higher speed execution efficiency, and then migrate back to the Bitcoin chain. We call this process "iump", which allows assets to safely jump between two chains without relying on any trusted cross-chain bridge or multi-signature mechanism, relying only on the binding between UTXOs. This design is based on the trust difference in the block confirmation time of Bitcoin and CKB, ensuring the security of asset migration through block confirmation of appropriate length.

We respond to the challenges of RGB protocol smart contract development by providing richer exchange experience and development support on CKB. We will launch a Layer 2 Dex solution to optimize the user experience so that they do not need to care whether the assets are in Layer 1 or Layer 2. This Dex allows users to list their assets from the Bitcoin chain to the Dex. During the process, the ownership of the assets is transferred from the Bitcoin UTXO to the CKB address, ensuring the security and transparency of the transfer. The smart contract code we use is open source, which reduces users' concerns about security. In addition, we ensured double-spend protection during asset jumps (jumps), as well as a smooth trading experience on Layer 2, so that users do not need to worry about the specific location of assets, thus providing an almost seamless trading experience.

5. Since after transferring money on Bitcoin, a synchronized and similar transaction will occur on CKB, then the user is using two When chaining, including in the case of transferring assets to each other, how is gas calculated?

First of all, when a transaction is made on Bitcoin and CKB, a transaction is indeed performed on each of the two chains. CKB transactions not only require network usage fees (gas fees), but also require status fees, which are used to store transaction status (such as the amount of CKB held). This status fee typically costs more than 100 CKB, which begs the question of who will bear these costs and how to ensure that the user experience is not affected.

The solution is that when executing a Bitcoin transaction, you can add an additional output to the Bitcoin transaction that is a fraction of the Bitcoin (cost Probably a few dollars), directed to a payer called the paymaster. This payer uses these Bitcoins to construct and initiate a corresponding transaction on CKB, paying the fees on the CKB chain on behalf of the user.

A key point in this process is that CKB takes advantage of a feature that allows the Bitcoin transaction content to be used to prove on CKB that the transaction did occur without The user is required to sign again on the CKB chain. This means that anyone (such as relayer or paymaster) can initiate transactions on the CKB chain on behalf of users and pay related fees.

Ultimately, through this mechanism, users do not need to directly worry about the calculation and payment of gas fees when transferring assets between the two chains, because these All are processed indirectly through the additional output added to the Bitcoin transaction, paid by the paymaster, thus providing a seamless and user-friendly experience.

6. BTC L2 on the market has shown an explosive trend, such as BounceBit, Merlin Chain, and B^2 all have very objective TVL; RGB++ Will you consider how to enter the market? Will there be a native asset distribution protocol on RGB++?

In response to the explosive trend of Bitcoin second layer (L2) solutions in the market and how RGB++ can enter this market, I will elaborate on it from two main aspects: one is about the functions and features of RGB++ as a distribution protocol, and the other is about our strategies and plans on the CKB second-layer chain.

First of all, the core function of RGB++ is to serve as an issuance protocol for NFTs and FTs (non-fungible tokens and fungible tokens). This means that RGB++ can support the issuance of NFTs and FTs with an experience similar to transactions on the Bitcoin mainnet, but may face higher gas fees and slower transaction speeds. However, when it comes to trading these assets, you can directly utilize CKB's Dex. In this regard, the assets on RGB++ and CKB follow the same standard, such as our FT standard XUDT, which is similar to ERC20. We also have standards for NFTs, sport NFTs, which are already in use on the mainnet.

Secondly, regarding the strategy on the CKB second-tier chain, we focus on providing a smooth user experience, including the issuance of native assets and the support of cross-chain assets. . Bitcoin and Ethereum assets can be transferred to CKB via bridging technology, and we are working with large institutions to ensure the security and reliability of this process. In addition, we emphasize the importance of the smart contract platform. Once the assets of RGB++ are issued, this platform can be immediately used for various decentralized application (DApp) development, such as definition, staking and mining activities.

Three types of assets on the second layer of CKB: FT, NFT and CKB native inscription assets. Each type of asset has its specific applications and trading mechanisms, and we provide corresponding technical and market solutions to support them. For example, we support the circulation of NF assets through unified standards and trading markets, and we are developing specific platforms, such as the Omega trading market, to support the issuance and trading of CKB native inscription assets.

To sum up, RGB++’s market entry strategy includes not only leveraging its ability as a powerful NFT and FT issuance protocol, but also including using CKB 2 Plans to launch innovative and native assets on the layer chain. We are committed to providing a complete smart contract platform that supports cross-chain transfer of assets and ensures the security and practicality of the technology by working with industry partners.

7. What is the difference between RGB++ assets and RGB20 and RGB721? Is it compatible with BRC20 and ARC20 assets with relatively high market shares on the original Bitcoin chain?

The assets on Bitcoin can be roughly divided into two major categories and three smaller categories. First, Bitcoin itself is an independent asset class. Secondly, all assets that require off-chain verification, or so-called “dyed assets”, form the second largest category. In this second category, I further subdivided it into two categories: one is assets that can take advantage of UTXO characteristics and can be reused on the Lightning Network. This type of assets uses a scheme similar to RGB, through isomorphic mapping and binding. It is determined and can be migrated to CKB for use. This means that, although assets such as atomic and taproot assets are still issued on the Bitcoin chain, they can be used on CKB through the RGB++ solution without requiring too many modifications to the protocol assets at this layer.

The second type of assets, such as BRC20, use fewer UTXO features and are difficult to migrate to CKB through isomorphic binding. For this type of assets, our approach is similar to other chains on the market, that is, by creating cross-chain bridges. This bridge will lock BRC20 assets on the Bitcoin chain, and then map and issue an equivalent FT (Fungible Token) or NFT (Non-Fungible Token) on CKB, allowing users to trade on CKB. This method is suitable for protocol assets that cannot directly utilize UTXO characteristics, such as BRC20 assets such as ordi. In short, RGB++ aims to be compatible with and optimize the use and migration of different types of assets between Bitcoin and CKB by providing a flexible isomorphic binding mechanism.

8. What kind of support will RGB++ provide in the future for some of this kind of assets that already exist and have a relatively large number of users and communities?

We are planning to support existing assets with a broad user base, mainly considering two approaches:

1. Inscription Bridge support: We intend to implement support for BRC 20 or other assets through the Inscription Bridge, as long as there is a suitable indexer and bridge operator. We are looking for partners to build these inscription cross-chain bridges. We will be able to solve the problem of the BTC bridge soon, and we are working on it for the Inscription Bridge. This requires support from wallets in the ecosystem, including plug-in wallets, which is currently lacking in the CKB ecosystem. We look forward to having more support for hardware wallets and plug-in wallets in the future. These wallets will be compatible with major protocols to support the development of the entire ecosystem.

2. Non-Inscription Bridge approach:Our first focus is on the implementation of RGB++. After finishing RGB++, we might consider supporting UTXO protocols like the room protocol to see which method is faster and more efficient. Our goal is to implement RGB++ first. In addition, we are also considering working with the Lightning Network team. Although they are mainly focused on payments and limited scripting functions, we believe that bringing these functions to CKB and empowering them at the smart contract level is the most suitable way.

Overall, our strategy is flexible and aggressive, aiming to advance incrementally through a variety of technology avenues and partnerships to support a broad range of users and Community assets. We are confident that these efforts are feasible and that the final implementation is within our own hands.