Forward the Original Title： In-depth Discussion on the Runes Protocol and the “Public Engraving” Issuance Mechanism

This article is reprinted from Foresight News, written by Trustless Labs. Original article link: https://foresightnews.pro/article/detail/54503 The enthusiasm for the Bitcoin Layer 2 track remains high, among the many L2 projects, CKB stands out for several reasons. On one hand, because the team originates from the well-known public chain Nervos CKB, which has been deeply engaged in the Proof of Work (PoW) mechanism; on the other hand, after announcing the repositioning as a BTC Layer 2 network, the team proposed an innovative scheme, RGB++, using the Cell on the CKB chain to “isomorphically bind” the original chain’s UTXO of Bitcoin. The market’s response to CKB has been very enthusiastic. On February 22, Trustless Labs invited the authors of RGB++ and CKB co-founder Cipher as well as the ecosystem leader Baiyu to share their understanding of Bitcoin L2, the mechanism of RGB++, the assets of RGB++, and the development ideas of the CKB ecosystem. The following is a text arrangement of the content in the Twitter space:

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 has chosen to stick with PoW instead of transitioning to a PoS chain, a decision rooted in our deep understanding of technology and the market. We believe the decentralization and security brought by the Proof of Work (PoW) mechanism are irreplaceable. Additionally, our technology choices—including the UTXO model and the adoption of the RISC-V architecture—although against the mainstream trend at the time, were based on considerations for long-term sustainability and technological advantages. From the start of the project in 2018 to its launch in 2019, we have experienced multiple fluctuations in the cryptocurrency market, but we have never changed our direction. At that time, smart contracts and PoS mechanisms were considered the future direction, while PoW was seen as outdated technology. Nonetheless, our commitment to PoW is not merely out of preference for the technology, but also because we believe the UTXO model and PoW mechanism can provide unique security and decentralization characteristics that other technological solutions cannot replace. Regarding the idea of transitioning to BTCKB, it actually stems from our profound insights into market narratives. Over the past few years, although our narrative seemed to be suppressed by the PoS and account model narratives, since 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 cases for Bitcoin but also enhanced user understanding and acceptance of UTXO and PoW. Furthermore, with the re-evaluation of the environmental impact of PoW and the increasing recognition of off-chain computation and on-chain verification patterns, we believe now is the best time to launch new protocols based on the PoW UTXO model, such as RGB++. I believe, with the Renaissance of Bitcoin and the market’s re-evaluation of the value of PoW and UTXO models, Nervos CKB will be at the forefront of cryptocurrency development. Our commitment to PoW is not without reason but is based on a true understanding of the technology’s value and a profound insight into future trends.

2. How does the Nervos CKB team understand the scaling of BTC and BTC’s Layer 2 solutions, and why choose the RGB protocol?

The perspective of the Nervos CKB team on BTC scaling, BTC Layer 2 solutions, and the choice of the RGB protocol is based on our team’s characteristics and technical accumulation. We had in-depth discussions on whether to pursue Total Value Locked (TVL) or opt for an EVM-compatible Layer 2 route. After careful consideration, we believe that adhering to a technology-driven approach, even if it means taking a different path from the mainstream, is our advantage. Our technological 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 are well aware that competing directly with Bitcoin and Ethereum is a challenging 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 placed us in an awkward situation—neither fully meeting the conservative standards of the Bitcoin community nor aligning with the development direction of Ethereum. This unique position made us somewhat out of place in both communities.

Faced with such challenges, we decided to embrace our characteristics and stick to our original technological vision. This includes a deep exploration and innovation of the UTXO model and research into Bitcoin’s Layer 2 solutions. We believe that by focusing on our technological strengths and innovations, we can find a path that aligns 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 was gradually increasing, which provided a favorable opportunity for our transformation. We decided to clearly express CKB’s positioning as a Layer 2 solution for Bitcoin, which not only aligns with our technological philosophy but also provides new growth opportunities for the Bitcoin ecosystem. Overall, our decisions are based on a profound understanding of the essence of technology and keen insights into market trends. We believe that by focusing on our core strengths and persisting in technological innovation, we can find our unique position in the world of cryptocurrencies.

