A More Flexible Binding Scheme for RGB++

English CKB Development & Technical Discussion
1

In the original design of RGB++, both inputs and outputs of ckb_tx are bound by commitments, leading to some issues:

  1. The issue of adjusting ckb_tx fees, which can be resolved by not including the cell used for fee payment.
  2. The issue of chain transactions, where users need to construct CKB transactions offline, then create a commitment and initiate a BTC transaction. They must wait for the BTC transaction to be confirmed on-chain before the CKB transaction can go on-chain, hindering the ability to utilize the chained transaction feature of UTXOs.

Since the “true Inputs” of RGB++ are UTXOs on the BTC network, binding CKB inputs is unnecessary because BTC UTXOs already impose this constraint. Therefore, binding ckb_tx inputs is redundant and can be omitted.

With this premise, the commitment placed in op_return can solely bind outputs.type + outputs. Data. outputs.lock and capacity are also redundant, as each cell’s control lies with its corresponding BTC UTXO. Only outputs related to RGB++ need to be bound within this framework, excluding irrelevant Cells.

However, for outputs jumping from L1 to L2, it’s necessary to add lock to the cell, identifying it as an asset that needs to jump to L2.

For transactions from L2 jumping to L1, maybe it is still necessary to include the required inputs in the commitment?

This design leads to a protocol capable of sending chain transactions and flexibly adjusting fees, while also being somewhat decoupled from CKB. Users can fully validate and utilize this protocol in an off-chain client, replaying the transaction sequence to the CKB mainnet after some time.

When unlocking rgb_lock in a rgb++ tx, the following checks are performed:

  1. Verify that each cell with rgb_lock is bound to a UTXO present in the inputs of the provided BTC tx, and that the btc_tx can be verified via SPV.
  2. Ensure that the RGB++ cells in the outputs match those in the commitment, and that the btc_tx indeed has at least this many outputs.
    3. For each input of the ckb_tx, locate the previous_ckb_tx based on its outpoint, and with the witness providing the previous_btc_tx, check that the inputs of the previous_ckb_tx’s RGB++ cells are bound to the inputs of the previous_btc_tx. after some discussion, this is useless now.

We don’t need to place the preimage of the commitment in the witness, as we can directly read data from the rgb++ transaction itself, concatenate it into a preimage, hash it, and then compare it with the commitment for validation.

For client-side verification, both version and header_dep need to be bound by the commitment.

For cell_dep, the following constraints can be applied:

  1. For cell_deps bound via data_hash, it is acceptable not to impose constraints since their content is fully constrained by the hash.
  2. For upgradable scripts, the decision of which script version to accept should be made by users during client-side verification. Since RGB++ transactions are bound on the BTC network, users can decide to accept only newer versions of scripts from a certain BTC block height. In the event of incompatible hard forks on CKB, this approach can also apply, meaning bindings from a specific BTC height will use the post-hard fork validity criteria.
4 Likes