RGB++: A New Approach to Bitcoin L2 Assets

This article is reprinted from Foresight News, authored by Trustless Labs.
Original link: https://foresightnews.pro/article/detail/54503

The popularity of Bitcoin Layer 2 continues unabated. Among numerous L2 projects, CKB stands out for two reasons: on one hand, the team originates from the well-known public chain Nervos CKB, which has been deeply engaged in the PoW mechanism; on the other hand, after announcing its repositioning as a BTC Layer 2 network, the team proposed an innovative solution RGB++, using Cells on the CKB chain to "isomorphically bind" the UTXO of the Bitcoin original chain. The market's reaction to CKB has also been very enthusiastic.

On February 22, Trustless Labs invited RGB++ author and CKB co-founder Cipher, along with ecosystem leader Baiyu, to share their understanding of Bitcoin L2, the mechanism of RGB++, the assets of RGB++, and the construction ideas for the CKB ecosystem.

Below is a textual summary of the Twitter space content:

1. Nervos CKB is a long-standing PoW public chain. Why has it insisted on PoW without transitioning to a PoS chain? How did the idea of transitioning to BTCKB come about?#

Nervos CKB's decision to stick with PoW rather than transition to a PoS chain is rooted in our profound understanding of technology and the market. We believe that the decentralization and security brought by the PoW (Proof of Work) mechanism are irreplaceable. Additionally, our technical choices—including the UTXO model and the adoption of the RISC-V architecture—although contrary to the mainstream trends at the time, were based on considerations of long-term sustainability and technical advantages.

From the project's inception in 2018 to its launch in 2019, we experienced multiple fluctuations in the cryptocurrency market, but we never changed our direction. At that time, smart contracts and PoS mechanisms were considered the future, while PoW was seen as outdated technology. Nevertheless, our adherence to PoW is not merely a preference for technology; it is also because we believe that the UTXO model and PoW mechanism can provide unique security and decentralization features that are difficult to replace with other technological solutions.

The idea of transitioning to BTCKB actually stems from our deep insights into market narratives. In recent years, although our narrative seemed suppressed by the PoS and account model narratives, since last year, with Bitcoin's expansion on Layer 1 and the emergence of new applications for the UTXO model, we saw an opportunity. These changes not only expanded the use of Bitcoin but also enhanced users' understanding and acceptance of UTXO and PoW. Furthermore, with the reevaluation of the environmental impact of PoW and the increasing recognition of off-chain computation and on-chain verification models, we believe now is the best time to launch new protocols based on the PoW UTXO model, such as RGB++.

I believe that with the renaissance of Bitcoin and the market's renewed recognition of the value of PoW and the UTXO model, Nervos CKB will be at the forefront of cryptocurrency development. Our insistence on PoW is not without reason; it is based on a true understanding of the value of technology and a profound insight into future trends.

2. What is the Nervos CKB team's understanding of BTC's scalability and BTC L2, and why did they choose the RGB protocol?#

Regarding the Nervos CKB team's understanding of BTC's scalability and BTC L2, as well as why we chose the RGB protocol, my perspective is based on our team's characteristics and past technical accumulation. We have deeply discussed whether we should pursue TVL or choose an EVM-compatible Layer 2 path. After careful consideration, we believe that sticking to a technical route, even if it means taking a path different from the mainstream, is our advantage. Our technical choices and strategies, particularly the choice of the RGB protocol, are based on our understanding of the Bitcoin community's conservative attitude and our pursuit of technological innovation.

We are well aware that directly competing with Bitcoin and Ethereum is a difficult road. In the past, we attempted to position CKB as a Layer 1 public chain similar to Bitcoin and Ethereum, aiming to become a value storage platform. However, this positioning put us in an awkward position—neither fully aligning with the conservative standards of the Bitcoin community nor conflicting with the development direction of Ethereum. This unique positioning made us feel out of place in both major communities.

Faced with such challenges, we decided to embrace our characteristics and adhere to our original technical vision. This includes in-depth exploration and innovation of the UTXO model, as well as research on Bitcoin Layer 2 solutions. We believe that by focusing on our technical advantages and innovations, we can find a path that aligns with the spirit of Bitcoin while bringing value to the community.

