Author: Ajian

This article attempts to provide a concise description of the asset issuance protocol RGB on Bitcoin (which can also be understood as an off-chain smart contract system) and highlights its differences from other protocols that aim to achieve similar functions. These differences make RGB protocol far more scalable and leave more room for programming. In addition to introducing the completed design of RGB, we will also explore these programming possibilities.

What is the RGB Protocol?

The idea of issuing assets on Bitcoin has long existed. However, the Bitcoin protocol has its own characteristics: its state is expressed solely by Bitcoin UTXOs (Unspent Transaction Outputs); a UTXO carries only two pieces of data: its own value (Bitcoin amount) and a “script public key” (also known as a “locking script”) used to program the spending conditions for this fund, for example, providing a signature of a certain public key. The operation codes allowed to program the locking script are provided by Bitcoin’s consensus rules and cannot be used to implement arbitrary security rules. Therefore, it is not possible to create other assets within UTXOs – Bitcoin scripts cannot program the security checks for these assets. This means that all ideas for issuing assets on Bitcoin are essentially creative use of Bitcoin block space. This means that we need to design an off-chain smart contract system and require the steps that change the contract state, such as contract A changing parameters or B transferring a certain amount of assets to C, to be uploaded to the blockchain as information. By collecting this information, the latest state of this smart contract system can be obtained.

A rough design idea is to upload the information of the steps that change the contract state to the Bitcoin blockchain as it is. This can certainly work, but it faces several problems:

• IBC Product Manager states that Ethereum Layer2 is not the holy grail of scaling.
• From Concept to Performance Is it the Spring of Humanoid Robots?
• What are Dispute Games? Modular games designed for the OP Stack fault-tolerant mechanism.

(1) Because the complete information is uploaded, it may consume more block space, and when users need to change the contract state (such as transferring), they will also need to pay more on-chain transaction fees. Especially when we want such off-chain contract systems to have better programmability than Bitcoin, the increase in programmability may come at the cost of consuming more block space;

(2) Almost any piece of information in a block can change the off-chain smart contract, so users must obtain all Bitcoin block data to derive the latest state of this off-chain contract system, which means higher verification costs;

(3) Depending on the design of the off-chain smart contract system, perhaps only the same level of privacy as Bitcoin can be achieved, or even worse privacy. If more privacy is to be provided, it may require more block space.

In the past, there was a protocol called “Omni” that had a large user base. It does not upload the complete information of off-chain contract transactions, only the hash value of the transactions. This approach solves the above problems and decouples the complexity of off-chain contract transactions from their economic costs. However, users still need to obtain the complete Bitcoin block data to derive the latest state of the Omni protocol. In addition, it does not specifically enhance privacy.

RGB uses a new paradigm called “single-use seals”. Its usage is quite simple: RGB requires that every state of every contract must be attached to a Bitcoin UTXO. Once the state needs to be changed, the UTXO must be spent and the transaction spending it must be confirmed on the blockchain. Additionally, the Bitcoin transaction spending it must provide the hash value of the content of the state transition to indicate the UTXO that the changed state is attached to.

In the eyes of RGB developers, this design is similar to numbered plastic seals: it is easy to tell if it has been tampered with, and once it has been tampered with, it cannot be used again. However, from another perspective, the UTXO that the state is attached to can be considered as a “container” or a ceramic piggy bank. To take out the money from the piggy bank, it must be broken and the money inside must be put into a new piggy bank.

This design is in stark contrast to the previous protocol that treated the entire block as a whiteboard: using UTXOs as containers means that transactions that do not spend the UTXO cannot have any impact on the contract states inside the container. Therefore, to verify a specific state of a contract, we do not need to obtain all the block data. What we need is a series of Bitcoin transactions, evidence that these Bitcoin transactions exist in a specific block, and the RGB state transitions promised by these Bitcoin transactions (paired with relevant Bitcoin transactions). This chain of data should allow us to trace back to the initial state of the contract and recognize the essence of this state.

For readers familiar with on-chain smart contract systems (such as Ethereum), one difficult aspect to understand is: how is the security of this smart contract system ensured without relying on the consensus of the blockchain (which means that the initial state of the contract and each state change will be verified by every node)? How can one ensure that the received assets are the desired ones and prevent illegal issuance of assets?

The answer is simple: “client-side validation” – you validate it yourself. In on-chain contract systems, nodes verify each state transition operation and reject invalid operations based on publicly known state transition rules, thus calculating the latest state based on the initial state. However, as long as the state transition rules and initial state are known, relying on on-chain consensus for verification is not the only way. Users can verify each step of the state transition in accordance with the initially defined state transition rules based on the information provided by the payer. In this way, the verifying party (assuming it is the recipient of the assets) can also detect illegal state transitions and refuse to accept them.

Finally, let’s use an example to illustrate the characteristics of the RGB protocol:

