Exploring Bitcoin Scaling Solutions: RGB ++

Introduction

Welcome to our second post! We’re excited to continue with this series of articles focused on Bitcoin (BTC) Scaling solutions. Our goal is to simplify and explain these technologies, showing how they can make blockchain faster and more efficient. In this post, we will be focused on exploring RGB++ Bitcoin Scaling Solution.

Overview and Vision

RGB++ is an extension of the RGB protocol, introduced by the Cipher from Nervos CKB team. Nervos CKB is a public blockchain that utilizes a UTXO-based model, referred to as “Cells” within its framework. Building upon the RGB protocol, RGB++ maps RGB UTXO structure to Nervos CKB’s Cells, leveraging script constraints on both the CKB and Bitcoin networks to ensure the accuracy of state computations and the legitimacy of ownership transfers. The goal of RGB++ is to address the technical challenges faced by the original RGB protocol in real-world scenarios by offloading the client-side workload onto the CKB blockchain.

Protocol Overview

To keep things accessible, we will avoid delving into the complex technicalities of the protocol in this section. Instead, we will explain the protocol’s operation in a straightforward manner.

How It Works

As an extension of RGB, it is advisable to familiarize yourself with the RGB protocol before proceeding. The essence of RGB++ is the shift from the traditional client-side validation approach to a model where all data is openly published on the Nervos CKB blockchain, with CKB serving as the execution engine. We will continue to use an example from the RGB protocol to illustrate this, as depicted in the figure below (Please note: This figure is a simplified representation of RGB++’s basic functioning for illustrative purposes only).

In the example, Bob is transferring 70 RGB assets to Alice. Unlike the previous client-side verification, all RGB-related data is now publicly available on the CKB chain, with CKB taking on the role of the execution engine to manage and maintain the RGB contract state.

• Bob can easily verify through Nervos CKB that he has 100 RGB assets associated with his UTXO1.
• When Bob sends assets to Alice, there is no need to share data0 and data1 with her; Alice can independently access the current contract state or historical data on the blockchain.
• Once the Bitcoin transaction that includes the commitment(0x345AB…D7654) is confirmed, Bob can submit a transaction with the RGB data (data2) to CKB. CKB nodes, running a lightweight version of the Bitcoin node, will verify the existence of the commitment on the Bitcoin network.
• After CKB processes the transaction, Alice can see that she now holds 70 RGB assets on her UTXO4.

As a result, the CKB chain now handles the majority of functions previously managed by the client in the RGB protocol. This transition significantly reduces the data storage and verification burden on users. However, this approach does come with a trade-off: the level of privacy inherent in the original RGB protocol is diminished.

Details for Transaction Process

The white paper of the RGB++ protocol offers an in-depth explanation of the transaction process, which we will use here, complemented by the above diagram.

Off-chain Computing

• Bob chooses the next UTXO to be used for the BTC transaction, such as UTXO1.
• Bob performs off-chain computing to create an RGB++ transaction for submission to the CKB network: CKB_TX. This transaction includes the necessary data for changes in the RGB state.
• Bob calculates an off-chain commitment value commitment(0x345AB...D7654).

Submission of BTC Transaction

• Bob creates and dispatches a Bitcoin transaction that spends UTXO1, incorporating the aforementioned commitment(0x345AB...D7654) through an OP_RETURN operation.

Submission of CKB Transaction

• Bob submits CKB_TX to the CKB network.
• The most recent user state is preserved in CKB_TX.output.data.
• The subsequent state change (by Alice) will require UTXO4 and the output of CKB_TX.

Chain Verification

• The Bitcoin UTXO1 is utilized only once.
• Through a Bitcoin Light Node, CKB verifies the commitment value on the Bitcoin network and ensures that the appropriate UTXO has been spent.
• CKB confirms that the contract’s state transition on its network adheres to the predefined contract rules.

Trust and Security

Since security is a fundamental aspect of every blockchain protocol, we will analyze from the perspective of “trust” the components of the protocol and applications that users need to have confidence in, and provide an analysis. Unless otherwise mentioned, we consider the classic cryptographic algorithms used in the protocol to be trustworthy (not considering quantum computers).

1. Users must trust the Bitcoin network.