During the transition process, we realized that the market's acceptance of the UTXO model was gradually increasing, providing a favorable opportunity for our transition. We decided to clearly express CKB's positioning as a Layer 2 solution for Bitcoin, which not only aligns with our technical philosophy but also provides new growth opportunities for the Bitcoin ecosystem. Overall, our decision is based on a profound understanding of the essence of technology and a keen insight into market trends. We believe that by focusing on our core advantages and adhering to technological innovation, we can find our unique position in the world of cryptocurrency.

3. In terms of technical choices, BTCKB chose the RGB protocol and proposed the RGB++ protocol. Can you briefly explain this solution (DA at which layer, client verification, whether there is open-source indexing, what VM)?#

Baiyu: I will first introduce the broader context and decision-making process at that time. We believe that the key to Bitcoin's Layer 2 competition lies in Layer 1, and the core of Layer 1 competition is new protocols. We categorize new protocols into two types: one that utilizes UTXO characteristics for assets, and another that does not. Based on this, we chose protocols with UTXO characteristics, such as atomical, RGB, and taproot assets.

Specifically, we decided to choose the RGB protocol because Cipher has a strong interest in RGB and has conducted in-depth research with Professor A Jian. We proposed a method of isomorphic binding to launch RGB++. In the future, CKB's core direction will be to advance technologies related to RGB++, but it is important to clarify that RGB++ and RGB are two different concepts. RGB is primarily developed by the LNP/BP Association, Dr. Maxim, and was initially proposed by Peter, who expanded it using the concept of one-time seals. RGB++, on the other hand, introduces the possibility for other UTXO chains to act as RGB++ clients, with its core contribution being the concept of isomorphic binding. From CKB's perspective, we plan to be compatible with more protocols in the future.

Cipher: When discussing technical choices, I will first explain what the RGB protocol is. RGB is essentially a protocol that utilizes Bitcoin's one-time seals and client verification technology to bind RGB transaction states off-chain through Bitcoin's UTXO model, thus creating an asset protocol on Bitcoin Layer 1. This design allows for the verification of a transaction by only focusing on the transaction paths related to that UTXO, rather than checking all transactions to confirm balances or states like other models.

Regarding data availability (DA), we often discuss its storage location in Layer 1 or Layer 2 within the Ethereum ecosystem and its impact on security. However, in the Bitcoin ecosystem, this concept differs from Ethereum, especially for protocols like RGB that utilize UTXO characteristics. In the RGB protocol, only the data related to the user needs to be verified, and this data theoretically does not need to be stored in a specific DA layer, as the transaction parties can directly exchange the necessary information.

The RGB++ protocol is an extension of RGB. RGB itself requires the exchange of transaction history and data through a P2P network, which includes using a new virtual machine and defining interaction logic, making off-chain logic complex and development slow. RGB++ aims to move all "smart" components of the RGB protocol, such as P2P networks, virtual machines, and smart contracts, on-chain, specifically placing these functions on CKB. The state transitions of each UTXO on CKB are constrained by CKB smart contracts, allowing for the verification and execution of RGB++ contract assets and logic on CKB, while addressing issues such as interaction, smart contract execution, and proof provision. CKB uses the RISC-V virtual machine, supporting Turing-complete smart contracts, enabling users to view or verify asset states directly on CKB without sacrificing security, or verify on the client side when needed.

Technical Implementation: Through the RGB++ protocol, we first ensure compatibility with all operations of RGB. We addressed the slow progress of off-chain clients by using a UTXO supply chain strategy based on proof of work (PoW) instead. Additionally, we implemented a mechanism that allows for the seamless migration of transactions from Bitcoin to CKB for execution, utilizing 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 that it allows transactions to jump to Layer 2, for example, from the Bitcoin chain to the CKB chain. This means that transactions can be executed multiple times (e.g., 100 times, 1000 times) on CKB, enjoying the benefits of low cost and high performance, before jumping back to the Bitcoin chain. This method significantly improves transaction efficiency and performance while circumventing the performance limitations of Bitcoin itself.

Security Considerations: In the process of implementing the jump, we pay special attention to security issues. This process does not rely on any trusted cross-chain bridges or multi-signature mechanisms but is based on direct binding between two UTXOs. We adhere to the security standards of proof of work (PoW), believing that transactions on the Bitcoin chain cannot be reversed after 6 blocks, while on CKB, we require approximately 24 blocks to achieve the same security guarantee through equivalent computational formulas. This method ensures the security of assets jumping or migrating between the two layers.

