Author: Trustless Labs

The heat of the Bitcoin Layer 2 track shows no sign of abating. Among the numerous L2 projects, CKB stands out. On one hand, this is due to the team's background in the well-known public chain Nervos, which has been deeply rooted in the POW mechanism. On the other hand, after announcing the positioning adjustment to become a BTC Layer 2 network, the team proposed a groundbreaking solution, RGB++, which uses Cells on the CKB chain to "isomorphically bind" the UTXO of the original Bitcoin chain. The market's response to CKB has also been very enthusiastic.

On February 22, Trustless Labs invited the author of RGB++, CKB co-founder Cipher, and ecosystem leader Baiyu to share their understanding of Bitcoin L2, the mechanism of RGB++, and the asset and CKB ecosystem development strategy. The following is a summary of the content from the Twitter space.

1. Nervos is a long-standing POW public chain. Why has it persisted in not transitioning to a POS chain? How did the idea of transitioning to BTCKB come about?

Nervos chose to persist in POW rather than transition to a POS chain based on a deep understanding of technology and the market. They believe that the decentralization and security brought by the POW mechanism are irreplaceable. Additionally, their technical choices, including the UTXO model and the adoption of the RISC-V architecture, were based on considerations of long-term sustainability and technical advantages.

From the start of the project in 2018 to the launch in 2019, they experienced multiple fluctuations in the cryptocurrency market but never changed their direction. Despite the prevailing narrative at the time favoring smart contracts and POS mechanisms as the future direction, Nervos' persistence in POW was not only due to a preference for the technology but also because they believed that the UTXO model and POW mechanism could provide unique security and decentralization, which other technical solutions could not replace.

As for the idea of transitioning to BTCKB, it actually stems from their deep insight into the market narrative. Despite their narrative seemingly being suppressed by the narratives of POS and account models in recent years, they saw an opportunity with the expansion of Bitcoin on Layer 1 and the emergence of new applications for the UTXO model. These changes not only expanded the use of Bitcoin but also enhanced users' understanding and acceptance of UTXO and POW. Additionally, with the increasing recognition of the environmental impact of POW and the growing acceptance of off-chain computation and on-chain verification, they believed that now is the best time to launch new protocols based on the POW UTXO model, such as RGP+.

They believe that with the renaissance of Bitcoin and the market's reevaluation of the value of POW and the UTXO model, Nervos and BTCKB will be at the forefront of cryptocurrency development. Their persistence in POW is not without reason but based on a true understanding of the value of technology and a deep insight into future trends.

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

Regarding Nervos team's understanding of BTC's scalability and BTC L2, and why they chose the RGB protocol, their view is based on their team's characteristics and past technical accumulation. They had deep discussions on whether to pursue TVL or choose an EVM-compatible Layer 2 path. After careful consideration, they believed that sticking to a technical path, even if it meant taking a different path from the mainstream, was their advantage. Their technical choices and strategy, especially the selection of the RGB protocol, were based on their understanding of the conservative attitude of the Bitcoin community and their pursuit of technical innovation.

They were aware that directly competing with Bitcoin and Ethereum was a difficult path. In the past, they tried to position CKB as a Layer 1 public chain similar to Bitcoin and Ethereum, aiming to be a value storage platform. However, this positioning put them in an awkward position—neither fully meeting the conservative standards of the Bitcoin community nor aligning with the development direction of Ethereum. This unique positioning made them seem out of place in both communities.

Faced with this challenge, they decided to embrace their uniqueness and adhere to the original technical vision. This included a deep exploration and innovation of the UTXO model and research into Bitcoin Layer 2 solutions. They believed that by focusing on their technical strengths and innovation, they could find a path that not only aligns with the spirit of Bitcoin but also brings value to the community.

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

3. At the technical level, BTCKB chose the RGB protocol and proposed the RGB++ protocol. Please briefly explain this solution (DA at which layer, client verification, whether there is an open-source index, what VM)?

Baiyu: I will first introduce the background and decision-making process at the time. We believe that the key to the competition of Bitcoin's Layer 2 lies in Layer 1, and the core of the competition in Layer 1 lies in new protocols. We divided the new protocols into two categories: one that uses UTXO-based assets and one that does not. Based on this, we chose protocols with UTXO-based features, such as atomical, RGB, and taproot assets.