Now, Alice owns UTXO A’, which holds Y units of asset X issued according to the RGB protocol, and she wants to transfer Z units of Y to Bob. These assets have gone through 5 previous owners (including the asset issuer) before they reached Alice. Therefore, Alice needs to provide Bob with evidence of these 4 state transitions (the evidence for the first 3 transitions was provided by the previous owners to Alice), including the initial state and state transition rules of the contract, the Bitcoin transactions used for each transfer, the RGB transactions promised by each Bitcoin transaction, and the evidence that these Bitcoin transactions have been confirmed in a block. Bob will verify that these 4 transfers do not violate the rules based on the contract’s state transition rules, and then decide whether to accept. When Alice constructs the RGB transaction, since Z is less than X, she also needs to arrange a UTXO for herself to receive the remaining portion. Finally, Alice embeds the hash value of this RGB transaction into the Bitcoin transaction that spends UTXO A’, completing this payment.

Finally, due to the use of UTXO containers, the latest state of an RGB contract can be represented as a point on a directed acyclic graph with no descendants (each point represents a state stored in the UTXO container). And for the owner P in the diagram below, he will only know the process from the initial state G of the contract to his own, which is the process marked by the red circle, and he knows nothing about the gray points:

Advantages of RGB

Lightweight Verifiable State

As mentioned above, compared to asset issuance protocols (off-chain contract systems) that appeared on Bitcoin before, RGB significantly reduces the cost of verifying the state of a contract. When making a transaction, the receiver no longer needs to traverse all blocks to collect information about changes in the contract state, but only needs to obtain a series of Bitcoin transactions, as well as the RGB transactions promised by these transactions, and the block containing these Bitcoin transactions with evidence (based on the Merkle evidence of the block header), to ensure that the payer really owns a certain amount of assets.

This reduction in verification cost also greatly reduces the users’ dependence (trust) on large infrastructure providers. In previous protocols, due to the high verification cost, users found it difficult to calculate the latest state of the contract themselves, so they had to trust some providers (such as the contract state provider used by their wallets); at the same time, because there were few providers who could afford such calculation costs, this also meant centralization of providers. However, in RGB, users only need to use a Bitcoin lightweight client to check part of the Bitcoin transactions, and use the RGB protocol to check part of the RGB transactions, which they can afford themselves.

Compared to some on-chain contract systems, RGB also appears to be more lightweight. This is reflected in the fact that RGB can selectively verify a specific state of a contract, while in systems that are not based on UTXO, due to the lack of a mechanism like UTXO to control access, any transaction can change any state, so it is almost impossible to selectively verify a specific state, and one can only determine a specific state while calculating all the latest states — in this sense, the feature expressed as “global state” should actually be called “uniform state”, although it provides the feature of cross-contract access, it also determines that the verification cost will be higher and it is more difficult to achieve trustlessness.

In these on-chain contract protocols, a major optimization measure is to require the block header to commit to the latest state (“state root”), allowing lightweight clients to verify a specific state of a specific contract obtained from a full node based on these commitments. This is a way to reuse the calculations that have already occurred (calculations already performed by full nodes), and it is also very efficient, so if trustlessness is not considered, it can be considered more efficient than RGB. However, it still means that lightweight nodes rely on full nodes for transaction-based verification and contract state computation. In the RGB wallet using a Bitcoin lightweight client, the trust assumption it relies on is that the relevant Bitcoin transactions are valid transactions, and the part related to the contract state is personally verified by the client, hence better trustlessness. The drawback is that the verification delay is longer and more data needs to be stored.

Scalability

The scalability of RGB is reflected in two aspects:

Only a hash value is embedded in Bitcoin transactions, which means that the size of RGB transactions (except for custom rules of the contract) is not limited. Even if you divide an RGB asset into 100 parts (the RGB transaction itself will be very large), only one hash value needs to be embedded in the Bitcoin transaction. As mentioned in note 6, there are two methods to embed such hash values: one is to use the OP_RETURN output, which means it will consume on-chain space for a hash value; the other is to hide it in the script tree promised by the script public key in the Taproot output, which will not consume any on-chain space. This also means that users do not have to sacrifice economy for programmability, only considering on-chain transaction fees.

The latest state of the RGB contract is an independent point on a directed acyclic graph with no descendants, which means that these states can be changed independently without affecting each other, allowing for concurrency. This is actually inherited from the UTXO feature. This also means that invalid changes (invalid transactions) that occur on one branch will not affect other branches, let alone cause the entire contract to freeze, so it can be considered a security benefit.

One criticism of RGB’s scalability is that each transfer requires the receiver to verify all the transactions involved from the initial state to the payer’s state. As the number of asset transfers increases, the verification burden on subsequent receivers will become heavier. This criticism is true. Optimizing it means that we also need to find a way to reuse the calculations that have already occurred. Proof system technologies (such as SNARKs) are expected to provide such solutions.

Differentiation of Asset Definition and Custody Mechanism

The last benefit is still related to UTXO and depends on how we understand the locking script mechanism of UTXO.

