Background

Bitcoin’s performance has been closely watched since the crypto was launched in 2009. As it can process only seven transactions per second, the network does not allow for scalable smart contracts. The SegWit upgrade increased Bitcoin’s block size limit to 4MB (1MB for transaction data and 3MB for witness data); however, the limitation still persists. Meanwhile, as Bitcoin’s influence grows, the scalability challenge has become more acute. Scalability remains a fundamental challenge facing the Bitcoin ecosystem. Today, practitioners are exploring solutions with different approaches, which primarily include:

Sidechains including Liquid, Stacks, Rootstock, etc.;
State channels like the Lightning Network that process certain highly frequent transactions off-chain;
Non-upgradeable scaling solutions such as RGB and Bitcoin Script that do not modify Bitcoin’s code;
Upgrade-based scaling solutions including Drivechain (BIP300/301) that require strong miner support and achieve scalability through hard forks.

Of the different approaches, some early scaling solutions are regaining attention. Notably, Nostr, a protocol that went viral in late 2022, contributed to the widespread adoption of the Lightning Network. At the same time, Ordinals boomed in early 2023. As a smart contract solution based on Bitcoin and the Lightning Network offering Turing completeness, scalability, and strong privacy protection, RGB released a new version (v0.10) this April.

RGB’s Evolution

The genesis of RGB can be traced back to 2016, when Peter Todd introduced the notion of single-use seal and client-side validation. Built upon these critical concepts, RGB was proposed in 2018.

In 2019, Orlovsky, a core RGB developer, spearheaded the development of RGB and created many components that ultimately constitute the RGB protocol. Additionally, the establishment of the LNP/BP Association in Switzerland helped provide the relevant standards.

Following extensive development efforts, RGB unveiled its v0.10 release in April 2023.

About RGB’s Design

This is how RGB achieves scalability and confidentiality:

Client-Side Validation

Most existing public blockchains operate under a global consensus model, where all nodes validate all transactions, share transaction information with each other, and maintain a unified global state.

However, this model brings forth several challenges, including:

Scalability limitations that make it expensive to validate all contract interactions;
High costs leading to centralized node operation;
Lack of privacy due to open transaction information.

Client-Side Validation (CSV) proposes an alternative approach: It only requires the consensus layer to fulfill cryptographic commitments associated with ledger events, while storing actual event information (the ledger) off the blockchain. This approach, which originates from the work of Peter Todd, is termed “Client-Side Validation”. CSV shifts transaction data off-chain, where detailed information is stored and verified, and only minimal information is submitted on the blockchain. Furthermore, transaction data is transferred off-chain only between the sender and the receiver. For instance, in a real-world transaction, validation is required only when the wallet and the parties ask for access to contract data.

Key features of CSV:

Detailed transaction information is stored off-chain and validated only on the client;
Only commitments to the transaction data are stored on the chain;
Validation only applies to transactions that users must be aware of.

In RGB, the validation mechanism for asset transfers significantly differs from that of Bitcoin. In the Bitcoin network, nodes are always downloading and validating blocks and mempool transactions, which allows them to acquire the latest state of the UTXO set. Upon encountering a new transaction, Bitcoin validators check the validity of its history by verifying whether all the inputs exist in the most current UTXO set.

RGB, on the other hand, does not rely on a global network broadcast of all transactions to create an equivalent of the Bitcoin UTXO set. This means that while receiving an incoming payment, an RGB client not only has to verify that the last state transition is valid, but also needs to perform the same validation for all previous state transitions up the genesis state in the issuance contract. This bottom-up validation of transaction history in RGB also safeguards against double-spending attacks.

RGB improves scalability by only validating transactions that are relevant. However, this approach might result in problems associated with poor data availability, which may require data sharing to optimize payment validation.

Bitcoin-based Single-use Seals

Physical single-use seals are uniquely numbered plastic ties commonly used to detect tampering during storage and shipment. For instance, it lets us know if the door of a shipping container was opened during shipping. Digital single-use seals close a digital seal over a message to make sure that it can be used only once, which makes it impossible for sellers to sell the same property twice.

Instead of using a trusted entity to certify the opening and closing of digital seals, it is possible to use Bitcoin’s Unspent Transaction Outputs (UTXOs) as seals. A UTXO can be seen as a seal that is closed when it is created and opened when it is spent. In light of Bitcoin’s consensus rules, an output can be spent only once; therefore, the seal can be opened only once. In this way, single-use seals are used to associate Bitcoin’s UTXOs with off-chain contract states, enabling the execution of the next state transition through off-chain RGB transactions (closing the seal). Similar to the physical single-use seals used to secure shipping containers, a digital single-use seal is a unique object that accurately seals a piece of information to prevent double-spending.

