English translation, hope it’s accurate, let me know if anything needs fixing.
Introduction
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.
One-Time Seals
The concept of one-time hermetic seals, first introduced by Peter Todd in 2016, allows you to lock an electronic seal on a message, ensuring that the message can only be used once. Specifically, we can use Bitcoin’s Unspent Transaction Outputs (UTXOs) as seals for messages, and the Bitcoin system’s consensus mechanism ensures that these UTXOs can only be consumed once, meaning that these seals can only be opened once.
The RGB protocol utilizes this one-time seal based on Bitcoin UTXOs to map RGB state changes to ownership of Bitcoin UTXOs. The Bitcoin system thus ensures ownership of the state of RGB, as well as the ability to trace all state changes through the UTXO history. The one-time seal provides the RGB protocol with double-spend-proof security and transaction branch traceability guaranteed by the Bitcoin consensus.
Client-side Authentication
The RGB protocol contains user state that cannot be verified directly by the Bitcoin consensus, and users must use off-chain calculations to ensure that RGB’s state changes are as expected. Client-side validation technology allows users to validate only the UTXO branching history that is relevant to them and not the transaction history that is not relevant to them. RGB’s state security is ensured through client-side validation and does not rely on any centralized third party.
Problems with the RGB Protocol
Despite the many advantages of the RGB protocol, especially its ability to provide Bitcoin with virtually uncompromising contract extensions, there are still several technical and product issues in practice.
DA Issues
How the average user can generate or obtain proof of transaction history. The average user with a simple client-side product does not have the ability or resources to save all historical transactions, and therefore has difficulty providing proof of transactions to counterparties.
P2P Network Issues
RGB transactions, as an extension of Bitcoin, rely on a P2P network for propagation. Users also need to interact with each other when transferring money, and recipients need to provide receipts. These rely on a P2P network that is independent of the Bitcoin network.
Virtual Machines and Contract Languages
The virtual machine for the RGB protocol is currently dominated by AluVM, which, as a new virtual machine, currently lacks well-developed development tools and practice code.
Problems of Masterless Contracts
The RGB protocol does not have a perfect solution for the interaction of no master contract (public contract). This makes multi-party interactions difficult to realize.
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).
RGB++ Transaction Process
Out-of-chain calculations
Select the next one-time seal to be used, e.g. btc_utxo#2
Calculate off-chain and generate an RGB++ transaction to be sent to CKB: CKB_TX_B
Calculate off-chain commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)
BTC Transaction Submission
Generate and send a Bitcoin transaction Bitcoin_TX_A, input consumed btc_utxo#1, output added to above commitment via OP_RETURN
CKB Transaction Submission
Send the above CKB transaction CKB_TX_B
User’s latest state is maintained by CKB_TX_B.output.data
The next change of status requires the use of btc_utxo#2, CKB_TX_B.output.
On-chain validation
Bitcoin validation related utxo can only be spent once by a given user.
There is a light client for Bitcoin on CKB, which can verify that the relevant transactions on Bitcoin exist on the Bitcoin chain.
The relevant transaction on Bitcoin is submitted as a witness to the CKB transaction to assist in the verification
CKB further verifies that the correct utxo was spent on the BTC transaction.
CKB further verifies that the BTC transaction is committed with the correct commitment
CKB verifies that the state transfer on the CKB conforms to the predefined contract rules.
RGB++ Client
Unlike the RGB protocol, all transactions in RGB++ are on CKB and are validated by CKB script constraints, so there is no need for a standalone client for RGB++. Users only need to access Bitcoin and the CKB light client to validate all transactions. The CKB light client also uses the PoW algorithm to validate all historical transactions and state from the nearest block header, which in turn validates all transactions in RGB++ using isomorphic bindings.
Transaction Folding
The RGB++ protocol isomorphically binds the Bitcoin UTXO to the CKB Cell, enabling Turing-complete Bitcoin UTXO transactions supported by CKB Cell validation. If we further utilize the programmability of the CKB Cell, then we can map multiple CKB transactions to a single Bitcoin RGB++ transaction, which allows a low-speed, low-throughput Bitcoin chain to be scaled with a high-performance CKB chain.
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, we 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.
Non-Interactive Transfers
One of the problems with the original RGB protocol is that the payee needs to provide a live utxo as an invoice in order to perform the transfer, which requires the payee to be online in order to complete an ordinary transaction, increasing the difficulty of user understanding and product complexity. RGB++ can take advantage of the Turing-complete environment by placing the interaction behavior in a CKB environment, and adopting a two-step operation of send-receive to implement non-interactive transfer. Receive two-step operation to realize the non-interactive transfer logic.
Send
When user A sends an asset to user B, it only needs to know B’s address and transfer money to that address in the RGB++ transaction, without requiring the recipient to provide a utxo or invoice.
Recieve
The CKB lock contract has the ability to verify the digital signature of the BTC address, so the receiver can construct a Tx C on the CKB to unlock the corresponding CKB Cell and transfer the assets to their utxo#2. This completes the non-interactive collection.
Coins
The issuance of fungible assets on RGB++ requires corresponding data structure standards and consistency verification standards. We can use CKB’s xudt standard as its isomorphic binding protocol.
Issuance
RGB++ coins can be issued in a variety of ways, including but not limited to centralized distribution, airdrops, and subscriptions. The total number of tokens can be either uncapped or pre-capped. For tokens with a preset cap, a state sharing scheme can be used to verify that the total amount of issued tokens is less than or equal to the preset cap at each issuance.
Transfers
The transfer of RGB++ coins is very simple, you only need to assign the payee and the change utxo to the shadow cell of CKB, and the transfer of coins can also be done by collapsing the transactions to CKB only, and then committing the final result to BTC after multiple transactions.
Privacy
xudt is a transparent token protocol, and we can also enhance the privacy-preserving properties of RGB++ coins by employing token protocols that support amount privacy and flow privacy. For example, we can use the bulletproof algorithm to turn the contents of the data into a blinded amount and provide a zero-knowledge proof that the amount is the same and non-negative in each transfer transaction. In this way, only the parties to the transaction know the specific amount information of the current transaction, and a third-party observer cannot obtain the amount data.
In addition, we can use ring signatures to realize the blinding of the transfer flow. The user’s coin is transferred to the ring signature obfuscator on the CKB, and then back to an address managed by bitcoin utxo. In this way, the history of the money flow is cut off, thus accomplishing address privacy.
NFTs
Distribution
RGB++'s NFT asset distribution can also utilize existing NFT protocols on CKB, including but not limited to Spore, mNFT, and CoTA. Spore, for example, keeps all metadata on-chain and achieves 100% security of data availability. The CoTA protocol, on the other hand, utilizes state compression to compress NFT information and holding data in a 32-byte SMT, providing the ultimate cost advantage.
Transfers
The transfer of NFTs in RGB++ is also very simple, similar to a coins transfer with no change.
Lightning Network Connectivity
RGB, as a client-side authentication protocol, naturally supports stateful channels and lightning networks, but it is very difficult to implement non-btc lightning networks on Bitcoin due to its scripting capabilities. By wrapping the RGB++ protocol, we can implement state channels and lightning networks for RGB++ assets based on CKB’s Turing-complete scripting system. This technology has great commercial promise, e.g., a stablecoin payment system based on the Lightning Network can provide cost and performance advantages over centralized systems, while guaranteeing decentralization and censorship resistance.
Application Examples
Airdrop
Given a list of addresses and a list of amounts, we can implement a complete airdrop application using RGB++. Let’s assume that both the pending airdrop data and the list of claimed addresses are stored in cell data as SMT. Users can then collect airdrops from their own addresses.
DEX & AMM
RGB++ utilizes the UTXO structure to directly support UTXO-based asset exchange protocols without the need to introduce intermediaries. The grid order book design also enables an automated market maker model, which is more customizable and suitable for trading UTXO structured assets than Uniswap’s price curve market maker model.
The example above is a seller placing an order for RGB++ xudt and a buyer buying it with Bitcoin. The structure of the transaction is that the buyer provides the buyer’s utxo with sufficient amount of Bitcoin and PBST signature, and the buyer constructs the transaction on the CKB to meet the seller’s requirements, and finally the buyer sends the constructed CKB transaction to the seller, who then uploads the BTC transaction and the CKB transaction one after the other to complete the transaction.
Summary
RGB++ inherits the core idea of the RGB protocol and adopts a different virtual machine and validation scheme. Users don’t need a separate RGB++ client, but only need to access the Bitcoin and CKB light nodes to complete all the validation independently. RGB++ brings Turing-complete contract scaling and dozens of times of performance scaling to Bitcoin. It does not use any cross-chain bridges, but rather a native client-side validation scheme that ensures security and censorship resistance.
