RGB++ Protocol and the Future of Bitcoin: Cipher's Insights from Bitcoin Singapore 2024

On March 9th, during the Bitcoin Singapore 2024 conference, co-organized by Nervos Foundation and ABCDE, Cipher, founder of CELL Studio and author of the RGB++ protocol, presented a keynote speech titled 'Overview and Prospects of the RGB++ Protocol'. Here is a summary of the main points from Cipher's presentation: Challenges Faced by the RGB Protocol The RGB protocol has been in existence for many years, yet it hasn't seen widespread adoption due to several factors: Challenges with Interactive Operations In transactions involving BTC, ETH, etc., the receiver only needs to provide an address, and the sender can transfer funds either today or tomorrow, which is very convenient. In contrast, each RGB transaction requires the recipient to first issue an invoice. Then, the sender must construct an RGB transaction and generate a proof of asset history to send to the recipient. Upon receiving this proof, the recipient must perform client-side validation (CSV). After successful validation, they must store this proof for future transactions. Therefore, RGB transactions not only depend on both parties being online but also on both parties storing relevant historical data. This poses a significant hurdle for consumer-oriented products. Data Availability (DA) Issues In RGB transactions, it's essential to attach the historical proof of the asset. If this proof is lost, it's as critical as losing a private key. The question of who will help users save their assets is a problem of data availability. In the original RGB protocol, aimed at preserving privacy, no one else stores assets for users, meaning users must take responsibility for their own data storage. Even with proper data storage, consider a scenario where Alice wants to transfer RGB assets to Bob. How does she send him the historical proof of these assets? Using email or Whatsapp? Clearly, transmitting through any centralized channel is inappropriate, necessitating the use of a specialized P2P channel. However, P2P channels raise issues of confidentiality: why would someone assist in transmitting this sensitive data? This leads to a series of complex issues. Interoperability Issues The historical proof data of RGB assets is retained by the users themselves and passed on to the receiver during transactions, but not made publicly available. This results in the data being scattered across each individual in the network. For someone building a trading platform, whether centralized or decentralized, data from multiple sources is needed to maintain the global state of RGB. There are some RGB service providers who centralize and store this data for application developers, yet this approach diminishes RGB's privacy. Despite this solution, challenges remain, such as facilitating data transfers among various service providers holding different users' RGB data. Issues with Smart Contract/Script Execution Environment There are significant challenges associated with the smart contract or script execution environments in RGB. It utilizes a Virtual Machine (VM) named AluVM, but the specifics of its programming language are yet to be finalized. Moreover, critical development tools, such as compilers and debuggers, are not fully developed. It also lacks support for shared states and decentralized (ownerless) contracts. At present, it’s evident that AluVM is still in its very early stages. Hence, RGB is confronted with numerous complex issues, each requiring considerable time and effort. These challenges significantly contribute to the delays in the effective implementation of RGB. An Overview of the RGB++ Protocol RGB transactions are intricately linked to Bitcoin transactions through a mapping process. Additionally, RGB transactions demand an off-chain infrastructure, encompassing Data Availability (DA), client-side validation, P2P networking, virtual machines, shared states, and decentralized contracts. When considering such an infrastructure, the blockchain naturally comes to mind, given its capabilities in data management, validation, virtual machine integration, P2P networking, incentivization, and smart contracts. The RGB++ protocol concept is based on this fundamental intuition, proposing the use of the UTXO model-based and Turing-complete CKB blockchain as a substitute for the off-chain infrastructure required by RGB. RGB++ introduces a concept called isomorphic binding technology. Each Bitcoin transaction includes an output. In the case of an RGB transaction, it necessitates the inclusion of an OP_RETURN segment within the Bitcoin output. This segment holds specific hash data, termed a commitment. If this commitment coincides with the hash of a transaction on another public blockchain, and if the inputs and outputs of both transactions are isomorphic - meaning they correspond in structure - and assuming that this alternative blockchain's UTXO (Unspent Transaction Output) possesses Turing-complete computational and state storage capabilities, then the transaction on the Bitcoin blockchain becomes fully integrated or bound with the transaction on this other blockchain. The CKB (Common Knowledge Base) blockchain satisfies these prerequisites. Hence, conducting a transaction on Bitcoin effectively equates to performing a corresponding transaction on the CKB chain. Any change in the state of the Bitcoin transaction mirrors a change in the state of the transaction on the CKB chain, adhering to the contract constraints present on CKB. This encapsulates the essence of isomorphic binding technology. However, this concept encompasses numerous intricate technical aspects, including maintaining transactional consistency and preventing double-spending, which are not delved into in detail at this moment. Isomorphic binding technology enables the enhancement of Bitcoin's state capabilities. For instance, let's consider the btc_utxo#1 illustrated in the following diagram. This Bitcoin UTXO (Unspent Transaction Output) typically exhibits just two states: a locking script and an amount, the latter representing the balance. However, in the corresponding blue Cell on the CKB (Common Knowledge Base) blockchain, as shown in the diagram, the capabilities are broader. Unlike the Bitcoin UTXO's limited functionality to just show balance, this isomorphic Cell on the CKB chain can store not only balance data but also various other types of data. In addition to the data component, the Cell possesses a type script. This script serves a specific purpose: it defines the conditions under which assets are received and imposes restrictions on the asset types. Furthermore, the Cell contains a lock script, which in this case is explicitly linked to btc_utxo#1. This linkage implies that the Cell on the CKB blockchain can be spent only if and when btc_utxo#1 is expended. On the CKB platform, we have implemented a Bitcoin light node. Once a Bitcoin transaction is initiated, it's captured by a Relay mechanism, which then transfers this transaction as a form of proof onto the CKB blockchain. This process involves verifying the transaction's presence on the Bitcoin light node and ensuring that the commitment is isomorphic with the transaction. Through this approach, we significantly extend the functionalities of Bitcoin. It paves the way for issuing a wide range of assets directly on Bitcoin and facilitates the expansion of Turing-complete contracts. The advantage of this approach is that we have successfully introduced Turing-complete scripting into the Bitcoin realm while maintaining a security status almost identical to that of Bitcoin Layer 1 (L1). This is because all historical records, transactions, and commitments are linked through the UTXO chain on Bitcoin L1. The trade-off, however, is a slight decrease in privacy. In the case of RGB, data is dispersed among individual users, making it difficult for others to access any particular user's RGB data. With RGB++, all off-chain data are published on the CKB blockchain, which maintains these states, leading to a reduction in privacy. Yet, the worst-case scenario is only a reduction to the level of privacy found in Bitcoin transactions; it does not expose IP addresses or personal identity information. In fact, we could implement an enhanced privacy layer on CKB. Four years ago, we collaborated with the Grin community to write a paper discussing the use of Mimblewimble technology on CKB to create this enhanced privacy layer. In the future, we could integrate this layer into RGB++, enabling not only the concealment of transaction amounts but also severing the links in transaction history. The resultant privacy would be stronger than that of RGB. In summary, we've realized the vision of RGB in a simpler way and expanded its capabilities even further. Unlocking the Potential of Bitcoin L1 Assets Here's a simplified introduction to the leap concept. Homomorphic binding technology, which can be applied to Bitcoin, is equally applicable to Litecoin, Liquid, and other UTXO-based chains. As previously mentioned, in both RGB and RGB++ systems, the payee is a Bitcoin UTXO, endowed with the sole authority to spend. When I create an RGB++ transaction on Bitcoin, I have the option to designate the payee not as a Bitcoin UTXO, but as a Litecoin UTXO. Consequently, this asset 'leaps' to Litecoin, since its subsequent expenditure requires unlocking by a Litecoin UTXO. Similarly, this asset can leap to Liquid, or even leap back to Bitcoin. Of course, there is a special case to consider. When an asset leaps to the CKB blockchain, its data interpretation layer, contract layer, and ownership are all on CKB. This means that it no longer depends on any other chain and can directly engage in transactions and interact with smart contracts on CKB. This can be described as leaping to L2. On L2, users can conduct thousands or even tens of thousands of transactions until someone decides to leap the asset back to Bitcoin. This is what we call transaction folding. Whether it’s RGB or RGB++, transactions take place on the Bitcoin blockchain, where mining fees are expensive. However, once an asset leaps to CKB and undergoes transaction folding, the fees become significantly lower, and it can easily return to the Bitcoin blockchain at any time. This whole process does not rely on any multi-signature bridges or trust in any individuals; the only requirement is to wait for a few more block confirmations. Leaping from the Bitcoin blockchain to the CKB blockchain requires waiting for 6 Bitcoin block confirmations. To leap back from the CKB blockchain to Bitcoin, 24 CKB block confirmations are needed, to prevent block reverts/r. This is why we say we've introduced a new paradigm. Of course, this isn’t our invention but rather an idea that existed in the early materials of RGB, where RGB assets could jump between different UTXO chains. After combining Turing completeness with leaping to CKB, we discovered that the potential applications are extensive and vastly different from the traditional narrative of Ethereum’s multi-signature bridges. Future Prospects Next, let's discuss scalability. Bitcoin's transaction rate is approximately 7 transactions per second (TPS), whereas CKB peaks at around 200 TPS. If you factor in contract execution and script validation costs, the TPS could reduce to about 50, which is less than a tenfold expansion compared to Bitcoin. This isn’t nearly enough, so what are the options for scaling up? We see two main directions: State Channels: State channels represent an ultimate scaling solution, offering a very high-performance ceiling. The challenge, however, lies in the complexity of implementing multi-party contracts, making state channels more suitable for payment transactions and individual-to-server interactions. Jan is set to spearhead the team in advancing research on state channels. AppChain Stack: Constructing a Layer 2 (L2) solution based on the UTXO model, the L2 AppChain will secure its anchoring on CKB, aligning isomorphically with it. This approach allows us to develop innovative scaling strategies within this new paradigm. This is also a key focus for CELL Studio in the coming year. Lastly, I’d like to outline the mission and roadmap for RGB++. RGB++ aims to develop foundational protocol modules to facilitate easy use and integration by third-party developers and users. The roadmap of RGB++ protocol is as follows, and the protocol has already been live on Bitoin mainnet and RGB ++ SDK was released on April 3. By Cipher, founder of CELL Studio and author of the RGB++ protocol. This article is based on Cipher’s talk at Bitcoin Singapore on March 9th, 2024. On March 9th, during the Bitcoin Singapore 2024 conference, co-organized by Nervos Foundation and ABCDE, Cipher, founder of CELL Studio and author of the RGB++ protocol, presented a keynote speech titled 'Overview and Prospects of the RGB++ Protocol'. Here is a summary of the main points from Cipher's presentation: Here is a summary of the main points from Cipher's presentation: Challenges Faced by the RGB Protocol The RGB protocol has been in existence for many years, yet it hasn't seen widespread adoption due to several factors: Challenges with Interactive Operations In transactions involving BTC , ETH , etc., the receiver only needs to provide an address, and the sender can transfer funds either today or tomorrow, which is very convenient. In contrast, each RGB transaction requires the recipient to first issue an invoice. Then, the sender must construct an RGB transaction and generate a proof of asset history to send to the recipient. Upon receiving this proof, the recipient must perform client-side validation (CSV). After successful validation, they must store this proof for future transactions. BTC ETH Therefore, RGB transactions not only depend on both parties being online but also on both parties storing relevant historical data. This poses a significant hurdle for consumer-oriented products. Data Availability (DA) Issues In RGB transactions, it's essential to attach the historical proof of the asset. If this proof is lost, it's as critical as losing a private key. The question of who will help users save their assets is a problem of data availability. In the original RGB protocol, aimed at preserving privacy, no one else stores assets for users, meaning users must take responsibility for their own data storage. Even with proper data storage, consider a scenario where Alice wants to transfer RGB assets to Bob. How does she send him the historical proof of these assets? Using email or Whatsapp? Clearly, transmitting through any centralized channel is inappropriate, necessitating the use of a specialized P2P channel. However, P2P channels raise issues of confidentiality: why would someone assist in transmitting this sensitive data? This leads to a series of complex issues. Interoperability Issues The historical proof data of RGB assets is retained by the users themselves and passed on to the receiver during transactions, but not made publicly available. This results in the data being scattered across each individual in the network. For someone building a trading platform, whether centralized or decentralized, data from multiple sources is needed to maintain the global state of RGB. There are some RGB service providers who centralize and store this data for application developers, yet this approach diminishes RGB's privacy. Despite this solution, challenges remain, such as facilitating data transfers among various service providers holding different users' RGB data. Issues with Smart Contract/Script Execution Environment There are significant challenges associated with the smart contract or script execution environments in RGB. It utilizes a Virtual Machine (VM) named AluVM, but the specifics of its programming language are yet to be finalized. Moreover, critical development tools, such as compilers and debuggers, are not fully developed. It also lacks support for shared states and decentralized (ownerless) contracts. At present, it’s evident that AluVM is still in its very early stages. Hence, RGB is confronted with numerous complex issues, each requiring considerable time and effort. These challenges significantly contribute to the delays in the effective implementation of RGB. An Overview of the RGB++ Protocol RGB transactions are intricately linked to Bitcoin transactions through a mapping process. Additionally, RGB transactions demand an off-chain infrastructure, encompassing Data Availability (DA), client-side validation, P2P networking, virtual machines, shared states, and decentralized contracts. When considering such an infrastructure, the blockchain naturally comes to mind, given its capabilities in data management, validation, virtual machine integration, P2P networking, incentivization, and smart contracts. The RGB++ protocol concept is based on this fundamental intuition, proposing the use of the UTXO model-based and Turing-complete CKB blockchain as a substitute for the off-chain infrastructure required by RGB. RGB++ introduces a concept called isomorphic binding technology . Each Bitcoin transaction includes an output. In the case of an RGB transaction, it necessitates the inclusion of an OP_RETURN segment within the Bitcoin output. This segment holds specific hash data, termed a commitment. If this commitment coincides with the hash of a transaction on another public blockchain, and if the inputs and outputs of both transactions are isomorphic - meaning they correspond in structure - and assuming that this alternative blockchain's UTXO (Unspent Transaction Output) possesses Turing-complete computational and state storage capabilities, then the transaction on the Bitcoin blockchain becomes fully integrated or bound with the transaction on this other blockchain. The CKB (Common Knowledge Base) blockchain satisfies these prerequisites. Hence, conducting a transaction on Bitcoin effectively equates to performing a corresponding transaction on the CKB chain. Any change in the state of the Bitcoin transaction mirrors a change in the state of the transaction on the CKB chain, adhering to the contract constraints present on CKB. This encapsulates the essence of isomorphic binding technology. However, this concept encompasses numerous intricate technical aspects, including maintaining transactional consistency and preventing double-spending, which are not delved into in detail at this moment. isomorphic binding technology Isomorphic binding technology enables the enhancement of Bitcoin's state capabilities. For instance, let's consider the btc_utxo#1 illustrated in the following diagram. This Bitcoin UTXO (Unspent Transaction Output) typically exhibits just two states: a locking script and an amount, the latter representing the balance. However, in the corresponding blue Cell on the CKB (Common Knowledge Base) blockchain, as shown in the diagram, the capabilities are broader. Unlike the Bitcoin UTXO's limited functionality to just show balance, this isomorphic Cell on the CKB chain can store not only balance data but also various other types of data. In addition to the data component, the Cell possesses a type script. This script serves a specific purpose: it defines the conditions under which assets are received and imposes restrictions on the asset types. Furthermore, the Cell contains a lock script, which in this case is explicitly linked to btc_utxo#1. This linkage implies that the Cell on the CKB blockchain can be spent only if and when btc_utxo#1 is expended. On the CKB platform, we have implemented a Bitcoin light node. Once a Bitcoin transaction is initiated, it's captured by a Relay mechanism, which then transfers this transaction as a form of proof onto the CKB blockchain. This process involves verifying the transaction's presence on the Bitcoin light node and ensuring that the commitment is isomorphic with the transaction. Through this approach, we significantly extend the functionalities of Bitcoin. It paves the way for issuing a wide range of assets directly on Bitcoin and facilitates the expansion of Turing-complete contracts. The advantage of this approach is that we have successfully introduced Turing-complete scripting into the Bitcoin realm while maintaining a security status almost identical to that of Bitcoin Layer 1 (L1). This is because all historical records, transactions, and commitments are linked through the UTXO chain on Bitcoin L1. The trade-off, however, is a slight decrease in privacy. In the case of RGB, data is dispersed among individual users, making it difficult for others to access any particular user's RGB data. With RGB++, all off-chain data are published on the CKB blockchain, which maintains these states, leading to a reduction in privacy. Yet, the worst-case scenario is only a reduction to the level of privacy found in Bitcoin transactions; it does not expose IP addresses or personal identity information. In fact, we could implement an enhanced privacy layer on CKB. Four years ago, we collaborated with the Grin community to write a paper discussing the use of Mimblewimble technology on CKB to create this enhanced privacy layer. In the future, we could integrate this layer into RGB++, enabling not only the concealment of transaction amounts but also severing the links in transaction history. The resultant privacy would be stronger than that of RGB. In summary, we've realized the vision of RGB in a simpler way and expanded its capabilities even further. Unlocking the Potential of Bitcoin L1 Assets Here's a simplified introduction to the leap concept. Here's a simplified introduction to the leap concept. Homomorphic binding technology , which can be applied to Bitcoin , is equally applicable to Litecoin, Liquid, and other UTXO-based chains. As previously mentioned, in both RGB and RGB++ systems, the payee is a Bitcoin UTXO, endowed with the sole authority to spend. When I create an RGB++ transaction on Bitcoin, I have the option to designate the payee not as a Bitcoin UTXO, but as a Litecoin UTXO. Consequently, this asset 'leaps' to Litecoin, since its subsequent expenditure requires unlocking by a Litecoin UTXO. Similarly, this asset can leap to Liquid, or even leap back to Bitcoin. Homomorphic binding technology Bitcoin Of course, there is a special case to consider. When an asset leaps to the CKB blockchain, its data interpretation layer, contract layer, and ownership are all on CKB. This means that it no longer depends on any other chain and can directly engage in transactions and interact with smart contracts on CKB. This can be described as leaping to L2. On L2, users can conduct thousands or even tens of thousands of transactions until someone decides to leap the asset back to Bitcoin. This is what we call transaction folding. Whether it’s RGB or RGB++, transactions take place on the Bitcoin blockchain, where mining fees are expensive. However, once an asset leaps to CKB and undergoes transaction folding, the fees become significantly lower, and it can easily return to the Bitcoin blockchain at any time. This whole process does not rely on any multi-signature bridges or trust in any individuals; the only requirement is to wait for a few more block confirmations. Leaping from the Bitcoin blockchain to the CKB blockchain requires waiting for 6 Bitcoin block confirmations. To leap back from the CKB blockchain to Bitcoin, 24 CKB block confirmations are needed, to prevent block reverts/r. This is why we say we've introduced a new paradigm. Of course, this isn’t our invention but rather an idea that existed in the early materials of RGB, where RGB assets could jump between different UTXO chains. After combining Turing completeness with leaping to CKB, we discovered that the potential applications are extensive and vastly different from the traditional narrative of Ethereum’s multi-signature bridges. Future Prospects Next, let's discuss scalability. Bitcoin's transaction rate is approximately 7 transactions per second (TPS), whereas CKB peaks at around 200 TPS. If you factor in contract execution and script validation costs, the TPS could reduce to about 50, which is less than a tenfold expansion compared to Bitcoin. This isn’t nearly enough, so what are the options for scaling up? We see two main directions: State Channels: State channels represent an ultimate scaling solution, offering a very high-performance ceiling. The challenge, however, lies in the complexity of implementing multi-party contracts, making state channels more suitable for payment transactions and individual-to-server interactions. Jan is set to spearhead the team in advancing research on state channels. AppChain Stack: Constructing a Layer 2 (L2) solution based on the UTXO model, the L2 AppChain will secure its anchoring on CKB, aligning isomorphically with it. This approach allows us to develop innovative scaling strategies within this new paradigm. This is also a key focus for CELL Studio in the coming year. State Channels: State channels represent an ultimate scaling solution, offering a very high-performance ceiling. The challenge, however, lies in the complexity of implementing multi-party contracts, making state channels more suitable for payment transactions and individual-to-server interactions. Jan is set to spearhead the team in advancing research on state channels. State Channels : State channels represent an ultimate scaling solution, offering a very high-performance ceiling. The challenge, however, lies in the complexity of implementing multi-party contracts, making state channels more suitable for payment transactions and individual-to-server interactions. Jan is set to spearhead the team in advancing research on state channels. State Channels AppChain Stack: Constructing a Layer 2 (L2) solution based on the UTXO model, the L2 AppChain will secure its anchoring on CKB, aligning isomorphically with it. This approach allows us to develop innovative scaling strategies within this new paradigm. This is also a key focus for CELL Studio in the coming year. AppChain Stack : Constructing a Layer 2 (L2) solution based on the UTXO model, the L2 AppChain will secure its anchoring on CKB, aligning isomorphically with it. This approach allows us to develop innovative scaling strategies within this new paradigm. This is also a key focus for CELL Studio in the coming year. AppChain Stack Lastly, I’d like to outline the mission and roadmap for RGB++. RGB++ aims to develop foundational protocol modules to facilitate easy use and integration by third-party developers and users. The roadmap of RGB++ protocol is as follows, and the protocol has already been live on Bitoin mainnet and RGB ++ SDK was released on April 3. RGB ++ SDK By Cipher, founder of CELL Studio and author of the RGB++ protocol. By Cipher, founder of CELL Studio and author of the RGB++ protocol. This article is based on Cipher’s talk at Bitcoin Singapore on March 9th, 2024. This article is based on Cipher’s talk at Bitcoin Singapore on March 9th, 2024. Bitcoin Singapore Bitcoin Singapore