Here’s a simple analogy: We can think of UTXOs as a series of checks, each of which comes with a different amount. When making a payment, you are essentially paying someone with an uncashed check. Moreover, any remaining balance of the check will go back to you in the form of a new check. In this scenario, single-use seals add certain transfer records to the additional information box of the check. As a check can only be cashed once, this approach prevents double-spending.

Let’s see how this process works among Alice, Bob, and Dave:

For starters, Alice has issued an RGB asset (e.g., USDT Tether or USDT) with a total supply of 100 million, and added the commitment information to a valid check (Check A) in the additional information box. The check printer does not have to consider this additional information, and Check A can have any face value, as long as it belongs to Alice and remains uncashed.
When Alice wants to transfer 10 million USDT to Bob, she needs to cash Check A and indicate in the additional information box that 10 million USDT will go to a new check (Check B) owned by Bob and 90 million USDT will go to another new check (Check C) owned by Alice, which contains the remaining 90 million USDT.
If Bob wishes to transfer 10 million USDT to Dave, he needs to cash Check B and note in the additional information box that 10 million USDT will go to a new check (Check D) owned by Dave.
The same process is repeated for each subsequent transfer. More specifically, the previous holder endorses a portion of the amount to the new receiver, and the receiver then verifies the entire history of asset transfers. Similar to circulating checks, each transfer creates a new check, and each check can only be cashed once (UTXO). Meanwhile, old checks (UTXOs) become invalid, making sure that the state can only move forward and not backward, which also prevents double-spending. This way, the on-chain records reliably reflect the state changes of a crypto asset.

RGB uses the Bitcoin-based single-use-seal model described above, meaning that when an RGB transaction occurs, the sender creates a state transition of the contract defining the rights being transferred. Let’s take the case of tokens. First, the issuer of a contract sets the genesis state which defines the contract details, such as asset name, total supply, and UTXO with the right to move the supply. Then, as the assets are first transferred, the owner of the first UTXO can create a state transition that defines which new UTXO will now own the asset. RGB achieves state transitions by leveraging the mechanism that UTXOs can only be spent once, which allows it to reliably define and track the transfer of crypto assets and the changes in ownership rights.

RGB keeps all transaction information off the Bitcoin network, transferring them exclusively between senders and receivers. Meanwhile, the commitment data is anchored to Bitcoin UTXOs. Once a UTXO is spent, it cannot be spent in the same manner again, signifying a change in the contract.

RGB leverages the Bitcoin blockchain for protection from double spending, and this is achieved by committing each RGB state transition inside the Bitcoin transaction spending the UTXO that owns the rights being moved. Multiple state transitions can be included in a single Bitcoin transaction, but each state transition can only be submitted once (otherwise double spending would be possible).To enable having several state transitions in one commitment, the state transitions are aggregated multiple times and then submitted to the Bitcoin transaction through Taproot or OP_RETURN. If multiple commitments exist in a Bitcoin transaction, only the first one will be relevant for RGB validation rules, and the others will be ignored, making any attempt to double spend pointless.Key Features of RGB

Scalability

Compared to alternative protocols that keep all the logic on-chain, CSV keeps data off-chain, reducing costs and computational strain;
RGB is readily available on Bitcoin, without the need for code modification or complex on-chain transactions;
RGB supports the Lightning Network.

Privacy

Third parties cannot observe RGB transactions or their single-use seals;
RGB features blinded UTXOs. A blinded UTXO consists of the hash of the concatenation between the UTXO and a random blinding secret. In this way, the sender does not know where the assets went, and the new receiver can only validate the blinded UTXO when the receiver spends the asset;
RGB also uses a zero-knowledge mechanism called Bulletproof. Under this mechanism, asset owners will be able to see all the UTXOs that previously owned an asset, but they will not be able to see the amount of asset transferred in each state transition.

RGB’s Versatile Functions and Use Cases

Schemas

Issuers can use RGB schemas, which act as templates of contracts that can be used to target specific use cases.

Here are some examples:

RGB20 fungible assets issuance
RGB21 non-fungible assets issuance
RGB22 decentralized digital identities
RGB23 verifiable-unique history log for auditable data
RGB24 decentralized global domain name system
RGB25 collectible assets issuance