3. The Technical Choices of BTCKB: Exploring the RGB Protocol and the Introduction of RGB++

Interview with Baiyu: Explaining the RGB++ Protocol (DA Layer, Client-Side Verification, Open-Source Index, and VM)

Baiyu: To begin, I’ll provide some context about our decision-making process. We believe that the competition in Bitcoin’s Layer 2 fundamentally stems from Layer 1, where the core of the competition lies in the introduction of new protocols. We categorize these new protocols into two types: those that utilize the UTXO feature and those that do not. Based on this, we opted for protocols with UTXO characteristics, such as Atomical, RGB, and Taproot assets.

Specifically, we chose the RGB protocol due to Cipher’s strong interest in RGB and his extensive research with Professor Ajian. We proposed a method of isomorphic binding to introduce RGB++. It’s important to note that RGB++ and RGB are distinct concepts. The RGB protocol was initially proposed by Peter, further developed by the LNP/BP Association, and Dr. Maxim, employing the concept of one-time seals for expansion. In contrast, RGB++ introduces the possibility of other UTXO chains serving as clients, with its core contribution being the concept of isomorphic binding. From CKB’s perspective, we aim to support more protocols in the future.

Cipher: Discussing the technical choices, let’s first explain what the RGB protocol is. RGB utilizes Bitcoin’s one-time seals and client-side verification technology to bind RGB transaction states off-chain through Bitcoin’s UTXO model, creating an asset protocol on Bitcoin Layer 1. This design allows for transaction verification to focus solely on the transaction path related to that UTXO, avoiding the need to check all transactions for balance or state confirmation.

Data availability (DA) often discusses its placement in Layer 1 or Layer 2 within the Ethereum ecosystem and its impact on security. However, this concept differs in the Bitcoin ecosystem, especially for UTXO-based protocols like RGB. In RGB, it’s sufficient to verify user-related data, which theoretically doesn’t need to be stored on a specific DA layer since parties can directly exchange the necessary information.

The RGB++ protocol extends RGB, which originally required exchanging transaction history and data through a P2P network, including new virtual machines and defining interaction logic, complicating off-chain logic and slowing development. RGB++ aims to move all “smart” components of the RGB protocol, such as P2P networks, virtual machines, and smart contracts, on-chain, specifically to CKB. State transitions for each UTXO on CKB are constrained by CKB smart contracts, enabling verification and execution of RGB++ contract assets and logic on CKB, addressing interaction, smart contract execution, and proof provision issues. CKB uses a RISC-V virtual machine, supporting Turing-complete smart contracts, allowing users to view or verify asset states directly on CKB without sacrificing security or verifying on the client-side if necessary.

Implementation: The RGB++ protocol ensures compatibility with all RGB operations. It addresses the slow progress of off-chain clients by adopting a Proof-of-Work (PoW) based UTXO chain strategy. Moreover, we implemented a mechanism for seamlessly migrating transactions from Bitcoin to CKB, utilizing CKB’s high-performance execution environment before migrating the results back to Bitcoin.

Performance Optimization: A key feature of the RGB++ protocol is allowing transactions to jump to Layer 2 (e.g., from Bitcoin to CKB), significantly enhancing transaction efficiency and performance while circumventing Bitcoin’s performance limitations.

Security Considerations: In implementing the jump process, we prioritized security, relying on direct bindings between two UTXOs rather than trust-based cross-chain bridges or multi-signature mechanisms. We adhere to PoW security standards, considering transactions on the Bitcoin blockchain irreversible after six blocks, and on CKB, approximately 24 blocks are needed for equivalent security. This method ensures the safety of asset jumps or migrations between layers.

Innovation and Optimization: Our approach differs from Ethereum’s Layer 2 logic or other cross-chain bridges, representing our innovation and optimization in blockchain technology. The RGB++ protocol addresses performance and cost issues while enhancing system security and reliability.

