🖇️RGB++

RGB++ is an extended RGB-based protocol that utilizes one-time seals and client-side validation techniques to manage state changes and transaction validation. It maps the Bitcoin UTXO to the Cell of the Nervos CKB via isomorphic bindings, and utilizes scripting constraints on the CKB chain and the Bitcoin chain to validate the correctness of the state computation and the validity of the change ownership.

RGB++ solves the technical problems that the original RGB protocol had in practice, and provides more possibilities, such as blockchain-enhanced client-side validation, transaction folding, shared state and masterless contracts, non-interactive transfers, and more. It brings Turing-complete contract scaling and performance scaling to Bitcoin without the need to cross-chain and without loss of security.

RGB++ isomorphic bindings

RGB++ solves the problems encountered by RGB protocol and gives more possibilities to RGB through isomorphic binding technology. In the RGB protocol, the two most important components are the UTXO for ownership determination and the commitment for state management and one-time sealing, RGB++'s isomorphic binding maps the Bitcoin UTXOs to the cell of the CKB, uses the bitcoin utxo lock for ownership synchronization, and uses the cell’s data and type for state maintenance.

Blockchain Enhanced Client-side Authentication

All RGB++ transactions are synchronized with one transaction each on the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter replaces the client-side validation process, so that the user only needs to check the relevant transaction on the CKB to verify that the state of the RGB++ transaction is calculated correctly.

However, users can also not use the transactions on the CKB chain as the basis for verification, and by utilizing the local historical transaction information of UTXO, users can independently verify the RGB++ transaction from the CKB chain (some functions such as transaction folding still need to rely on the block header hash of CKB to do the anti-double spend verification).

Shared States and Masterless Contracts

A mediocre implementation of shared state.

Shared state has always been a challenge for UTXO systems, so here we discuss a mediocre implementation that does not take into account multiple people updating the shared state at the same time, and then move on to a solution that allows multiple people to manipulate the shared state at the same time, as would be the case in practice.

Consider the existence of a global state cell on the CKB that manages the state shared by multiple users. Typically, it could be a pledge contract for an algorithmic stablecoin, where users deposit volatile assets and receive a certificate of deposit. The global state is managed by a masterless contract, by which we mean that anyone can make changes to the state, subject to the constraints of the contract, without requiring the designated digital signature provider to do so. The implementation of a masterless contract is decisive for 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, so that CKB TX will not hold because the specified Global state utxo does not exist. The Bitcoin TX needs to be sent out and computed into the commitment before the CKB TX, and thus no subsequent validation is possible.

State Contention in Shared State and Solution

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