Anyone is free to develop their own schema for different applications without having to ask for permission from RGB developers. However, it is expected that most use cases can be covered by a few main schemas.

AluVM

RGB employs AluVM, a specially designed register-based RISC virtual machine. AluVM is Turing-complete and can operate the global state with the same availability guarantees as existing blockchain-based systems. Similar to EVM, AluVM features an architecture that nests an RGB node on top of the Lightning Network, housing an RGB client on RGB nodes.

Fully Compatible with the Lightning Network

By linking payment channels of specific tokens to the Lightning Network, RGB assets can deliver the same user experience and security assumptions as regular Lightning Network payments. This ensures low-cost, fast, and stable payments and may benefit the entire ecosystem, including users, developers, and Lightning node operators.

Comparison with Other Solutions

RGB VS TARO

TARO (now Taproot Assets), a Taro protocol backed by Taproot, was introduced by Lightning Labs in April 2022 after it raised $70 million in Series B funding.

Both RGB and TARO are built on CSV. As the two share similar designs, some even argue that TARO drew inspiration from RGB. However, it now seems that they focus on different aspects: TARO concentrates on tokens, while RGB aims to implement smart contract functions.

Comparison with Other Bitcoin Solutions

Unlike Drivechain, which is based on BIP300 and BIP301 and requires hard forks, RGB is compatible with existing Bitcoin technology and potential future soft forks, without the need for modifications at Bitcoin’s base layer.

Ordinals commits all data to the blockchain, while RGB only keeps the data commitments on the chain. Given the security provided by UTXOs, RGB consumes minimal on-chain space, enabling seamless integration with the Lightning Network.

RGB VS Rollup

Rollup is an Ethereum scaling solution that enables users to deposit funds into Ethereum’s smart contracts and then transact with other users in the same Rollup. These transactions are periodically aggregated and submitted to the blockchain.

Additionally, RGB is not an independent blockchain.ChallengesThe RGB ecosystem remains in its infancy. Although the infrastructure is already in place, the ecosystem only offers a handful of basic applications, and it may take a while for RGB to expand its developer tools and user base.
RGB clients store massive data, and spending would be impossible if the off-chain data for validation is lost. As such, it is not just the key that must be stored. Furthermore, unlike Bitcoin and other global consensus systems, RGB clients do not need to see or validate all transactions globally. Instead, they only have to validate transactions that are related to their wallets. This significantly reduces the data each client must validate, making the entire system more scalable. Though validating massive data upon receiving payments may seem problematic because slow validation means slow transactions, it only becomes an issue when the transaction history is lengthy. When that happens, new data availability layers will be needed, which will allow clients to voluntarily share the state transition data of specific contracts. In this way, future receivers can start validating part of the transaction history in advance.
For popular CSV tokens, extensive adoption may raise the validation cost.
RGB is community-driven development and relies on diligent team research, which means slow progress and limited market promotions.

Developer learning curve: In addition to Bitcoin knowledge, developers also have to stay informed about RGB’s state transitions and contracts.

Ecosystem Projects

DIBA

Website: https://diba.io/

DIBA is a Bitcoin NFT marketplace using RGB Smart Contract Protocol.

Cosminmart

Website: https://www.cosminmart.com/

Cosminmart is an ecosystem based on the RGB protocol and offers functions including wallet, market, Launchpad, and browser.

Mycitadel

Website: https://mycitadel.io/

Mycitadel features a wide range of functions, including multi-signature, time-locked spending conditions, Taproot, etc.

Bitmask

Website: https://bitmask.app/

Bitmask is a wallet extension.

About CoinEx

Established in 2017, CoinEx is a global cryptocurrency exchange committed to making crypto trading easier. The platform provides a range of services, including spot and margin trading, futures, swaps, automated market maker (AMM), and financial management services for over 5 million users across 200+ countries and regions. Founded with the initial intention of creating an equal and respectful cryptocurrency environment, CoinEx is dedicated to dismantling traditional finance barriers by offering easy-to-use products and services to make crypto trading accessible for everyone.

References

https://hackernoon.com/top-4-directions-of-bitcoin-ecosystem-scalability

https://docs.rgb.info/

https://github.com/RGB-WG/blackpaper/blob/master/README.md

https://docs.lightning.engineering/the-lightning-network/taproot-assets

https://docsend.com/view/he8x9erkjmphphvn

A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin