What is the true potential of the Bitcoin asset issuance protocol RGB?

Author: A Jian, Wu Shuo Blockchain

This article attempts to provide a concise description of the RGB asset issuance protocol on Bitcoin (which can also be understood as an off-chain smart contract system) and points out how it differs from other protocols aimed at achieving the same or similar functions. These differences allow the RGB protocol's scalability to far exceed theirs and leave a broader programming space. In addition to introducing the design that RGB has completed, we will also explore these programming possibilities.

What is the RGB Protocol?

The idea of issuing assets on Bitcoin has a long history. 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 denomination (Bitcoin value) and a "script public key" (also known as a "locking script") that programs the conditions for spending these funds, such as providing a signature from a specific public key. The opcodes that can be used to program the locking script are provided by Bitcoin's consensus rules, and they cannot be used to implement arbitrary security rules. Therefore, it is impossible to create other assets within a UTXO—Bitcoin scripts cannot program security checks for these assets. This means that all ideas for issuing assets on Bitcoin are essentially creative uses of Bitcoin's block space. This implies that we need to design an off-chain smart contract system and require that the steps that change the contract's state—such as contract A changing parameters, and B transferring a certain amount of some asset to C—have their information uploaded to the blockchain. Thus, by collecting this information, we can obtain the latest state of this smart contract system.

A rough design idea is to upload the information of the steps that change the contract's state intact to the Bitcoin blockchain. This can certainly work, but it faces several issues: (1) By uploading complete information, it may consume more block space, and when users need to change the contract's state (e.g., for transfers), they will also have to pay higher on-chain fees. Especially when we want such an off-chain contract system 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 within a block could potentially 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, it may only achieve privacy comparable to Bitcoin, or even worse; and if more privacy can be provided, it may require consuming more block space.

In the past, a widely used protocol called "Omni" did not upload the complete information of off-chain contract transactions but only uploaded the hash of the transaction. This approach addressed the aforementioned issue (1), decoupling the complexity of off-chain contract transactions from their economic costs; however, users still needed to obtain the full Bitcoin block data to derive the latest state of the Omni protocol; furthermore, it did not specifically enhance privacy.

RGB, on the other hand, employs a new paradigm called "single-use seals." Its usage is straightforward: RGB requires that every state of a contract must be attached to a specific Bitcoin UTXO; once this state needs to be changed, the UTXO must be spent, and the transaction spending it must receive confirmation on the blockchain. Additionally, the Bitcoin transaction spending it must also provide the hash of the content of the state transition to indicate which UTXO the changed state is attached to.

From the perspective of RGB developers, this design is similar to numbered plastic seals: it is easy to see if it has been tampered with, and once it has been tampered with, it cannot be reused. However, from another angle, the UTXO that is attached can be seen as a container for this state or a ceramic piggy bank—if you want to take money out of the piggy bank, you must break it and then put the money into a new container.

This design sharply contrasts with previous protocols that treated the entire block as a large slate: using UTXOs as containers means that transactions that do not spend this UTXO cannot affect the contract state inside the container. Therefore, to verify a specific state of a contract, we do not need to obtain all the block data; we only need a series of Bitcoin transactions, evidence that these Bitcoin transactions exist in a certain block, and the RGB state transitions promised by these Bitcoin transactions (paired with the relevant Bitcoin transactions). This data, which can be linked into a chain, should allow us to trace back to the initial state of this contract, enabling us to identify the essence of this state.

For readers familiar with on-chain smart contract systems (like Ethereum), one difficult aspect of this process is: how is the security of such a smart contract system ensured if it does not rely 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 assets received are indeed the desired type and that the assets have not been illegally inflated?

The answer is simple: "client-side validation"—you verify it yourself. In on-chain contract systems, nodes verify each state transition operation based on publicly available state transition rules, rejecting invalid operations, thus calculating the latest state from the initial state. However, as long as the state transition rules and the initial state are known, verifying through blockchain consensus is not the only method; users can verify each step of the state transition themselves based on the information provided by the payer to ensure compliance with the originally defined state transition rules. Through this method, the verifying party (presumably the asset receiver) can also detect illegal state transitions and refuse to accept them.

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