Innovation and Optimization: Our approach differs from Ethereum's Layer 2 logic or other cross-chain bridge Layer 2 logic, representing our innovation and optimization in blockchain technology. Through the RGB++ protocol, we not only address performance and cost issues but also enhance the overall security and reliability of the system.

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

4. The development of smart contracts for the RGB protocol is relatively difficult, which is one of the main reasons for the slow progress of RGB. Will RGB++ also adopt the same smart contracts as RGB? What technical 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 fully comply with the original RGB protocol, mainly because the RGB protocol itself is still evolving and not fully mature. In the second step, we will utilize isomorphic binding technology to ensure that each RGB or RGB++ transaction can be bound to CKB's UTXO (which we refer to as cells). This means that the smart contracts and states at the RGB++ protocol layer will be equivalent to the smart contracts and states on CKB. Our toolchain and support are based on the accumulation of the past five years at CKB, although development is relatively complex.

Secondly, compared to Ethereum's account model and CKB's UTXO model, there are intuitive differences and implementation difficulties in smart contract development. Ethereum's account model is more intuitive for programmers, allowing simple function calls to yield results. However, implementing UTXO-based business logic (such as RGB or RGB++) under the account model is extremely challenging due to the uncertainty of transaction results, which affects the feasibility of isomorphic binding.

Although programming under the UTXO model is more difficult, we believe it is the only solution for extending Bitcoin protocol logic. The development tools and product knowledge we have accumulated over the past four to five years, including toolchains for writing smart contracts in Rust, C, Lua, and JavaScript, provide rich support for developers. We attempted to implement an AMM similar to Uniswap under the UTXO model but faced significant challenges, ultimately leading to project failure, highlighting 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 by the end of March, based on CKB. The user experience design aims to simplify the process, allowing users to easily transfer assets without cumbersome inscription steps. The entire process automates isomorphic transactions, making it transparent for users and aiming to provide a seamless cross-chain interaction experience.

In terms of technical choices, we first ensure compatibility with the RGB protocol while introducing a mechanism that allows transactions to seamlessly migrate from the Bitcoin chain to CKB for execution, enjoying higher execution efficiency, and then migrating back to the Bitcoin chain. We refer to this process as "jump," which allows assets to securely jump between the two chains without relying on any trusted cross-chain bridges or multi-signature mechanisms, solely depending on the binding between UTXOs. This design is based on the trust differences in block confirmation times between Bitcoin and CKB, ensuring the security of asset migration through appropriately long block confirmations.

To address the challenges of smart contract development for the RGB protocol, we provide richer exchange experiences and development support on CKB. We will launch a Layer 2 DEX solution to optimize user experience, allowing users to not worry about whether assets are on Layer 1 or Layer 2. This DEX allows users' assets to be listed from the Bitcoin chain to the DEX, during which the ownership of the assets transfers from Bitcoin's UTXO to CKB addresses, ensuring the security and transparency of the transfer. The smart contract code we use is open-source, reducing users' concerns about security. Additionally, we ensure double-spending protection during the asset jump process and a smooth trading experience on Layer 2, allowing users not to worry about the specific location of their assets, thus providing an almost seamless trading experience.

5. Since a transaction occurs on Bitcoin, a corresponding transaction will also happen on CKB. How is gas calculated when users use both chains, especially in asset transfers between them?#

First, when transactions occur on both Bitcoin and CKB, indeed, a transaction is executed on each chain. CKB transactions require not only network usage fees (gas fees) but also state fees for storing transaction states (such as the amount of CKB held). This state fee typically requires over 100 CKB, raising the question of who will bear these costs and how to ensure that user experience is not affected.

The solution is that when executing a Bitcoin transaction, an additional output can be added to the Bitcoin transaction, which is a small amount of Bitcoin (costing about a few dollars) pointing to a payer known as a paymaster. This paymaster uses these Bitcoins to construct and initiate a corresponding transaction on CKB, replacing the user in paying the fees on the CKB chain.

A key point in this process is that CKB utilizes a feature that allows proving that the transaction indeed occurred on CKB through the content of the Bitcoin transaction, without requiring the user to sign again on the CKB chain. This means that anyone (such as a relayer or paymaster) can initiate a transaction on the CKB chain on behalf of the user and pay the related fees.

Ultimately, through this mechanism, users do not need to directly worry about gas fee calculations and payments when transferring assets between the two chains, as these are indirectly handled through the additional output added to the Bitcoin transaction, paid by the paymaster, thus providing a seamless and user-friendly experience.