In particular, we decided to choose the RGB protocol because Cipher has a strong interest in RGB and conducted in-depth research with Professor Jian. We proposed a way of isomorphic binding to introduce RGB++. In the future, the core direction of CKB will be to advance the technologies related to RGB++, but it needs to be clear that RGB++ and RGB are two different concepts. RGB is mainly developed by the lmpbp association, Dr. Maxim, and was initially proposed by Peter, who used the concept of one-time sealed strips for expansion. RGB++, on the other hand, introduces the possibility of other UTXO chains as clients for RGB++, with its most 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 the technical choices, I will first explain what the RGB protocol is. RGB is actually a protocol that utilizes Bitcoin's one-time sealing and client verification technology to bind RGB transaction states off-chain using Bitcoin's UTXO model, thereby creating an asset protocol on Bitcoin Layer 1. This design allows for the verification of a transaction by only focusing on the transaction path related to that UTXO, without the need to check all transactions for balance or status, as with other models.

As for data availability (DA), we often discuss its storage location and its impact on security in the Ethereum ecosystem at Layer 1 or Layer 2. However, in the Bitcoin ecosystem, this concept is different, especially for protocols like RGB that utilize UTXO features. In the RGB protocol, it is only necessary to verify data related to the user, and theoretically, this data does not need to be stored in a specific DA layer because the parties to the transaction can directly exchange the necessary information.

1. Introduction to RGB++ Protocol

The RGB++ protocol is an extension of RGB. RGB itself requires the exchange of transaction history and data through a P2P network, including the use of 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, to the chain through isomorphic binding or mapping, specifically by placing these functions on CKB (Nervos Network). The state transition of each UTXO on CKB is constrained by CKB smart contracts, allowing for the verification and execution of RGB++ contract assets and logic on CKB, while addressing issues related to interaction, smart contract execution, and proof provision. CKB uses the RISC-V virtual machine, supporting Turing-complete smart contracts, enabling users to directly view or verify asset status on CKB without sacrificing security, or to verify on the client side when needed.

Technical Implementation: Through the RGB++ protocol, compatibility with all operations of RGB is ensured. The issue of slow progress in off-chain client development for RGB is addressed by using a UTXO supply strategy based on proof of work (PoW) instead. Additionally, a mechanism has been implemented to seamlessly migrate 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 the ability to allow transactions to "jump" to the second layer (Layer 2), for example, from the Bitcoin chain to the CKB chain. This means that transactions can be executed multiple times on CKB (e.g., 100 or 1000 times), benefiting from low cost and high performance, and then "settle" back to the Bitcoin chain. This approach significantly improves transaction efficiency and performance while bypassing the performance limitations of Bitcoin itself.

Security Considerations: In the process of implementing the "jump," particular attention has been paid to security. This process does not rely on any trusted cross-chain bridge or multi-signature mechanism, but is based on direct binding between two UTXOs. Based on the security standard of proof of work (PoW), it is believed that transactions on the Bitcoin chain are unlikely to be reversed after 6 blocks, while on CKB, approximately 24 blocks are needed to achieve the same level of security assurance through equivalent calculation. This method ensures the security of asset jumps or migrations between the two layers.

Innovation and Optimization: The approach differs from the Layer 2 logic of Ethereum or other cross-chain bridges, representing innovation and optimization in blockchain technology. Through the RGB++ protocol, not only have performance and cost issues been addressed, but the overall system's security and reliability have also been enhanced.

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

4. Development and Support for RGB++ Protocol

Regarding the compatibility of RGB++ with the original RGB protocol, the development process will be divided into two steps. Initially, full compatibility with the original RGB protocol will not be achieved, mainly because the RGB protocol itself is still evolving and not yet fully mature. Subsequently, using isomorphic binding technology, each transaction of RGB or RGB++ will be bound to a UTXO on CKB (referred to as a cell). This means that the smart contracts and states at the RGB++ protocol layer will be equivalent to the smart contracts and states on CKB. The development tools and support are based on the accumulation of the past five years of CKB, although development is relatively complex.

The differences in intuition and implementation difficulty between Ethereum's account model and CKB's UTXO model in smart contract development are also addressed. The account model of Ethereum aligns more with programmer intuition, allowing for simple function calls to obtain 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 under the account model, which affects the feasibility of isomorphic binding.

Despite the programming difficulty under the UTXO model, it is believed to be the only solution for extending Bitcoin protocol logic. The development tools and foundational design for writing smart contracts using Rust, C, Lua, and JavaScript under the UTXO model, accumulated over the past four to five years, provide rich support for developers. Attempts to implement an AMM similar to Uniswap under the UTXO model faced significant challenges and ultimately failed, demonstrating the difficulty of innovation under the UTXO architecture.

For user experience, the plan is to launch alternative and non-fungible tokens for RGB++ and the corresponding Dex by the end of March, based on CKB. The user experience design aims to simplify asset transfers, eliminating the need for cumbersome engraving steps. The entire process automates isomorphic transactions, providing a transparent experience for users and aiming to deliver a seamless cross-chain interaction experience.