Now, Alice has UTXO A', which holds X units of asset Y issued according to the RGB protocol, and she wishes to transfer Z units of Y to Bob. This batch of assets has gone through 5 previous owners (including the asset issuer) before reaching Alice. Therefore, Alice needs to provide Bob with evidence of these 4 state transitions (the evidence for the first 3 transitions was provided to Alice by the previous owners), including the initial state of the contract and the state transition rules, each Bitcoin transaction used for the transfer, the RGB transaction promised by each Bitcoin transaction, and evidence that these Bitcoin transactions have been confirmed by a certain block, all sent to Bob. Bob will verify that these 4 transfers do not violate the rules according to the contract's state transition rules before deciding 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 of this RGB transaction into the Bitcoin transaction that spends UTXO A', completing the payment.

Ultimately, 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 a UTXO container). Moreover, for the owner P in the diagram below, they will only know the process from the initial state G to their state, indicated by the red circle, while being completely unaware of the gray points:

Advantages of RGB

Cool Verifiable State

As mentioned above, compared to previous asset issuance protocols (off-chain contract systems) that appeared on Bitcoin, RGB significantly reduces the cost of verification (of a specific state of a contract). During transactions, the receiver no longer needs to traverse all blocks to collect information about changes in the contract state; they only need to obtain a series of Bitcoin transactions, the RGB transactions promised by these transactions, and evidence that these Bitcoin transactions are included in a block (based on the Merkle evidence of the block header) to be assured that the payer indeed possesses a certain amount of some asset.

This reduction in verification costs also greatly diminishes users' reliance (trust) on large infrastructure providers. In previous protocols, due to high verification costs, users found it difficult to calculate the latest state of the contract themselves, thus needing to trust some providers (such as the contract state provider used by their wallet); simultaneously, because there were few providers capable of bearing such computational costs, this also meant centralization of providers. However, in RGB, users only need to use a Bitcoin light client to check the Bitcoin transaction part and use the RGB protocol to check the RGB transaction part, allowing them to bear the costs themselves.

Compared to some on-chain contract systems, RGB also appears to be more lightweight. This is reflected in RGB's ability to specifically verify a certain state of a contract; in systems that do not rely on UTXOs, due to the lack of a mechanism like UTXO to control access, any transaction could potentially change any state, making it nearly impossible to specifically verify a certain state, and one can only determine a specific state while calculating all the latest states—in this sense, the characteristic expressed as "global state" should actually be referred to as "uniform state." Although it provides the feature of cross-access between contracts, it also determines that its verification costs will be higher and more difficult to achieve trustlessness.

In these on-chain contract protocols, a significant optimization measure is to require the block header to commit to the latest state ("state root"), allowing light clients to verify a certain state of a contract based on these commitments. This is a method of reusing computations that have already occurred (computations that full nodes have already run) and is very efficient. Therefore, if we do not consider trustlessness, it can be seen as more efficient than RGB. However, it does mean that light nodes rely on full nodes for transaction base verification and contract state calculation. In RGB wallets using Bitcoin light clients, the trust assumption they rely on is that the relevant Bitcoin transactions are valid, while the parts related to the contract state are personally verified by the client, thus providing better trustlessness. The downside is that verification latency is longer, and more data needs to be stored.

Scalability

The scalability of RGB is reflected in two aspects:

1. Only a hash value is embedded in the Bitcoin transaction, meaning that the size of RGB transactions (aside from the custom rules of the contract) has no limitations— even if you split an RGB asset into 100 parts (the RGB transaction itself will be very large), only a single hash value needs to be embedded in the Bitcoin transaction. As noted in footnote 6, there are two methods for embedding such a hash value: one is using OP_RETURN output, which means it will consume on-chain space for one hash value; the other is hiding it in the script public key promised by the Taproot output's script tree—this will not consume any on-chain space. This also means that users do not have to sacrifice economic efficiency for programmability—at least considering on-chain transaction fees.

2. The latest state of an RGB contract is an independent point on a directed acyclic graph with no descendants—this means that these states can change independently and do not affect each other, allowing for concurrency. This is actually a characteristic inherited from UTXOs. This also means that invalid changes (invalid transactions) occurring on one branch will not affect other branches and will not cause the entire contract to become stuck, thus can also be seen as a safety benefit.

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

Separation of Asset Definition and Custody Mechanism

The final benefit is still related to UTXOs, depending on how we understand the locking script mechanism of UTXOs.

Locking scripts can be used to program the conditions for unlocking funds, thus enabling 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 for programming in Bitcoin contract protocols. For instance, a UTXO using a 2-of-2 multi-signature locking script can be a Lightning channel; during the channel's operation, both parties can make almost countless mutual payments, while the on-chain form of funds remains unchanged. In other words, at this time, the 2-of-2 multi-signature locking script constitutes a value transfer mechanism that allows both parties to transfer value without changing the on-chain form of funds.

