RGB++: Advancing Bitcoin's Layer 2 with Innovation

By DaPangDun On February 13th, Cipher, a co-founder of CKB, introduced an extended protocol for RGB: RGB++. This announcement quickly captured the attention of the market and had a noticeable impact on the secondary market prices of CKB. Prior to the unveiling of this protocol, I engaged in several thorough discussions with Cipher regarding the RGB protocol, exploring its initial concepts and formulations. Consequently, I've decided to write a brief article to express my straightforward understanding of the RGB++ protocol, my personal opinions on it, and my perspectives on the potential implications and effects of this protocol. Overview of RGB++: Expanding the Use Cases of RGB Technology To concisely understand RGB++, consider the following key points: 1.1 An Extension Protocol Based on RGB It incorporates certain technologies from the RGB protocol. Although it doesn't strictly belong to the RGB ecosystem, it significantly expands the use cases of RGB technology. 1.2 Enhancing the Current RGB Protocol’s Capabilities It solves existing technical challenges in the practical application of the RGB protocol and introduces enhanced functionalities, including "verification processes," "contract programmability," and "Turing-complete virtual machines." 1.3 Realized Through UTXO Isomorphic Binding Bitcoin UTXOs are mapped onto Nervos CKB Cells. This process leverages script constraints on both the CKB and Bitcoin blockchains to ensure the accuracy of state computations and the legitimacy of ownership transfers. I believe that the concept of isomorphic binding offers significant potential for scalability. 2. Why Introduce the RGB++ Protocol? Those familiar with my work know that I have been deeply involved in researching the RGB protocol, constantly monitoring its development and the growth of its ecosystem. My extensive research has revealed that although the RGB protocol is beautifully designed, it encounters several challenges in practical implementation: 2.1 Slower Progress in RGB Development One contributing factor is that the majority of its design elements are either entirely new concepts or aimed at establishing new standards. Both require meticulous, comprehensive planning and the creation of novel code from scratch. Another factor is the relatively small number of developers engaged in the protocol layer. This is apparent from the personnel makeup in LNP/BP and the limited scope of current projects within the ecosystem. 2.2 Development of RGB Affected by External Uncontrollable Factors For example, the RGB protocol is typically designed to operate on the Lightning Network. However, the current bolt-ln standard inadequately supports RGB contracts. To address this, the LNP/BP Association has introduced a new standard for the Lightning Network called bifrost. But implementing bifrost is a massive undertaking, requiring substantial work and potentially waiting for broader developments in the Lightning Network. Furthermore, the transfer process in RGB involves handling invoices and committees. At present, these can be managed via platforms like web2 (Twitter, Telegram, etc.) or peer-to-peer networks. However, for a more unified approach, a standardized protocol for transmission is necessary. This role is intended for storm nodes. However, setting up such a network is also a labor-intensive task. 2.3 The AluVM Virtual Machine in RGB Currently Lacks Robust Development Tools and Practical Code This implies that, even after the full release of version 0.11, significant time is needed to evaluate the virtual machine's performance and reliability. Additionally, a considerable period is required to accumulate experience in code development using AluVM and in creating standard libraries. These challenges make RGB stand out in a market where every second counts, similar to the early developmental phase of BTC. It introduces various uncertainties: impacts of market cycles (like missing out on bullish funding phases), emotional influences, the merging of other new technologies (integrations that combine other tech with aspects of RGB to gain an early advantage), among others. To summarize: RGB is highly promising, but the full realization of the protocol is a lengthy process fraught with uncertainties. This forms the backdrop and the challenges that the RGB++ protocol seeks to tackle. The Technical Essence of the RGB++ Solution: Isomorphic Binding As such, the primary focus in the initial stages of discussion centered on two key questions: "How can we resolve the implementation challenges faced by RGB?" and "Is it feasible to leverage CKB’s existing technologies to address these issues to a certain extent?" In a creative approach, Cipher made use of the fundamental element of RGB, "UTXO," and its architectural parallelism with CKB, proposing the concept of "isomorphic binding." This concept gradually laid the foundation for the protocol structure of "RGB++.” Consider the following illustration, which integrates two crucial components of the RGB protocol with CKB’s framework: The UTXO in RGB, acting as a container, can be mapped onto CKB's Cell. This is achieved by utilizing the lock script in the Cell. The off-chain client-side verification mechanism in RGB can be transformed into on-chain public verification within CKB. The data and state used for verification in RGB can correspondingly be integrated with the data and type elements within the Cell. By employing "isomorphic binding," the process of interpreting RGB committees on CKB has been realized. Moreover, to maintain compatibility, users can still perform interpretations on RGB, which is a particularly interesting functionality. Deeper analysis reveals that Cipher has effectively "deconstructed" and "modularized" RGB's technology. This involves evaluating whether certain modules could leverage alternative technological approaches or substitutes, leading to a broader range of possibilities. Following the implementation of "isomorphic binding," the protocol naturally gains extensibility, enabling the realization of various extension functions (detailed information can be found in the white paper): 3.1 Transaction Folding Leveraging the programmability of CKB Cells, multiple CKB transactions can be aligned with a single Bitcoin RGB++ transaction. This strategy allows the expansion of the Bitcoin chain, which is typically slower and has lower throughput, using the high-performance CKB chain. Expanding the concept of "transaction folding," it's possible that not every state change needs synchronization on the Bitcoin blockchain, essentially introducing an "off-chain verification" mechanism in CKB. 3.2 Leaderless Contracts Leaderless contracts are designed so that anyone can modify the state of the contract as long as they meet its constraints, without the necessity for changes to be initiated by a specified digital signature provider. This contract type paves the way for more complex contractual systems such as Automated Market Makers (AMM). 3.3 Non-interactive Transfers One characteristic of RGB protocol transfers is the need for both parties to communicate certain information to complete a transaction. This requirement has its advantages (like protection against scam tokens) but also adds to the complexity and user learning curve. RGB++ can leverage these benefits by transferring interactive processes to the CKB environment, implementing a send-receive operation to facilitate non-interactive transfer logic. This approach is essential for executing widespread airdrops effectively. 3.4 AMM+DEX It's possible to integrate CKB's grid-based AMM design, thereby creating a market-making model based on the UTXO system. Though different from Uniswap's price curve market-making model, this represents a significant step forward for UTXO-based models. 4. The Impact of the RGB++ Protocol Given that the protocol has recently been introduced and its full development is still underway, and considering that many people are not thoroughly acquainted with the RGB protocol itself, there’s a general lack of awareness about the potential transformative effects RGB++ might bring. I will elaborate on my perspective regarding the impact of the RGB++ protocol from several angles: 4.1 For CKB: RGB++ as a Critical Lever in the Struggle for Bitcoin's Legitimate L2 Market CKB, known for its POW mechanism and an advanced "UTXO" model, is regarded for its "orthodoxy." However, despite early backing from several high-profile institutions, its network and ecosystem haven't seen particularly impressive growth. This year, with its pivot towards Bitcoin's L2 space, I see this as a crucial period of opportunity for CKB. On one hand, the underlying technology and foundational infrastructure have matured over the past few years. On the other hand, it's timely aligned with the current wave of interest. During my discussions with Cipher, he put forth a perspective that I found particularly enlightening: The key to winning in the Bitcoin L2 arena hinges on L1. RGB++ fosters a deeper integration between CKB and the Bitcoin mainchain, thereby bolstering its claim to "orthodoxy." This deepened connection is why I see it as one of the pivotal anchors. Digression: Discussing the 'Traditional' L2." The concept of Layer 2 (L2) technology, particularly in its mature form, has evolved mainly from developments in Ethereum. As various L2 solutions and modular developments have progressed, the definition of L2 has become more ambiguous. In the Ethereum context, the approach leans towards pragmatism, and the idea of 'orthodoxy' is progressively diminishing. However, in the Bitcoin network, the notion of 'orthodoxy' has consistently been a prominent signal throughout its entire development process. At present, according to my personal viewpoint, the 'orthodoxy' hierarchy within L2, ranked from highest to lowest, is: 1. Lightning Network, RGB, BitVM These three systems are familiar to many. In essence, each one follows a fundamentally different path in implementation and addresses distinct aspects. Currently, the Lightning Network is the most advanced in terms of development, followed by RGB, and then BitVM. 2. Sidechains Examples include Liquid, Stacks, CKB, and others. The majority of these still utilize the UTXO architecture but with certain adaptations or innovations to enhance aspects like scalability (including privacy and programmability) and to refine the consensus mechanism. Sidechains, to some extent, can be perceived as experimental chains for BTC, serving to test new functions or features that are temporarily unfeasible on the BTC main chain. 3. Others This category could encompass 'L2 based on cross-chain protocols,' 'L2 based on EVM (Ethereum Virtual Machine),' and more. I generally concur with the perspective of Ajian. 4.2 Regarding RGB: RGB++ Amplifies the Possibility of Integration with Other UTXO Architecture-Based Public Blockchains The RGB protocol inherently possesses the capability to merge with other public blockchains built on UTXO architecture. The LNP/BP Association's official Twitter post has revealed its intention to facilitate interoperability with the Liquid network. Through the integration of certain technologies from CKB and RGB, the practical viability of this combination will be substantiated to a considerable extent. Diving deeper: If we further abstract the RGB++ protocol, transforming it into a more expansive extension layer tailored to bridge the RGB protocol with all UTXO architecture-based public blockchains that possess scalability, its narrative and value proposition would be greatly enhanced. This is also the direction I foresee Cipher possibly pursuing in their next phase of efforts. Additionally, this strategy provides alternative developmental avenues for projects within the RGB ecosystem, diverging from the simplistic approach of 'multi-signature cross-chain bridges' and grounded in native methodologies. For Other Bitcoin Layer 2 Solutions: Offering a Technical Blueprint for Incorporating the RGB Protocol Cipher’s analytical breakdown of the RGB technology architecture could serve as a valuable thought paradigm for technicians working on other Layer 2 solutions. They could integrate specific needed technologies from RGB with their project’s unique technical characteristics and strengths. This would enable them to 'synthesize' these elements into a novel product paradigm, potentially even achieving a 'lead advantage' (the term 'lead advantage' here is not derogatory; it signifies the combinatory nature of technology and the innovation within the BTC ecosystem's development. This 'lead advantage' would also likely further the proliferation and evolution of the RGB protocol). Overall, while RGB++ is presently only at the white paper stage, I hold a theoretical optimism towards it. It has the potential to inject fresh vitality into the RGB protocol and could also reinvigorate the CKB network. Author’s bio: DaPangDun, Independent Researcher This article is a translation of DaPangDun’s original post. By DaPangDun DaPangDun DaPangDun On February 13th, Cipher, a co-founder of CKB, introduced an extended protocol for RGB: RGB++ . This announcement quickly captured the attention of the market and had a noticeable impact on the secondary market prices of CKB. RGB++ Prior to the unveiling of this protocol, I engaged in several thorough discussions with Cipher regarding the RGB protocol, exploring its initial concepts and formulations. Consequently, I've decided to write a brief article to express my straightforward understanding of the RGB++ protocol, my personal opinions on it, and my perspectives on the potential implications and effects of this protocol. Overview of RGB++: Expanding the Use Cases of RGB Technology To concisely understand RGB++, consider the following key points: 1.1 An Extension Protocol Based on RGB It incorporates certain technologies from the RGB protocol. Although it doesn't strictly belong to the RGB ecosystem, it significantly expands the use cases of RGB technology. 1.2 Enhancing the Current RGB Protocol’s Capabilities It solves existing technical challenges in the practical application of the RGB protocol and introduces enhanced functionalities, including "verification processes," "contract programmability," and "Turing-complete virtual machines." 1.3 Realized Through UTXO Isomorphic Binding Bitcoin UTXOs are mapped onto Nervos CKB Cells. This process leverages script constraints on both the CKB and Bitcoin blockchains to ensure the accuracy of state computations and the legitimacy of ownership transfers. I believe that the concept of isomorphic binding offers significant potential for scalability. 2. Why Introduce the RGB++ Protocol? Those familiar with my work know that I have been deeply involved in researching the RGB protocol, constantly monitoring its development and the growth of its ecosystem. My extensive research has revealed that although the RGB protocol is beautifully designed, it encounters several challenges in practical implementation: 2.1 Slower Progress in RGB Development One contributing factor is that the majority of its design elements are either entirely new concepts or aimed at establishing new standards. Both require meticulous, comprehensive planning and the creation of novel code from scratch. Another factor is the relatively small number of developers engaged in the protocol layer. This is apparent from the personnel makeup in LNP/BP and the limited scope of current projects within the ecosystem. 2.2 Development of RGB Affected by External Uncontrollable Factors For example, the RGB protocol is typically designed to operate on the Lightning Network. However, the current bolt-ln standard inadequately supports RGB contracts. To address this, the LNP/BP Association has introduced a new standard for the Lightning Network called bifrost. But implementing bifrost is a massive undertaking, requiring substantial work and potentially waiting for broader developments in the Lightning Network. Furthermore, the transfer process in RGB involves handling invoices and committees. At present, these can be managed via platforms like web2 (Twitter, Telegram, etc.) or peer-to-peer networks. However, for a more unified approach, a standardized protocol for transmission is necessary. This role is intended for storm nodes. However, setting up such a network is also a labor-intensive task. 2.3 The AluVM Virtual Machine in RGB Currently Lacks Robust Development Tools and Practical Code This implies that, even after the full release of version 0.11, significant time is needed to evaluate the virtual machine's performance and reliability. Additionally, a considerable period is required to accumulate experience in code development using AluVM and in creating standard libraries. These challenges make RGB stand out in a market where every second counts, similar to the early developmental phase of BTC. It introduces various uncertainties: impacts of market cycles (like missing out on bullish funding phases), emotional influences, the merging of other new technologies (integrations that combine other tech with aspects of RGB to gain an early advantage), among others. To summarize: RGB is highly promising, but the full realization of the protocol is a lengthy process fraught with uncertainties. RGB is highly promising, but the full realization of the protocol is a lengthy process fraught with uncertainties. This forms the backdrop and the challenges that the RGB++ protocol seeks to tackle. The Technical Essence of the RGB++ Solution: Isomorphic Binding As such, the primary focus in the initial stages of discussion centered on two key questions: "How can we resolve the implementation challenges faced by RGB?" and "Is it feasible to leverage CKB’s existing technologies to address these issues to a certain extent?" In a creative approach, Cipher made use of the fundamental element of RGB, "UTXO," and its architectural parallelism with CKB, proposing the concept of "isomorphic binding." This concept gradually laid the foundation for the protocol structure of "RGB++.” Consider the following illustration, which integrates two crucial components of the RGB protocol with CKB’s framework: The UTXO in RGB, acting as a container, can be mapped onto CKB's Cell . This is achieved by utilizing the lock script in the Cell. UTXO Cell The off-chain client-side verification mechanism in RGB can be transformed into on-chain public verification within CKB. The data and state used for verification in RGB can correspondingly be integrated with the data and type elements within the Cell. off-chain client-side verification on-chain public verification By employing "isomorphic binding," the process of interpreting RGB committees on CKB has been realized. Moreover, to maintain compatibility, users can still perform interpretations on RGB, which is a particularly interesting functionality. Deeper analysis reveals that Cipher has effectively "deconstructed" and "modularized" RGB's technology. This involves evaluating whether certain modules could leverage alternative technological approaches or substitutes, leading to a broader range of possibilities. Following the implementation of "isomorphic binding," the protocol naturally gains extensibility, enabling the realization of various extension functions (detailed information can be found in the white paper): 3.1 Transaction Folding Leveraging the programmability of CKB Cells, multiple CKB transactions can be aligned with a single Bitcoin RGB++ transaction. This strategy allows the expansion of the Bitcoin chain, which is typically slower and has lower throughput, using the high-performance CKB chain. Expanding the concept of "transaction folding," it's possible that not every state change needs synchronization on the Bitcoin blockchain, essentially introducing an "off-chain verification" mechanism in CKB. 3.2 Leaderless Contracts Leaderless contracts are designed so that anyone can modify the state of the contract as long as they meet its constraints, without the necessity for changes to be initiated by a specified digital signature provider. This contract type paves the way for more complex contractual systems such as Automated Market Makers (AMM). 3.3 Non-interactive Transfers One characteristic of RGB protocol transfers is the need for both parties to communicate certain information to complete a transaction. This requirement has its advantages (like protection against scam tokens) but also adds to the complexity and user learning curve. RGB++ can leverage these benefits by transferring interactive processes to the CKB environment, implementing a send-receive operation to facilitate non-interactive transfer logic. This approach is essential for executing widespread airdrops effectively. 3.4 AMM+DEX It's possible to integrate CKB's grid-based AMM design, thereby creating a market-making model based on the UTXO system. Though different from Uniswap's price curve market-making model, this represents a significant step forward for UTXO-based models. 4. The Impact of the RGB++ Protocol Given that the protocol has recently been introduced and its full development is still underway, and considering that many people are not thoroughly acquainted with the RGB protocol itself, there’s a general lack of awareness about the potential transformative effects RGB++ might bring. I will elaborate on my perspective regarding the impact of the RGB++ protocol from several angles: 4.1 For CKB: RGB++ as a Critical Lever in the Struggle for Bitcoin's Legitimate L2 Market CKB, known for its POW mechanism and an advanced "UTXO" model, is regarded for its "orthodoxy." However, despite early backing from several high-profile institutions, its network and ecosystem haven't seen particularly impressive growth. This year, with its pivot towards Bitcoin's L2 space, I see this as a crucial period of opportunity for CKB. On one hand, the underlying technology and foundational infrastructure have matured over the past few years. On the other hand, it's timely aligned with the current wave of interest. During my discussions with Cipher, he put forth a perspective that I found particularly enlightening: The key to winning in the Bitcoin L2 arena hinges on L1. The key to winning in the Bitcoin L2 arena hinges on L1. RGB++ fosters a deeper integration between CKB and the Bitcoin mainchain, thereby bolstering its claim to "orthodoxy." This deepened connection is why I see it as one of the pivotal anchors. Digression: Discussing the 'Traditional' L2." The concept of Layer 2 (L2) technology, particularly in its mature form, has evolved mainly from developments in Ethereum. As various L2 solutions and modular developments have progressed, the definition of L2 has become more ambiguous. In the Ethereum context, the approach leans towards pragmatism, and the idea of 'orthodoxy' is progressively diminishing. However, in the Bitcoin network, the notion of 'orthodoxy' has consistently been a prominent signal throughout its entire development process. At present, according to my personal viewpoint, the 'orthodoxy' hierarchy within L2, ranked from highest to lowest, is: 1. Lightning Network, RGB, BitVM These three systems are familiar to many. In essence, each one follows a fundamentally different path in implementation and addresses distinct aspects. Currently, the Lightning Network is the most advanced in terms of development, followed by RGB, and then BitVM. 2. Sidechains Examples include Liquid, Stacks, CKB, and others. The majority of these still utilize the UTXO architecture but with certain adaptations or innovations to enhance aspects like scalability (including privacy and programmability) and to refine the consensus mechanism. Sidechains, to some extent, can be perceived as experimental chains for BTC, serving to test new functions or features that are temporarily unfeasible on the BTC main chain. 3. Others This category could encompass 'L2 based on cross-chain protocols,' 'L2 based on EVM (Ethereum Virtual Machine),' and more. I generally concur with the perspective of Ajian. 4.2 Regarding RGB: RGB++ Amplifies the Possibility of Integration with Other UTXO Architecture-Based Public Blockchains The RGB protocol inherently possesses the capability to merge with other public blockchains built on UTXO architecture. The LNP/BP Association's official Twitter post has revealed its intention to facilitate interoperability with the Liquid network. Through the integration of certain technologies from CKB and RGB, the practical viability of this combination will be substantiated to a considerable extent. Diving deeper: If we further abstract the RGB++ protocol, transforming it into a more expansive extension layer tailored to bridge the RGB protocol with all UTXO architecture-based public blockchains that possess scalability, its narrative and value proposition would be greatly enhanced. This is also the direction I foresee Cipher possibly pursuing in their next phase of efforts. Additionally, this strategy provides alternative developmental avenues for projects within the RGB ecosystem, diverging from the simplistic approach of 'multi-signature cross-chain bridges' and grounded in native methodologies. For Other Bitcoin Layer 2 Solutions: Offering a Technical Blueprint for Incorporating the RGB Protocol Cipher’s analytical breakdown of the RGB technology architecture could serve as a valuable thought paradigm for technicians working on other Layer 2 solutions. They could integrate specific needed technologies from RGB with their project’s unique technical characteristics and strengths. This would enable them to 'synthesize' these elements into a novel product paradigm, potentially even achieving a 'lead advantage' (the term 'lead advantage' here is not derogatory; it signifies the combinatory nature of technology and the innovation within the BTC ecosystem's development. This 'lead advantage' would also likely further the proliferation and evolution of the RGB protocol). Overall, while RGB++ is presently only at the white paper stage, I hold a theoretical optimism towards it. It has the potential to inject fresh vitality into the RGB protocol and could also reinvigorate the CKB network. Overall, while RGB++ is presently only at the white paper stage, I hold a theoretical optimism towards it. It has the potential to inject fresh vitality into the RGB protocol and could also reinvigorate the CKB network. Author’s bio : Author’s bio DaPangDun , Independent Researcher DaPangDun DaPangDun This article is a translation of DaPangDun’s original post.