• Transactions on the Bitcoin network must not be double-spent; otherwise, RGB(++) assets would also be at risk of double-spending.
• Transactions on the Bitcoin network must not be censored; otherwise, RGB(++) transactions might not be able to be recorded on the blockchain.

2. Users must trust the transaction execution mechanism of the CKB network for the same reasons as with RGB.

3. Users must trust that the CKB network will access recent Bitcoin transactions for verification. Otherwise, illegal states might be recorded on the blockchain.

4. Users must trust that the CKB network will not censor their transactions. If a user’s transaction is censored and cannot be recorded on the blockchain, they will not receive the results of the transaction execution. However, in such cases, the protocol can revert from RGB++ back to RGB, re-enabling the client-side validation paradigm to compute transaction results offline.

5. Users must have a certain level of trust in the consistency of the CKB network (consistency can be understood as whether confirmed transactions will be rolled back).

• Corresponding to the commitment on Bitcoin, malicious attackers cannot construct another CKB transaction containing different execution content. Users do not need to worry about double-spending of RGB assets due to inconsistencies on the CKB network.
• However, users should consider that if the CKB network experiences a rollback, it could result in the loss of transaction data. If users have not saved the relevant transaction data, this could potentially lead to the permanent loss of RGB++ data.

It should be noted that the above trust analysis does not take into account the extended features planned by the RGB++ project, such as “transaction folding” and “global state cells”.

RGB++ Summary: Advantages and Disadvantages

RGB++ is an extension to RGB, let’s analyze the strengths and weaknesses of RGB++ in comparison to its predecessor.

Advantages:

• Users are no longer required to store data themselves; CKB takes care of data hosting.
• The majority of the runtime environment’s responsibilities are handled by CKB, allowing users to access the most recent state of the RGB contract directly from the CKB chain without the need to initiate the entire RGB data process each time.
• CKB verifies transactions automatically through Bitcoin lightweight nodes, eliminating the need for users to conduct their own verification.

Disadvantages:

• Transaction privacy is compromised.
• Execution of complex transactions is restricted, as transactions must be processed on CKB. Additionally, transaction fees must be paid based on the complexity of the transactions.
• Extra trust shall be put on CKB chain.

While RGB++ does not wholly retain the advantages of RGB, it does significantly enhance the usability of the protocol by sacrificing some privacy and requiring a degree of additional trust from users.

As a scalability solution for Bitcoin, the advantages and disadvantages of RGB++ are as follows:

Advantages:

• Trust: The CKB chain acts as a public computing engine beneath the Bitcoin chain, taking on the responsibility of verifying and executing the protocol without the need for cross-chain bridges. The additional trust required by the protocol is minimal, allowing users to easily ascertain whether the CKB chain is acting maliciously, with the option to revert to client-side verification if necessary.

Disadvantages:

• The solution does not effectively address the issue of scalability. (The transaction folding proposed in the RGB++ Light Paper can somewhat mitigate this issue; for further information, readers are encouraged to explore the subsequent content.)

For More Details

In this part, we’ll cover aspects of the protocol that are less critical but still worth exploring for those who are curious about the technical intricacies.

Isomorphic Binding

We haven’t delved into the specific architecture of Nervos CKB in the previous sections. Other blockchains, like the Turing-complete EVM-compatible chains, can also achieve similar functionalities. A concise discussion on this topic can be found in the appendix.

The CKB’s ability to act as the RGB computation engine is greatly enhanced by the isomorphic nature of its Cells to Bitcoin(RGB)’s UTXOs. This allows CKB to adopt many designs from the RGB protocol, such as the proof-of-publication mechanism, which helps to prevent state contention and enables RGB computations to be performed offline, reducing reliance on the CKB chain.

Transaction Folding

With RGB++, it’s possible to make a commitment on Bitcoin for multiple CKB transactions instead of just one. This approach can create a ROLLUP-like effect, improving the system’s scalability.

Shared State and Its Security Risks

To boost the contract’s capabilities, RGB++ introduces the concept of “global state cell”. The “Shared State and Unhosted Contracts” white paper by RGB++ explains this feature:

Consider a global state cell on the CKB that manages the state shared by multiple users. Typically, it could be a staking contract for an algorithmic stablecoin, where users deposit volatile assets and receive a deposit proof. The global state is managed by an unhosted contract, meaning anyone can make changes to the state without requiring specific digital signatures from designated signatories. The implementation of an unhosted contract plays a crucial role in the decentralization and censorship resistance of the protocol.