Such a mechanism can be applied to the Bitcoin value carried by UTXOs, and naturally, it can also be applied to the RGB assets they carry. We can issue an RGB asset and attach it to a 2-of-2 multi-signature UTXO, thus utilizing the Lightning channel mechanism to allow for unlimited mutual payments of this asset between both parties. Similarly, RGB assets can also enter other contracts based on Bitcoin scripts.

Here, the scripts of UTXOs and the RGB protocol form a functional separation: the former is dedicated to implementing rules for value custody and transfer, while the latter focuses on asset definition. Thus, the custody of assets and the definition of assets can be separated. This is an important enhancement in security and is something sought after in some other on-chain contract systems.

Designs Already Made by RGB

The aforementioned characteristics actually apply to all protocols based on UTXO single-use seals and client-side validation. However, on this basis, the RGB protocol has made further designs.

In the current development of the RGB protocol, developers are particularly focused on the protocol's privacy, thus RGB has enhanced privacy in two aspects:

• Obfuscating UTXOs. In RGB transactions, the receiver only needs to use an obfuscated UTXO identifier to receive assets, without exposing the characteristics of the actual UTXO receiving the assets. This does not impair the receiver's ability to provide evidence to the next owner while allowing subsequent asset receivers to resist the prying of previous asset owners.

• Bulletproofs. These can be used to hide the specific amounts in each transaction. However, subsequent asset owners can still verify that there has been no inflation.

Explorable Space

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 focused on asset issuance. However, since RGB uses the "client-side validation" paradigm, we can actually add any features that can be ensured through client-side validation—only limited by the structure of UTXOs.

Covenants

Based on UTXOs, a concept that can broaden programmability is called "covenants." The essence of covenants is to restrict the destination to which funds can be transferred. With this capability, we can program many interesting applications, such as:

• Non-interactive withdrawal pools. We can allow many people's funds to pool in the same UTXO and use covenants to ensure that any of them can withdraw their funds without needing help from others. This can help people exit high-risk situations at low cost when demand for block space surges.

• Safe contracts. Require that funds must first be spent to a certain place and go through a time lock before they can be freely spent; during the time lock, the safe owner can use an emergency key to interrupt this process and immediately transfer the funds elsewhere. This mechanism can greatly assist in self-custody.

Current Bitcoin scripts do not have this capability, so enabling covenants on Bitcoin scripts would require a soft fork.

However, as long as we are willing to sacrifice some benefits brought by the "separation of asset definition and custody mechanism," we can experiment with such features on RGB assets. We can implement such functionality at the RGB contract level—although it will only be effective for the RGB assets using it (and not for Bitcoin), it will undoubtedly open an interesting space.

Existing research on covenants has shown that they can broaden the programming space of UTXO-based transactions and provide many features. However, this research is primarily based on Bitcoin, and on protocols like Bitcoin, we tend to be more conservative. In RGB, we can boldly generalize the core capability of covenants—the ability to read the transactions that spend themselves at the script level—thus providing more flexible programmability: the ability to cross-access contracts.

Cross-Access

The minimal covenant means that when a UTXO is spent, its script can read the outputs of the spending transaction. However, fully generalized covenants mean that it can read all parts of the transaction that spends it. This means it can also read other inputs of the transaction; if we do not restrict that other inputs must come from the same contract, it means it can read the states 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 simultaneously. If RGB transactions allow spending assets from two different contracts simultaneously, such cross-access capability may have application scenarios (although it can be imagined that it would 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 to implement cross-access capabilities for contracts. This is a very new field, opening up areas that past Bitcoin research has rarely touched, and may hold some surprises.

Conclusion

In this article, readers will find that a concept is frequently mentioned and runs through all reasoning and imagination: "UTXO." This is precisely my intention. If you do not understand UTXO, you cannot grasp the starting point of the design of protocols like RGB, nor can you understand the advantages of RGB's design, or imagine how people will use it. The characteristics of the RGB protocol are largely shaped by its UTXO single-use seal form. Correspondingly, the research accumulated in the field of Bitcoin regarding UTXOs can also be applied to our study of RGB.

This also explains why those who do not understand Bitcoin will find it difficult to comprehend RGB, while those who appreciate Bitcoin will recognize the designs that RGB has already made.