Translated from RGB++ Protocol Light Paper
Introduction
RGB++ is an extension protocol based on RGB, utilizing single-use seals and client-side validation technology to manage state changes and transaction verification. It maps Bitcoin UTXOs to Nervos CKB Cells via isomorphic bindings and uses script constraints on the CKB and Bitcoin chains to verify the correctness of state computation and the validity of ownership changes.
RGB++ addresses the technical challenges faced by the original RGB protocol in practical implementation and provides more possibilities, such as blockchain-enhanced client validation, transaction folding, shared states with ownerless contracts, and non-interactive transfers. It brings Turing-complete contract extensions and performance enhancements to Bitcoin without the need for cross-chain transfers or compromising security.
Single-use Seals
The concept of single use seals was first proposed by Peter Todd in July 2016, allowing you to lock a message with an electronic seal, 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 consensus mechanism of the Bitcoin system ensures that these UTXOs can only be spent once, meaning these seals can only be opened once.
The RGB protocol utilizes this single use seal based on Bitcoin UTXOs to correspond RGB state changes with the ownership of Bitcoin UTXOs. Therefore, the Bitcoin system ensures the ownership of RGB states and can trace all state changes through the UTXO history. Single-use seals provide RGB protocol with security against double spending guaranteed by Bitcoin consensus and the ability to trace transaction branches.
Client-Side Validation
The user states included in the RGB protocol cannot be directly verified by Bitcoin consensus, and users must ensure that RGB state changes meet expectations through off-chain computation. Client-side validation technology allows users to only verify the branch history of UTXOs relevant to them, without concern for transaction histories unrelated to them. The security of RGB states is ensured through client-side validation, independent of any centralized third party.
Issues with the RGB Protocol
Despite the many advantages of the RGB protocol, particularly its ability to provide almost uncompromised contract extensions for Bitcoin, there are still several technical and product issues in practical applications.
DA Issues
How ordinary users generate or obtain proofs of transaction history?
When ordinary users use simple client products, they do not have the ability or resources to save all transaction histories, making it difficult to provide transaction proofs to transaction counterparts.
P2P Network Issues
RGB transactions, as an extension of Bitcoin transactions, rely on a P2P network for propagation. When users conduct transfer transactions, they also need to interact, and the receiving party needs to provide a receipt. All of these depend on a P2P network independent of the Bitcoin network.
Virtual Machine and Contract Languages
The virtual machine of the RGB protocol currently mainly adopts AluVM, as a new virtual machine, which currently lacks mature development tools and practical code.
Ownerless Contract Issues
The RGB protocol currently lacks a perfect interactive solution for ownerless (public) contracts. This makes it difficult to implement multi-party interactions.
RGB++ Isomorphic Binding
RGB++ solves the problems encountered by the RGB protocol through isomorphic binding technology and endows RGB with more possibilities.
In the RGB protocol, the two most important components are UTXOs used for ownership identification and commitments used for state management and one-time sealing. RGB++'s isomorphic binding maps Bitcoin UTXOs one-to-one to CKB Cells, synchronizes ownership using bitcoin utxo lock, and maintains state using cell data and type.
Blockchain-Enhanced Client Validation
All RGB++ transactions will appear on both the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter replaces the client validation process. Users only need to check the relevant transactions on CKB to verify whether the state calculation of this RGB++ transaction is correct. However, users can also independently verify RGB++ transactions without using transactions on the CKB chain, using local historical transaction information of UTXOs. (Some functions such as transaction folding still rely on the block header hash of CKB for double spending verification.)
RGB++ Transaction Process
1. Off-Chain Computation
- Select the next one-time seal to be used, for example,
btc_utxo#2 - Off-chain computation and generate an RGB++ transaction to be sent to CKB:
CKB_TX_B - Off-chain computation
commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)
2. BTC Transaction Submission
- Generate and send a Bitcoin transaction Bitcoin_TX_A, consume
btc_utxo#1as input, and output the commitment added by OP_RETURN above.
3. CKB Transaction Submission
- Send the above CKB transaction CKB_TX_B
- The user’s latest state is maintained by
CKB_TX_B.output.data - The next change in state requires using
btc_utxo#2,CKB_TX_B.output
4. On-Chain Verification
-
Bitcoin verifies that the relevant utxo can only be spent by the specified user
-
There is a Bitcoin light client on CKB, which can verify the relevant transactions on Bitcoin on the Bitcoin chain
-
Bitcoin’s relevant transactions are submitted as witnesses of the ckb transaction to assist in verification
-
CKB further verifies that the btc transaction spent the correct utxo
-
CKB further verifies that the btc transaction promised the correct commitment
-
CKB verifies that the state transition on CKB complies with the prescribed contract rules
RGB++ Client
Unlike the RGB protocol, all transactions of RGB++ are on CKB and verified by CKB script constraints. Therefore, RGB++ does not require an independent client. Users only need to access Bitcoin and CKB light clients to verify all transactions independently. The CKB light client also uses the PoW algorithm to verify that only a few recent block headers are needed to verify all historical transactions and states, and then use isomorphic binding to verify all RGB++ transactions.
Transaction Folding
The RGB++ protocol binds Bitcoin UTXOs to CKB Cells, realizing Turing-complete Bitcoin UTXO transactions supported by CKB Cell validation. If we further utilize the programmable capabilities of CKB Cells, we can correspond multiple CKB transactions to a single Bitcoin RGB++ transaction, thereby using the high-performance CKB chain to expand the low-speed and low-throughput Bitcoin chain.
Shared States and Ownerless Contracts
Simple Implementation of Shared States
Shared states have always been a challenge in UTXO systems. Here, we first discuss a simple implementation that does not consider multiple users simultaneously updating shared states, and then further discuss the solution that allows multiple users to operate shared states simultaneously.
Consider a global state Cell on CKB for managing shared states among multiple users. Typically, it can be a collateral contract for an algorithmic stablecoin, where users deposit volatile assets and receive a deposit certificate. The global state is managed by an ownerless contract, which means that anyone can change the state without requiring a specified digital signature provider to make changes. The implementation of the ownerless contract has a decisive role in the decentralization and censorship resistance of the protocol.
The simple implementation here refers to the risk of the Global-state cell being occupied by other users, so that the CKB TX cannot be established due to the absence of the specified Global state utxo. And Bitcoin TX needs to be sent before CKB TX, and it is calculated into the commitment, so subsequent verification cannot be performed.
State Contention Issues and Solutions
To solve the above problems, we introduce Intent Cells as intermediaries. Users deterministically write the actions they want to execute into Intent Cells, which can then interact with the global state Cell through the cooperation of third-party aggregators, batch calculate the intents of multiple parties, and merge the interaction results onto standard shadow cells.
Non-Interactive Transfers
One problem with the original RGB protocol is that the recipient needs to provide their own live utxo as an invoice to execute the transfer. This method requires the recipient to be online to complete a regular transaction, increasing user understanding difficulty and product complexity. RGB++ can take advantage of the Turing-complete environment by placing interactive behaviors within the ckb environment, implementing non-interactive transfer logic using a send-receive two-step operation.
Send
When user A sends assets to user B, they only need to know B’s address and transfer to that address in the RGB++ transaction, without the need for the recipient to provide a utxo or invoice.
Claim
CKB’s lock contract has the ability to verify the digital signature corresponding to the btc address, so the recipient can construct Tx C on CKB to unlock the corresponding CKB Cell and transfer the assets to their own utxo#2. This completes non-interactive receipt.
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
There are many ways to issue RGB++ coins, including but not limited to centralized distribution, airdrops, subscriptions, etc. The total amount of tokens can also choose between no upper limit and a preset upper limit. For tokens with a preset upper limit, the status sharing scheme can be used to verify that the issued total is less than or equal to the preset upper limit each time.
Transfer
The transfer of RGB++ coins is very simple, only requiring the recipient and change utxos to correspond to the shadow cell on ckb. The transfer of coins can also be done by folding transactions only on CKB, committing the final result to BTC after multiple transactions.
Privacy
xudt is a transparent token protocol, and we can also adopt a token protocol that supports amount privacy and flow privacy to strengthen the privacy protection features of RGB++ coins. For example, we can use bulletproof algorithm to blind the amount in the data into blinded amounts, and provide zero-knowledge proofs of consistent and non-negative amounts in each transfer transaction. In this way, only the parties to the transaction know the specific amount information of the current transaction, and third-party observers cannot obtain the amount data.
In addition, we can use ring signatures to blind the transfer flow. Users’ coins are transferred to a ring signature mixer on CKB, and then flow back to the address managed by the bitcoin utxo. This cuts off the historical trajectory of funds flow, thereby completing address privacy protection.
NFTs
Issuance
The issuance of NFT assets on RGB++ can also leverage existing NFT protocols on ckb, including but not limited to Spore, mNFT, and CoTA protocols. Taking Spore as an example, it preserves all metadata on-chain, achieving 100% safety of data availability. The CoTA protocol utilizes state compression technology to compress NFT information and holding data into a 32-byte SMT, providing extreme cost advantages.
Transfer
The transfer of NFTs in RGB++ is also very simple, similar to the transfer of coins without change.
Lightning Network Interconnection
As a client verification protocol, RGB naturally supports state channels and lightning networks, but limited by the script computing power of Bitcoin, it is very difficult to implement non-BTC lightning networks on Bitcoin. Through the packaging of the RGB++ protocol, we can use the Turing-complete script system of CKB to realize the state channels and lightning networks of RGB++ assets based on CKB. This technology has tremendous commercial prospects. For example, a stablecoin payment system based on the lightning network can provide cost and performance advantages lower than centralized systems, while guaranteeing decentralization and censorship resistance.
Application Examples
Airdrop
Given a list of addresses and amounts, we can use RGB++ to implement a complete airdrop application. We assume that both the pending airdrop data and the list of claimed addresses are saved as information in the SMT cell data. Users can claim airdrops through their own addresses.
DEX & AMM
RGB++ can directly support UTXO-based asset exchange protocols without intermediaries. At the same time, using a grid order book design can realize an automated market maker model. Unlike the price curve market maker model of Uniswap, the grid market maker model can be more customizable and suitable for asset transactions based on UTXO structure.
The example above is a seller placing an order for RGB++ xudt, and the buyer using Bitcoin to purchase. The transaction structure involves the buyer providing a utxo containing sufficient Bitcoin and providing a PBST signature, and then the buyer constructs a transaction on CKB to meet the seller’s requirements. Finally, the buyer sends the constructed CKB transaction to the seller, and the seller completes the transaction by sequentially submitting the BTC transaction and the CKB transaction to the chain.
Conclusion
RGB++ inherits the core ideas of the RGB protocol, adopts different virtual machines and verification schemes, users do not need an independent RGB++ client, and only need to access Bitcoin and CKB light nodes to independently complete all verifications. RGB++ brings Turing-complete contract extensions and tens of times performance improvements to Bitcoin. It does not use any cross-chain bridges, but instead uses native client verification solutions to ensure security and censorship resistance.