In summary, by introducing the RGB++ protocol, we’ve significantly improved performance and ensured strict security 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 in the RGB Protocol Is Challenging, Which Is One of the Main Reasons for Its Slow Progress. Will RGB++ Adopt the Same Smart Contracts as RGB? What Technical Stack and Support Are Available for Developers?

Firstly, 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 has not been fully perfected. In the second step, we will utilize isomorphic binding technology to bind each RGB or RGB++ transaction to CKB’s UTXO (which we refer to as a cell). This means that the smart contracts and states at the RGB++ protocol layer will be equivalent to those on CKB. Our toolchain and support are based on CKB’s past five years of accumulation, although development is relatively complex.

Secondly, compared to Ethereum’s account model, the intuitive difference and implementation difficulty in smart contract development with CKB’s UTXO model are significant. Ethereum’s account model aligns more with programmers’ intuition, allowing for straightforward function calls to obtain results. However, implementing UTXO-based business logic (such as RGB or RGB++) under the account model is extremely difficult, due to the transaction outcome uncertainty in the account model, which affects the feasibility of isomorphic binding.

Despite the difficulty of programming in the UTXO model, we believe it is the only option for extending Bitcoin’s protocol logic. Our development tools and product awareness accumulated over the past four to five years, including toolchains and foundational designs for writing smart contracts in Rust, C, Lua, and JavaScript, provide rich support for developers. We attempted to implement an AMM similar to Uniswap in the UTXO model but encountered significant challenges, leading to the project’s failure, which highlights the difficulty of innovating within the UTXO architecture.

Regarding user experience, we plan to launch RGB++’s fungible and non-fungible tokens and the corresponding DEX based on CKB by the end of March. The user experience design aims to be simplified, enabling users to easily transfer assets without cumbersome minting steps. The entire process automates the handling of isomorphic transactions, transparent to users, aiming to provide a seamless cross-chain interaction experience.

In terms of technical choices, we first ensured 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 migrate back to the Bitcoin chain. This process, which we call “jump,” allows assets to safely jump between the two chains without relying on any trusted cross-chain bridges or multisig mechanisms, relying solely on the binding between UTXOs. This design is based on the trust difference in block confirmation times between Bitcoin and CKB, ensuring the safety of asset migration through an appropriate length of block confirmations.

To address the challenges of developing smart contracts for the RGB protocol, we counter this by offering a richer exchange experience and development support on CKB. We will launch a Layer 2 DEX solution to optimize user experience, making it unnecessary for users to worry about whether their assets are on Layer 1 or Layer 2. This DEX allows users’ assets to be listed from the Bitcoin chain to the DEX, transferring ownership of the assets from Bitcoin’s UTXO to a CKB address, ensuring the safety and transparency of the transfer. The smart contract code we use is open source, reducing users’ security concerns. Moreover, we ensure double-spending protection during the asset jump process and a smooth transaction experience on Layer 2, so users need not worry about the specific location of their assets, thus providing a nearly seamless trading experience.

5. Since a transaction on Bitcoin results in a synchronized similar transaction on CKB, how is gas calculated when users utilize both chains, including in scenarios of asset transfer between them?

First, when transactions occur on both Bitcoin and CKB, a transaction is indeed executed on each chain. Transactions on CKB not only require a network usage fee (gas fee) but also a state storage fee for storing transaction states (such as the amount of CKB held). This state fee usually requires more than 100 CKB, raising questions about who bears these costs and how to ensure it doesn’t negatively affect user experience.

The solution involves adding an extra output in the Bitcoin transaction, a small amount of Bitcoin (costing roughly a few dollars), directed to a paymaster who covers the costs on CKB by constructing and initiating a corresponding transaction on behalf of the user.

A key point here is that CKB utilizes a feature allowing proof of the Bitcoin transaction on CKB without the need for the user to sign again on the CKB chain. This means anyone (like relayers or paymasters) can initiate transactions on CKB on behalf of users and cover related costs.