5. Gas Calculation for Bitcoin and CKB Transactions

When conducting transactions on both Bitcoin and CKB, a transaction is indeed executed on both chains. 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 bears these fees and how to ensure they do not impact the user experience.

The solution involves adding an additional output to the Bitcoin transaction, directing a small portion of Bitcoin (costing approximately a few dollars) to a paymaster. This paymaster uses the Bitcoin to construct and initiate a corresponding transaction on CKB, covering the user's fees on the CKB chain.

A key point in this process is that CKB utilizes a feature that allows the transaction to be proven to have 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 and pay the related fees on CKB on behalf of the user, without the need for the user to sign on the CKB chain.

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

6. The BTC L2 solutions on the market are showing explosive trends, such as BounceBit, Merlin Chain, and B^2, all having substantial 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 on the market and how RGB++ plans to enter this market, I will elaborate on two main aspects: the functionality and features of RGB++ as an issuance protocol, and our strategies and plans on the CKB Layer 2 chain.

Firstly, 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 the experience similar to transacting 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 standards for NFTs, namely sport NFTs, which have been applied on the mainnet.

Secondly, regarding the strategy on the CKB Layer 2 chain, we are focused on providing a seamless user experience, including the issuance of native assets and support for cross-chain assets. Bitcoin and Ethereum assets can be bridged to CKB through bridging technology, and we are collaborating with major institutions to ensure the security and reliability of this process. Additionally, we emphasize the importance of a smart contract platform, where once assets are issued on RGB++, they can immediately be utilized for various decentralized applications (DApps) on this platform, such as defining, staking, and mining activities.

On the CKB Layer 2, there are three types of assets: FT, NFT, and CKB native script assets. Each type of asset has its specific applications and trading mechanisms, and we provide the 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 script assets.

In conclusion, the market entry strategy of RGB++ includes both its capability as a powerful NFT and FT issuance protocol and the plan to introduce innovative and native assets on the CKB Layer 2 chain. We are committed to providing a comprehensive smart contract platform, supporting asset cross-chain transfers, and ensuring the security and practicality of the technology through collaborations with industry partners.

7. How are RGB++ assets different from RGB20 and RGB721? Will they be compatible with BRC20 and ARC20 assets, which have a high market share on the Bitcoin main chain?

Bitcoin assets can be roughly divided into two major categories and three subcategories. Firstly, Bitcoin itself is a standalone asset. Secondly, all assets that require off-chain verification, or so-called "colored assets," constitute the second major category. Within this second category, I further divide it into two types: one type is assets that can utilize UTXO features and can be reused on the Lightning Network, and these assets can be migrated to CKB for use through a scheme similar to RGB, via isomorphic mapping and binding. This means that assets like atomical and taproot assets, while still issued on the Bitcoin chain, can be used on CKB through the RGB++ scheme without requiring significant modifications to these protocol assets.

The second type of assets, such as BRC20 assets, which use UTXO features less, are difficult to migrate to CKB through isomorphic binding. For these assets, our approach is similar to other chains on the market, which involves creating a cross-chain bridge. This bridge locks BRC20 assets on the Bitcoin chain and then issues 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 features, such as ordi BRC20 assets. In summary, RGB++ aims to be flexible and compatible with different types of assets for their use and migration between Bitcoin and CKB through the provision of a flexible isomorphic binding mechanism.

8. In the future, what support will RGB++ provide for existing assets with a large user and community base?

We are planning to support existing assets with a wide user base through two main approaches:

1. Script Bridge Support: We intend to support BRC20 or other assets through a script bridge, as long as there are suitable indexers and operators for the bridge. We are seeking partners to build these script cross-chain bridges. We can quickly resolve the issue with the BTC bridge, but we are actively working on the script bridge. This requires support from wallets in the ecosystem, including plugin wallets, which is currently lacking in the CKB ecosystem. We look forward to more support from hardware wallets and plugin wallets in the future, which will be compatible with major protocols, thus supporting the development of the entire ecosystem.

2. Non-Script Bridge Approach: Our initial focus is on the implementation of RGB++. After completing RGB++, we may consider supporting UTXO protocols such as the room protocol and evaluate which method is faster and more effective. Our goal is to implement RGB++ first. Additionally, we are considering collaboration with the Lightning Network team. Although they primarily focus on payments and limited script functionality, we believe bringing these features to CKB and empowering them at the smart contract level is the most suitable 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 approaches and partnerships. We are confident that these efforts are feasible, and ultimately, the implementation is in our hands. ```

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。