The locking script can be used to program the unlocking conditions for a fund, so it can implement custody rules. For example, if a locking script contains only one public key, it means that only the owner of the corresponding private key can control it. However, such custody rules are also the basis of Bitcoin contract-style protocol programming. For example, a UTXO with a 2-of-2 multisignature locking script can be a lightning channel. During the operation of the channel, the two parties can make almost countless mutual payments without changing the on-chain form of the funds. In other words, at this time, the 2-of-2 multisignature locking script constitutes a value transfer mechanism, allowing the transfer of value between the two parties without changing the on-chain form of the funds.

Such a mechanism can be used on the Bitcoin value carried by UTXO, and of course, it can also be used on RGB assets carried by UTXO. We can issue an RGB asset and attach it to a 2-of-2 multisignature UTXO, thereby using the mechanism of a lightning channel to enable unlimited mutual payments of this asset between the two parties. Similarly, RGB assets can also enter other Bitcoin script-based contracts.

Here, the separation of functions between UTXO scripts and the RGB protocol is formed: the former is dedicated to implementing rules for value preservation and value transfer, while the latter focuses on asset definition. As a result, asset preservation and asset definition can be separated. This is an important security improvement and something that people have been striving for in other chain contract systems.

Designs made by RGB

The above features actually apply to all protocols based on UTXO one-time sealing and client verification. However, the RGB protocol has made further designs on this basis.

In the development of the current RGB protocol, developers have paid particular attention to the privacy of the protocol, so RGB has strengthened privacy in two aspects:

Blinding UTXOs. In RGB transactions, the recipient only needs to use obscured UTXO identifiers to receive assets, without exposing the characteristics of the real UTXO that receives the assets. This does not affect the recipient’s ability to provide evidence to the next owner while allowing subsequent asset recipients to resist the previous owner’s snooping.

Bulletproof. It can be used to hide the specific amounts in each transaction. However, subsequent asset owners can still verify that there has been no additional issuance before.

Space for further exploration

In this section, I will discuss the space that the RGB protocol can continue to explore, mainly related to programmability.

Currently, the proposed RGB contract templates (schemas) are mainly focused on asset issuance. However, due to the use of the “client verification” paradigm in RGB, in fact, we can add any features that can be ensured by client verification – only limited by the UTXO structure.

Covenant restrictions

On top of UTXO, a concept that can broaden programmability is called “covenant restrictions”. The original intention of covenant restrictions is to limit the destination to which funds can be transferred. With this ability, we can program many interesting applications, such as:

Non-interactive withdrawal fund pool. We can gather funds from many people in the same UTXO and use covenant restrictions to ensure that any of them can withdraw their own funds without the help of others. This can help people withdraw from high-risk places at low cost when there is high demand for block space.

Safe deposit box contract. Make a fund must be spent to a certain place and go through a time lock before it can be freely spent; during the time lock, the owner of the safe deposit box can interrupt this process and immediately transfer the funds elsewhere using an emergency key. This device can provide great help for self-storage.

The current Bitcoin script does not have this ability, so enabling covenant restrictions on the Bitcoin script requires a soft fork.

However, as long as we are willing to sacrifice some of the benefits brought by the “separation of asset definition and preservation mechanism”, we can experiment with such features on RGB assets. We can achieve such functionality at the RGB contract level – although it only applies to RGB assets that use it, not Bitcoin – but undoubtedly it will open up an interesting space.

The research on existing restriction terms shows that it can expand the programming space for UTXO-based transactions and provide many features. However, these studies are mainly based on Bitcoin, and we will be more conservative on protocols like Bitcoin. On RGB, we can boldly generalize the core ability of restriction terms – the ability to read spending transactions at the script level – to provide more flexibility in programmability: the ability to cross-access contracts.

Cross-Access

The minimum restriction term means that when a UTXO is spent, its script can read the output of the spending transaction. But a fully generalized restriction term means that it can read all parts of the transaction that spent it. This means that it can also read other inputs of the transaction, and if we do not require other inputs to come from the same contract, it means that it can read the state of other contracts.

In RGB, we assume that each contract is an independent universe with its own directed acyclic graph. However, it is still possible for a user to hold the states of two different contracts at the same time. If RGB transactions allow spending assets from two different contracts at the same time, such cross-access capabilities may have use cases (although it can be imagined that it will make transaction verification more complex).

In fact, there are already on-chain contract systems based on UTXO-like structures (e.g., Nervos Network) that use this point to implement cross-access capabilities for contracts. This is a very new field, which has been rarely explored in previous Bitcoin research, and there may be some surprises buried in it.

Conclusion

In this article, readers will find that there is a concept that is frequently mentioned and runs through all the reasoning and fantasies: “UTXO”. That is exactly my intention. If you don’t understand UTXO, you can’t understand the starting point of the design of protocols like RGB, nor can you understand the advantages of RGB protocol design, and you can’t imagine how people use it. The features of the RGB protocol are largely shaped by its UTXO’s one-time sealed form. Correspondingly, the research on UTXO accumulated in the Bitcoin research field can also be applied to the study of RGB.

This also explains why people who don’t understand Bitcoin will find it difficult to understand RGB. And those who like Bitcoin will appreciate the design made by RGB.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.