Ultimately, this mechanism allows users to transfer assets between the two chains without worrying about calculating and paying gas fees directly. These costs are indirectly managed through the extra output added in the Bitcoin transaction and covered by the paymaster, providing a seamless and user-friendly experience.

6. With BTC L2 solutions like BounceBit, Merlin Chain, and B^2 showing substantial TVL growth, how does RGB++ plan to enter the market? Will RGB++ have a native asset issuance protocol?

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

Firstly, RGB++’s core functionality is as an issuance protocol for NFTs and Fungible Tokens (FTs). This means RGB++ supports the issuance of NFTs and FTs, offering an experience similar to trading on the Bitcoin mainnet but possibly facing higher gas fees and slower transaction speeds. However, these assets can be directly traded on CKB’s DEX, following the same standards as assets on CKB, like our FT standard xUDT, similar to ERC20. We also have a standard for NFTs, Spore NFT, which is already applied on the mainnet.

Secondly, regarding our strategy on CKB Layer 2, we focus on providing a smooth user experience, including the issuance of native assets and support for cross-chain assets. Bitcoin and Ethereum assets can be transferred to CKB via bridge technologies, and we are collaborating with major institutions to ensure the security and reliability of this process. Moreover, we highlight the importance of a smart contract platform; once assets are issued on RGB++, they can immediately utilize this platform for various decentralized applications (dApps) development, like lending, staking, and mining activities.

On CKB Layer 2, we focus on three types of assets: FTs, NFTs, and CKB native inscription assets. Each asset type has its specific applications and transaction 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 like 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 capability as a powerful NFT and FT issuance protocol and launching innovative and native assets on CKB Layer 2. We are committed to providing a comprehensive smart contract platform, supporting cross-chain asset transfers, and ensuring the security and practicality of our technology through partnerships with industry players.

7. How do RGB++ assets differ from RGB20 and RGB721? Are they compatible with BRC20 and ARC20 assets, which have a higher market share on the original Bitcoin chain?

Assets on Bitcoin can generally be divided into two main categories and three subcategories. First, Bitcoin itself is a unique category of asset. Second, all assets that require off-chain verification, or so-called “colored coins,” constitute the second major category. Within this second major 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. These types of assets, through schemes similar to RGB, can migrate to CKB 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 needing too many modifications to this layer of protocol assets.

The second type of assets, such as BRC20, which use UTXO features less, are difficult to migrate to CKB through isomorphic binding. For these types of assets, our approach is similar to that of other chains on the market, that is, by 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 applicable to protocol assets that cannot directly utilize UTXO features, such as ORDI, a type of BRC20 asset. 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 in the future for existing assets with a large user base and community?

We are planning support for existing assets with a wide user base. Two main approaches are considered:

1. Inscription Bridge Support: We plan to support BRC 20 or other assets through inscription bridges, as long as there are suitable indexers and bridge operators. We are looking for partners to build these inscription cross-chain bridges. The issue with the BTC bridge will be resolved soon, and we are working hard on the inscription bridge. This requires the support of 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 the main protocols and thus support the development of the entire ecosystem.

2. Non-Inscription Bridge Approach: Our first focus is the implementation of RGB++. After completing RGB++, we might consider supporting other UTXO protocols to see which method is faster and more efficient. Our goal is to first implement RGB++. Additionally, we are considering cooperation with the Lightning Network team. Although they mainly focus on payments and limited script functionalities, we believe that bringing these functionalities to CKB and providing them with a smart contract layer is the most appropriate way.

Overall, our strategy is flexible and aggressive, aimed at gradually advancing support for a wide range of user and community assets through various technical approaches and partnerships. We are confident that these tasks are feasible, and the ultimate implementation power lies in our own hands.

Statement:

1. This article is reprinted from Foresight News, and the copyright belongs to the original author, Trustless Labs. If there are any objections to the reprint, please contact the Gate Learn team, and the team will process it as quickly as possible according to the relevant procedures.

2. Disclaimer: The views and opinions expressed in this article are those of the author alone and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team. Without mentioning Gate.io, copying, disseminating, or plagiarizing the translated articles is not allowed.