A mediocre implementation in this context means that there is a risk that the Global state Cell is occupied by another user, causing CKB TX fail because the specified Global state utxo does not exist. As the Bitcoin TX needs to be sent out and computed into the commitment before the CKB TX, subsequent validation becomes impossible.

To address the above problem, we introduce the Intent Cell as an intermediary. Users can deterministically write down actions they wish to execute into the Intent Cell, which can interact with the global state Cell through the collaboration of a third-party aggregator, batch processing multiple parties’ intent and merging the results of the interaction into a standard shadow cell.

This approach, however, introduces potential security concerns. The proof-of-publication design in RGB only guarantees a partial order of state transitions, not a total order, which is sufficient for protocol security.

When elements like the global state are introduced, this changes the dynamics, as the revealing order of transactions A and B on different paths can influence the outcome. Consider the following scenario:

1. Both transactions A and B have had their commitments recorded on the BTC chain.
2. The CKB transaction for A has not been recorded due to some issue, such as a censorship attack on the CKB chain.
3. Transaction B has already altered the global state after execution.
4. If transaction A is eventually recorded on CKB, it may yield different results or even fail, potentially leading to asset loss.

The Intent Cell solution presented in the white paper does not fully address this issue. While it ensures that transactions submitted to CKB be executed, it doesn’t guarantee that both the execution result of A and B will be as expected. In the original RGB protocal, as long as the client correctly constructs the state transition and commitment, the contract operates as expected. However, in RGB++, the transaction execution result of the commitment made first on Bitcoin is now controlled by CKB, whereas, downgrading the original “Layer1 security”. Incorporating the global-state cell into RGB might not be a secure choice.

Related Resources

• RGB++ Protocol Light Paper
• RGB++ Contract Specification

Appendix: Discussion on Building an RGB Execution Engine Pseudocode in EVM

We mentioned in the text that a Turing-complete EVM can also serve as the execution engine for the RGB architecture. Below is a pseudocode implementation of a demo contract to deploy an RGB++-like execution engine on an EVM chain.

BTC_STATE is a specially implemented contract that we assume can (via a lightweight node) read confirmed information on the Bitcoin. At the same time, anyone can manually make a transaction’s commitment value public through RGB_CONTRACT’s openCommitment function, using the EVM as the execution engine to execute RGB transactions. Here, we assume that the transaction’s commitment value is submitted to the chain.

// BTC_STATE can read the confirmed state of Bitcoin
contract BTC_STATE {
  struct TXO {
    uint256 btcTxId;
    uint256 outputIndex;
  }
  // a Bitcoin transaction will have at most one OpReturn
  function readBitcoinOpReturn(uint256 btcTxId) returns (bytes);
  // or
  function readBitcoinTransactionOutputScript(TXO txo) returns(bytes);

  function isBitcoinTransactionOutputSpent(TXO txo) returns(boolean);
  // ...
  function readBitcoinOrdinalIndex(TXO txo, uint256 satoshiIndex) returns (uint256);
  // ...
  function readBitcoin...(uint256 btcTxId) returns (bytes);
}
  
contract RGB_CONTRACT {
  struct RGB_DATA {
    TXO input; // could be multiple, only for reference
    TXO output; // could be multiple, only for reference
    bytes payload;
  }
  mapping(uint256 => bytes) utxoStatus;
  mapping(uint256 => boolean) utxoPermission;
  function openCommitment(RGB_DATA calldata data, bytes32 salt) public {
    isValidOpen(data, salt);
    utxoPermission[calcTxoHash(data.input)] = false;
    utxoPermission[calcTxoHash(data.output)] = true;
    execute(data.payload);
  }
  function calcTxoHash(TXO txo) pure returns (uint256);
  function calcCommitment(RGB_DATA calldata data, bytes32 salt) pure returns (bytes32);
  function execute(bytes payload) internal;
  function isValidOpen(RGB_DATA calldata data, bytes32 salt) {
    require(utxoPermission[calcTxoHash(data.input)], "The input utxo should have permission");
    require(
      calcCommitment(data, salt) == BTC_STATE.readBitcoinOpReturn(data.input.btcTxId)
    );
    _;
  }
}