RGB Review: A Scalable, Confidential Smart Contract Protocol Based on Bitcoin
There is a lot of confusion around the term “smart contract”. It is believed that Vitalik Buterin, the founder of Ethereum, introduced it into circulation. It’s actually authored by researcher Nick Szabo, who in the 1990s defined it as “a set of promises marked in digital form, particularly the protocols under which parties fulfill those promises.”
However, there is a more important question. Do smart contracts exist only in the digital world or outside it too? For the latter will mean the path to a new approach to the functioning of the surrounding world and agreements between people. To understand this, let’s imagine two parties, completely anonymous, but willing to interact with each other. Their task is to exchange goods or services and be sure that the agreement will be fulfilled.
The first and most important problem is how to prove, without disclosing confidential information, that one party really is the owner of the goods that he is selling, and the other is the owner of the money for payment? Part of the answer was already found many years ago by introducing bearer rights. A bearer right is the right to fully own and transfer something held by the owner himself (hence the name “bearer”) on a physical medium (such as a certificate of title).
What is RGB?
An interesting fact about bearer rights is that there is no need to register your ownership of an asset or contract with any third party, public registry or authority – transfer of ownership involves providing physical evidence only to the counterparty, without entering information about it in any public database data. Thus, the concept of bearer rights allows for confidentiality and full ownership of an asset, while maintaining the ability to exchange it with others and verify information about counterparties completely peer-to-peer, without the involvement of third parties or registries.
The second thing we need to consider is: how to enforce the contract? Anonymity means that you do not know who to apply physical pressure to if they cheat. This is where economics comes to the rescue, namely game theory. By creating the right economic incentives to carry out a transaction, you can create a contract that makes it unprofitable for the other party (and yourself) to cheat.
Therefore, it turns out that the term “smart contract” is actually applicable in both the physical and digital world as a way of confirming ownership information and enforcing a certain agreement between parties without an external centralized authority (military, government, judicial, etc.) .) or physical coercion.
Computer science in this case is intended to improve processes and make real and digital interactions between people more effective. But in order to fully comply with the definition, a smart contract system must have the following parameters.
1. Censorship resistance. Grant full ownership of contract data to each party to the contract without the ability for any outside party to take it away.
2. Scalability. The system should be easily scalable to a global level and allow the participation of an unlimited number of parties.
3. Confidentiality. The ability to work in a private environment without revealing your identity or information about assets you may own or agreements you are involved in.
4. Check. Counterparties must be able to verify information about assets, ownership and contract performance independently, without having to trust any third party, authority or registry.
The digital world is replete with various smart contracts, and Bitcoin is one example of such a system. So far, this is the only protocol that is censorship-resistant, while programmability, confidentiality and scalability are not properties that are inherent to it. Ethereum contracts are much more flexible, but they lack censorship resistance, privacy, and scalability. Plus, as a contract participant, you must always delegate data verification to the global community, which means you never truly own anything.
Bitcoin’s performance has been closely watched since its introduction in 2009. Because it can only process seven transactions per second, the network does not allow smart contracts to scale. The SegWit update increased the Bitcoin block size limit to 4 MB (1 MB for transaction data and 3 MB for witness data); however, the limitation still applies. Meanwhile, as Bitcoin’s influence grows, the issue of scalability becomes increasingly relevant and remains one of the main problems of the Bitcoin ecosystem. Today, experts are looking for various approaches to solving it, which primarily include:
- Sidechains, including Liquid, Stacks, Rootstock, etc.;
- State channels such as the Lightning Network, which can process certain high-frequency off-chain transactions;
- Non-updatable scaling solutions such as RGB and Bitcoin Script, which do not change the Bitcoin code;
- Scalable upgrade-based solutions such as Drivechain (BIP300/301), which require strong miner support and achieve scalability through hard forks.
Of the variety of approaches, some early scaling solutions are regaining popularity. In particular, the Nostr protocol, which came to prominence in late 2022, has spurred widespread adoption of the Lightning Network. At the same time, the Ordinals protocol boomed in early 2023.
Today there is only one technology that meets all of the above criteria. This is RGB. In April of this year, RGB released a new version (v0.10) of its solution for smart contracts based on Bitcoin and the Lightning Network, providing Turing completeness, scalability and reliable privacy protection.
RGB is a scalable and private smart contract system that can be considered a layer 2 or layer 3 technology running on top of Bitcoin. RGB leverages the strengths of Bitcoin and Lightning while extending their functionality to amazing levels.
RGB makes it possible to separate many different types of property rights, such as the right to own, use, transfer, modify, sell, etc., from contract states (the conditions under which a contract exists at a particular unit of time), evidence, and contract evolution. An RGB contract can be said to define an “if-then” event-consequence algorithm with an obligation to comply with verification rules at every step. How was this achieved?
RGB relies on several breakthroughs, namely the concept of clientside validation, single use seals, and the use of zero-knowledge proofs. And it all runs on the Lightning Network, meaning transactions happen quickly, providing tools for complete ownership and management of property rights. All this functionality is available without a new blockchain or Bitcoin fork, without littering the L1 chain and without protocol-level tokens. What actions and decisions led to this?
RGB Evolution
The origins of RGB can be traced back to 2016, when Peter Todd came up with the idea of Single-use-seal and client-side validation. Based on these essential concepts, the RGB project was proposed in 2018. The RGB story began in 2016 with the idea of Giacomo Zucco to make more attractive Colored coins and connect them with the Lightning Network. This is where the name RGB comes from – this is one of the most famous color palettes. A few years later, Dr. Maxim Orlovsky from Pandora saw potential in the technology far beyond the use of tokens and joined the initiative. To create a completely free, free and open technology set containing the core values of cyberpunk, a Swiss non-profit organization called the LNP/BP Standards Association has launched. Active development has begun.
Until the spring of 2021, RGB evolved from an idea for a token protocol into a full-fledged private and scalable smart contract system on Bitcoin, finally offering a solution to complex problems and strengthening the Bitcoin ecosystem. In April 2023, after lengthy development, RGB introduced version v0.10.
RGB Structure
Below is an RGB structure that provides scalability and privacy:
Client-side Validation
Most existing public blockchains operate under a global consensus model, in which all nodes verify all transactions, share transaction information with each other, and maintain a single global state.
However, this model poses a number of problems, including:
- Scalability limitations that make it more expensive to verify all contract interactions;
- High costs leading to centralized operation of nodes;
- Lack of confidentiality due to openness of transaction information.
Client-side verification (CSV) offers an alternative approach: it requires the consensus layer to only fulfill the cryptographic obligations associated with events in the ledger, while the event information itself (the ledger) is stored off-chain. This approach comes from the work of Peter Todd, which he calls “Client-Side Validation”. CSV moves transaction data off-chain, where detailed information is stored and verified, and only minimal information is transferred to the blockchain. Additionally, transaction data is transferred off-chain only between the sender and the recipient. For example, in a real transaction, verification is only required when the wallet and parties request access to contract data.
CSV Key Features
- Transaction details are stored off-chain and verified only on the client;
- Only transaction data obligations are stored on the chain;
- Validation only applies to transactions that the user should be aware of.
The verification mechanism for asset transfers in RGB is significantly different from the verification mechanism in Bitcoin. In the Bitcoin network, nodes continuously download and validate blocks and transactions in the mempool, allowing them to obtain the latest state of the UTXO set. When a new transaction appears, Bitcoin validators check the validity of its history by checking the existence of all inputs in the most recent set of UTXOs.
RGB, on the other hand, does not rely on the global network broadcast of all transactions to create the equivalent of Bitcoin’s UTXO set. This means that when receiving an incoming payment, the RGB client must not only verify the validity of the last state transition, but must also perform a check for all previous state transitions back to the initial state in the issuing contract. This bottom-up verification of RGB transaction history protects against double-spending attacks.
RGB improves scalability by checking only relevant transactions. However, this approach can lead to problems associated with insufficient data availability, which may require data sharing to optimize payment verification.
BTC Based Single-use-seal
Physical disposable seals or seals are plastic seals with a unique number that are typically used to detect unauthorized access during storage and transportation. For example, they can determine whether the door of a shipping container was opened during transport. Digital one-time seals digitally seal a message and ensure it can only be used once, preventing the same asset from being sold multiple times.
Instead of using a proxy to confirm the opening and closing of digital seals, unspent Transaction Outputs (UTXOs) can be used as seals. A UTXO can be thought of as a seal that closes when created and opens when spent. According to Bitcoin consensus rules, a withdrawal can only be spent once, therefore a seal can only be opened once. Thus, one-time seals are used to bind Bitcoin UTXOs to off-chain contract states, allowing transition to the next state through off-chain RGB transactions (closing the seal). Similar to the physical one-time seals used to secure shipping containers, the digital one-time seal is a unique object that precisely seals a piece of information to prevent double spending.
To give a simple analogy, we can think of a UTXO as a series of checks, each with a different amount. When you make a payment, you are essentially paying someone with uncashed check. Moreover, any balance on the check will be returned to you in the form of a new check. In this case, one-time stamps add specific transfer entries to the additional information field of the check. Since a check can only be cashed once, this approach avoids double spending.
Let’s see how this process works for Alice, Bob and Dave:
1. To begin, Alice issued an RGB asset (such as USDT Tether or USDT) for a total amount of 100 million and added the liability information to the valid check (Check A) in the additional information field. The receipt printer does not need to take this additional information into account, and check A can have any face value as long as it belongs to Alice and remains uncashed.
2. When Alice wants to transfer 10 million USDT to Bob, she needs to cash check A and indicate in the additional information field that 10 million USDT will go to a new check (check B) belonging to Bob, and 90 million USDT will go to another new check (check C), owned by Alice, which contains the remaining 90 million USDT.
3. If Bob wants to transfer 10 million USDT to Dave, he needs to cash check B and note in the additional information field that 10 million USDT will go to a new check (check D) belonging to Dave.
4. A similar process is repeated for each subsequent transfer. Specifically, the previous holder transfers part of the amount to the new recipient, and the recipient then checks the entire history of the transfer of assets. Similar to checks in circulation, each transfer creates a new check and each check can only be cashed once (UTXO). Meanwhile, old checks (UTXO) become invalid, ensuring that the state can only move forward and not backward, which also prevents double spending. Thus, records on the chain reliably reflect changes in the state of the crypto asset.
RGB uses the Bitcoin-based one-shot model described above, that is, when an RGB transaction is made, the sender creates a contract state transition that defines the rights being transferred. Let’s consider the case with tokens. First, the issuer of the contract sets an initial state, which defines the details of the contract, such as the asset name, the total supply, and the UTXO with the right to move the supply. Then, when the assets are first transferred, the owner of the first UTXO can create a state transition that determines which new UTXO will now own the asset. RGB achieves state transitions using a mechanism whereby UTXOs can only be spent once, allowing crypto asset transfers and ownership changes to be reliably detected and tracked.
RGB stores all transaction information outside the Bitcoin network, transferring it exclusively between senders and recipients. At the same time, data on obligations is tied to Bitcoin UTXO. Once a UTXO is spent, it cannot be spent again in the same way, indicating that a contract change has occurred.
RGB uses the Bitcoin blockchain to protect against double spending, which is achieved by capturing each RGB state transition within a Bitcoin transaction that spends 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 committed once (otherwise it will result in double spending).
To include multiple state transitions in a single commitment, state transitions are aggregated multiple times and then passed into a Bitcoin transaction via Taproot or OP_RETURN. If there are multiple commitments in a Bitcoin transaction, only the first one will matter to the RGB validation rules and the rest will be ignored, preventing any attempt at double spending.
RGB Key Characteristics
Scalability
- Compared to alternative protocols that keep all logic on-chain, CSV stores data off-chain, which reduces cost and computational load;
- RGB is available directly on Bitcoin without the need for code modification or complex on-chain transactions;
- RGB supports Lightning Network.
Confidentiality
- Third parties cannot see RGB transactions and associated one-time stamps;
- RGB uses blinded UTXOs. A blind UTXO consists of a hash after splicing the UTXO and a random blinding secret. This way, the sender doesn’t know where the assets went, and the new recipient can only verify the blind UTXO when he spends the asset;
- RGB also uses a zero-knowledge mechanism called Bulletproof. Under this mechanism, asset owners will be able to see all UTXOs that previously owned the asset, but they will not be able to see the amount of the asset transferred at each state transition.
Variety of Functions and Use cases for RGB
Scheme
Issuers can use RGB schemes, which act as contract templates designed for specific use cases. Here are some examples:
- Release of interchangeable RGB20 assets
- Release of RGB21 non-fungible assets
- Decentralized RGB22 digital identifiers
- Verifiable unique history log for verifiable RGB23 data
- Decentralized Global Domain Name System RGB24
- Release of RGB25 collectible assets
- Anyone can design their own circuit for various applications without asking permission from RGB developers. However, it is assumed that most use cases can be covered by a few basic patterns.
AluVM
RGB uses AluVM, a custom-designed register-based RISC virtual machine. AluVM is Turing complete and can manage global state with the same availability guarantees as existing blockchain-based systems. Similar to EVM, AluVM has an architecture where the RGB node is hosted on top of the Lightning Network and the RGB client is hosted on the RGB nodes.
How RGB remains fully compatible with the Lightning Network
RGB can interact with the Lightning Network through the Bifrost extension to achieve near-instant settlement without waiting for new Bitcoin blocks to be mined. By connecting token-specific payment channels to the Lightning Network, RGB assets can provide the same user experience and security prerequisites as regular payments on the Lightning Network. This enables low-cost, fast and stable payments and can benefit the entire ecosystem, including users, developers and Lightning node operators.
RGB vs TARO
TARO (now Taproot Assets), the Taro protocol supported 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. Since they have a similar design, some even claim that TARO took inspiration from RGB. However, they focus on different aspects: TARO focuses 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 requiring modifications to the underlying Bitcoin layer.
The Ordinals protocol captures all data on the blockchain, while RGB only stores the obligations of that data on the chain. Given the security provided by UTXO, RGB takes up minimal on-chain space, allowing for seamless integration with the Lightning Network.
RGB vs rollups
Rollup is an Ethereum scaling solution that allows users to deposit funds into Ethereum smart contracts and then transact with other users in the same rollup. These transactions are regularly aggregated and transmitted to the blockchain. Additionally, RGB is not an independent blockchain.
RGB Issues
The RGB ecosystem is in its infancy. While the infrastructure already exists, the ecosystem only offers a few basic applications and it may take some time to expand the developer toolkit and user base.
RGB clients store huge amounts of data, and spending will become impossible if off-chain verification data is lost. Thus, it is necessary to store not only the key. Additionally, unlike Bitcoin and other global consensus systems, RGB clients do not need to see and confirm all transactions on a global scale. Instead, they must only confirm transactions that are associated with their wallets. This significantly reduces the amount of data that each client must verify, increasing the scalability of the overall system. While verifying massive data when receiving payments may seem problematic since slow verification means slow transactions, it only becomes a problem when there is a long transaction history. When this happens, new levels of data availability will be required that allow clients to voluntarily share state transition data for specific contracts so that future recipients can start auditing part of the transaction history in advance.
For popular CSV tokens, widespread adoption may result in higher validation costs.
RGB is developed by the community and relies on extensive team research, which means slow progress and limited market penetration.
Developer learning curve: In addition to knowing about Bitcoin, developers must also learn state transitions and RGB contracts.