6. The market for BTC L2 has already shown explosive trends, with projects like BounceBit, Merlin Chain, and B² having significant TVL. How will RGB++ consider entering the market? Will there be a native asset issuance protocol on RGB++?#

In response to the explosive trend of Bitcoin Layer 2 (L2) solutions in the market and how RGB++ will enter this market, I will elaborate on two main aspects: first, the functions and features of RGB++ as an issuance protocol, and second, our strategies and plans on the CKB Layer 2 chain.

First, 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 trading on the Bitcoin mainnet, but potentially facing higher gas fees and slower transaction speeds. However, when it comes to trading these assets, they can be directly utilized on CKB's DEX, where RGB++ and assets on CKB follow the same standards, such as our FT standard xUDT, similar to ERC20. We also have an NFT standard, Spore NFT, which has already been applied on the mainnet.

Secondly, regarding strategies on the CKB Layer 2 chain, we focus on providing a smooth user experience, including native asset issuance and cross-chain asset support. Bitcoin and Ethereum assets can be transferred to CKB through bridging technology, and we are collaborating with large institutions to ensure the security and reliability of this process. Additionally, we emphasize the importance of the smart contract platform; once RGB++ assets are issued, they can immediately utilize this platform for various decentralized application (dApp) developments, such as definitions, staking, and mining activities.

On the CKB Layer 2, there are three types of assets: FT, NFT, and CKB native inscription assets. Each type of asset has its specific application and trading mechanisms, and we provide corresponding technical and market solutions to support them. For example, we support the circulation of NFT 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.

In summary, RGB++'s market entry strategy includes leveraging its capabilities as a powerful NFT and FT issuance protocol, as well as launching innovative and native assets on the CKB Layer 2 chain. We are committed to providing a comprehensive smart contract platform that supports cross-chain asset transfers and ensures the security and practicality of technology through collaboration with industry partners.

Assets on Bitcoin can be roughly divided into two major categories and three minor categories. First, Bitcoin itself is a distinct asset. Second, all assets requiring off-chain verification, or so-called "colored assets," constitute the second major category. Within this second category, I further subdivide it into two types: one type utilizes UTXO characteristics and can be reused on the Lightning Network; these assets can be migrated to CKB using a scheme similar to RGB through isomorphic mapping and binding. This means that assets like atomical and taproot assets, although still issued on the Bitcoin chain, can be used on CKB through the RGB++ scheme without requiring significant modifications to the protocol assets at this layer.

The second type of assets, such as BRC20, which utilize UTXO characteristics less, are difficult to migrate to CKB through isomorphic binding. Our approach to these assets is similar to that of other chains in the market, which is to create cross-chain bridges. This bridge will lock BRC20 assets on the Bitcoin chain and then issue an equivalent FT (Fungible Token) or NFT (Non-Fungible Token) on CKB, allowing users to trade on CKB. This method applies to protocol assets that cannot directly utilize UTXO characteristics, such as BRC20 assets like ORDI. In summary, RGB++ aims to provide a flexible isomorphic binding mechanism to accommodate and optimize the use and migration of different types of assets between Bitcoin and CKB.

8. What support will RGB++ provide for existing assets with a considerable user base and community?#

We are planning to support existing assets with a broad user base through two main avenues:

1. Inscription Bridge Support: We intend to implement support for BRC20 or other assets through an inscription bridge, as long as there are suitable indexers and operators for the bridge. We are looking for partners to build these inscription cross-chain bridges. We expect to quickly resolve issues with the BTC bridge, while we are actively working on the inscription bridge. This requires support from wallets in the ecosystem, including plugin wallets, which are currently lacking in the CKB ecosystem. We look forward to more hardware wallets and plugin wallets supporting major protocols in the future, thereby supporting the development of the entire ecosystem.

2. Non-inscription Bridge Approaches: Our initial focus is on the implementation of RGB++. After completing RGB++, we may consider supporting other UTXO protocols to see which method is faster and more effective. Our goal is to implement RGB++ first. Additionally, we are considering collaborating with the Lightning Network team, although they primarily focus on payments and limited scripting capabilities. We believe that bringing these functionalities to CKB and empowering it at the smart contract level is the most appropriate approach.

Overall, our strategy is flexible and aggressive, aiming to gradually advance support for a wide range of user and community assets through various technical avenues and partnerships. We are confident that these efforts are feasible and that the ultimate implementation authority lies with us.