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, partly due to the team's background with 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 the author of RGB++, CKB co-founder Cipher, and ecosystem leader Baiyu to share their understanding of Bitcoin L2, the mechanism of RGB++, the assets of RGB++, and the construction ideas of the CKB ecosystem.
Below is a text 整理 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 mechanism are irreplaceable. Additionally, our technical choices—including the UTXO model and the adoption of RISC-V architecture—although contrary to the mainstream trends at the time, were made with considerations for long-term sustainability and technological 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 direction, while PoW was seen as outdated technology. Nevertheless, our insistence on 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 narratives of PoS and account models, starting last year, with the expansion of Bitcoin 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 profound insights into future trends.
2. What is the Nervos CKB team's understanding of BTC scaling and BTC L2, and why did they choose the RGB protocol?#
Regarding the Nervos CKB team's understanding of BTC scaling and BTC L2, as well as why we chose the RGB protocol, my view 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 path. 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 stick 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 (where DA is located, client verification, whether there is open-source indexing, what VM is used)?#
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 and one 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 of other UTXO chains serving 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 actually 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 achieving 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 as in 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 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 transacting 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 new virtual machines 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 a RISC-V virtual machine, supporting Turing-complete smart contracts, enabling users to view or verify asset states directly on CKB without sacrificing security, or to verify on the client side when needed.
Technical Implementation: Through the RGB++ protocol, we first ensure compatibility with all operations of RGB. We address the slow progress of off-chain clients by using a UTXO supply chain strategy based on proof of work (PoW). Additionally, we have implemented a mechanism that allows Bitcoin transactions to be seamlessly migrated 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 on CKB (e.g., 100 times, 1000 times), enjoying the benefits of low costs and high performance, and then jump back to the Bitcoin chain. This method significantly improves transaction efficiency and performance while bypassing 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 the Layer 2 logic of Ethereum or other cross-chain bridges, 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 have 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 our exploration of future directions.
4. The development of smart contracts for the RGB protocol is relatively difficult, which is also one of the main reasons for the slow progress of RGB. Will RGB++ 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 existing RGB protocol, mainly because the RGB protocol itself is still evolving and not fully perfected. 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 CKB over the past five years, 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 under the account model, which affects the feasibility of isomorphic binding.
Although programming under the UTXO model is more difficult, we believe it is the only solution to extend 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, which will be based on CKB. The user experience design aims to simplify the process, allowing users to easily transfer assets without cumbersome minting steps. The entire process will automatically handle isomorphic transactions, making it transparent to 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, relying solely 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 to not 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 happen on CKB. How will gas be calculated when users use both chains, including transferring assets between them?#
First, when transactions are made on Bitcoin and CKB, indeed, a transaction is 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 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 this Bitcoin 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 the transaction content of Bitcoin to prove that the transaction indeed occurred on CKB 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 associated 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, 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 an explosive trend, with projects like BounceBit, Merlin Chain, and B² already 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 in the market and how RGB++ will enter this market, I will elaborate on two main aspects: first, the functionality and characteristics 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 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 may face higher gas fees and slower transaction speeds. However, when it comes to trading these assets, they can be directly utilized through 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 working 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) development, 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 partnerships with industry players.
7. What are the differences between RGB++ assets and RGB20, RGB721? Will it be compatible with BRC20 and ARC20 assets that have a higher market share on the Bitcoin original chain?#
Assets on Bitcoin can be roughly divided into two major categories and three subcategories. First, Bitcoin itself is a distinct asset. Second, all assets that require 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 is assets that can utilize 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 on this layer.
The second type of assets, such as BRC20, are those that utilize UTXO characteristics less and are difficult to migrate to CKB through isomorphic binding. For these assets, our approach 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 is suitable for 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 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 wide 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 bridge operators. We are looking for partners to build these inscription cross-chain bridges. We expect to quickly resolve the 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 primary focus is on the implementation of RGB++. After completing RGB++, we may consider supporting other UTXO protocols to see which methods are 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 capabilities to CKB and empowering it at the smart contract level is the most appropriate approach.
Overall, our strategy is flexible and aggressive, aimed at gradually advancing 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 in our hands.