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

What is the RGB protocol?

The idea of issuing assets on Bitcoin has been around for a long time. However, the Bitcoin protocol has its own characteristics: its state is expressed only 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"), used to program the spending conditions of this fund, such as providing a signature of a certain public key; the opcodes allowed to program the locking script are provided by the consensus rules of Bitcoin, and they cannot be used to implement arbitrary security rules. Therefore, it is impossible for us to create other assets within UTXOs - Bitcoin scripts cannot program security checks for these assets. This means that all ideas for issuing assets on Bitcoin are essentially a creative use of the Bitcoin block space. This means that we need to design an off-chain smart contract system and require that the steps that change the contract state - for example, contract A changes parameters, and B transfers a certain amount of some asset to C - upload information to the blockchain. By collecting this information, we can obtain the latest state of this smart contract system.

One rough design idea is to upload the information of the steps that change the contract state to the Bitcoin blockchain as is. This can certainly work, but it faces several problems: (1) since complete information is uploaded, it may consume more block space, and when users need to change the contract state (such as transferring funds), they will also need to pay more on-chain fees. Especially when we hope that such off-chain contract systems have better programmability than Bitcoin, the increase in programmability may come at the cost of consuming more block space; (2) almost any information in the block can change the off-chain smart contract, so users must obtain all Bitcoin block data to determine the latest state of the off-chain contract system, which increases its verification cost; (3) depending on the design of the off-chain smart contract system, perhaps only the same level of privacy as Bitcoin can be obtained, or even worse privacy. If more privacy can be provided, it may require more block space. (Note 5: https://www.btcstudy.org/2023/09/12/the-potential-of-RGB-protocol/#note5)

In the past, a protocol with high usage called "Omni" was used. It did not upload the complete information of off-chain contract transactions, only the hash value of the transaction. This approach solved the above problem 1, decoupling the complexity and economic cost of off-chain contract transactions. However, users still need to obtain the full Bitcoin block data to determine the latest status of the Omni protocol. In addition, it does not specifically enhance privacy.

而 RGB uses a new paradigm called "single-use seals". Its usage is simple: RGB requires that every state of every contract must be attached to a Bitcoin UTXO; and once this state needs to be changed, the UTXO must be spent and the transaction spending it must be confirmed on the blockchain. In addition, the Bitcoin transaction spending it must provide the hash value of the content of the state transition to indicate the UTXO to which the changed state is attached. 6.

From the perspective 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 has been possessed can be regarded as a container or ceramic piggy bank for this state - if you want to take out the money in the piggy bank, you must break the piggy bank and put the money inside into a new one.

This design is in stark contrast to the previous protocol that treated the entire block as a capital letter board. Using UTXO as a container means that transactions that do not spend this UTXO cannot have any impact on the contract state inside the container. Therefore, to verify a certain state of a contract, we do not need to obtain all the data of the entire block. All we need is a series of Bitcoin transactions, which exist as evidence in a certain block, and the RGB state transitions promised by these Bitcoin transactions (paired with the relevant Bitcoin transactions). These data that can be linked into a chain should allow us to trace back to the initial state of the contract and enable us to identify 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 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 every state change will be verified by every node)? How can one ensure that the assets received are the ones they intended to receive, and how can one ensure that the assets have not been illegally increased?

The answer is simple, it's called "client-side validation". In the on-chain contract system, nodes verify each state transition operation and reject invalid operations based on publicly available 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, verifying through on-chain consensus is not the only way. Users can verify whether each step of the state transition follows the originally defined state transition rules based on the information provided by the payment party. Through this method, the verifying party (assuming it is the recipient of the asset) can also detect illegal state transitions and reject them.

Finally, we use an example to demonstrate the characteristics of the RGB protocol:

Now, Alice owns UTXO A, which holds the asset Y of X units issued according to the RGB protocol, and she wants to transfer Y of Z units 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 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 were confirmed by a certain block, all sent to Bob. Bob will verify that these 4 transfers do not violate the rules according to the state transition rules of the contract, and then decide whether to accept them. 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 part. 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). Moreover, for owner P in the following figure, he will only know the process from the initial state G to his own state, i.e. the process marked in red, and knows nothing about the gray points:

RGB Advantages

Lightweight Verifiable State

As mentioned above, compared with the asset issuance protocol (off-chain contract system) previously appeared on Bitcoin, RGB significantly reduces the cost of verification (a state of a contract). When making a transaction, the receiver no longer needs to traverse all blocks to collect information about the change of contract state, but only needs to obtain a series of Bitcoin transactions, as well as the RGB transactions promised by these transactions. By including evidence in the blocks of these Bitcoin transactions (based on the Merkel proof of the block header), the receiver can be sure that the payer really owns a certain amount of a certain asset.

The reduction in the cost of this type of verification also greatly reduces the user's dependence (trust) on large infrastructure providers. In previous protocols, due to the high cost of verification, users were unable to calculate the latest status of the contract themselves, so users had to trust some providers (such as the contract status provider used by their own wallet); at the same time, because there are few providers who can afford such calculation costs, this also means centralization of providers. However, in RGB, users only need to use a Bitcoin light client to check part of the transaction with Bitcoin, and use the RGB protocol to check part of the RGB transaction, which they can afford themselves.

Compared with some on-chain contract systems, RGB 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, any transaction can change any state without a mechanism to control access, making it almost impossible to selectively verify a specific state. Instead, one can only determine a specific state while calculating all the latest states, which is expressed as the "global state" feature, but should actually be called the "uniform state" feature. Although it provides the feature of cross-contract access, it also determines that its verification cost will be higher and it will be more difficult to obtain trustlessness.

One major optimization measure in these chain-based contract protocols 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 obtained from a full node based on these commitments. This is a method of reusing computations that have already occurred (computations that have already been run by full nodes), which is also very efficient. Therefore, if trustlessness is not considered, it can be considered more efficient than RGB. However, it still means that light nodes rely on full nodes for transaction-based verification and contract state calculation. In the RGB wallet that uses the Bitcoin light 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 verified by the client itself, so trustlessness is better. The disadvantage 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 volume 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 ways 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 on 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 with no descendants on a directed acyclic graph - which means that these states can be changed independently and do not affect each other, allowing for concurrency. This is actually a feature inherited from UTXO. 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 also be considered a security benefit.

One criticism of RGB's scalability is that every transfer requires the receiver to verify all transactions 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 valid. However, optimizing it means finding a way to reuse previously performed operations. Proof system technologies (such as SNARKs) are expected to provide such solutions 7.

Asset Definition and Custody Mechanism Separation

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

Locking script can be used to program the unlocking conditions of a fund, thus enabling the implementation of 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 8. For example, a UTXO that uses a 2-of-2 multisignature locking script can be a lightning channel; during the channel operation, the two parties can make almost countless mutual payments, and the on-chain form of the funds will not change. In other words, at this time, the 2-of-2 multisignature locking script constitutes a value transfer mechanism, allowing both parties to transfer value without changing the on-chain form of the funds.

This mechanism can be used for the Bitcoin value carried by UTXO, and of course, it can also be used for RGB assets carried by UTXO. We can issue an RGB asset and attach it to a 2-of-2 multisig UTXO, thereby utilizing the mechanism of Lightning Network to make unlimited mutual payments of this asset between the two parties 9. Similarly, RGB assets can also enter other Bitcoin script-based contracts.

Here, the functional differentiation between UTXO scripts and the RGB protocol is formed: the former is dedicated to implementing rules for value custody and transfer, while the latter focuses on asset definition. As a result, asset custody and asset definition can be separated. This is an important security enhancement and something that people have been striving for in contract systems on some other chains.

RGB has made the design

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

In the current development of the RGB protocol, developers are particularly concerned about the privacy of the protocol. Therefore, RGB has strengthened privacy in two aspects:

Blinding UTXO. In RGB transactions, the recipient only needs to use the obfuscated UTXO identifier to receive assets, without exposing the characteristics of the UTXO that actually 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 surveillance of previous asset owners.

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

Explorable Space

In this section, I will discuss the space that can still be explored with regards to the programmability of the RGB protocol.

Currently, all proposed RGB contract templates (schemas) are focused on asset issuance. However, due to RGB's use of the "client-side validation" paradigm, in reality, we can add any feature that can be ensured through client-side validation - limited only by the structure of UTXOs.

Restriction Terms

On the basis of UTXO, a concept that can expand programmability is called "covenants"  10. The original intention of covenants is to restrict the destination to which a fund 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 into the same UTXO and use restrictive terms to ensure that anyone 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. It requires a sum of money to be spent in a certain place and go through a time lock before it can be spent freely. During the time lock, the owner of the safe deposit box can use an emergency key to interrupt the process and immediately transfer the funds to another place. This device can provide great assistance for self-storage.

The current Bitcoin script does not have this capability, so enabling restriction clauses on the Bitcoin script requires a soft fork.

However, as long as we are willing to sacrifice some of the benefits brought by the "differentiation of asset definition and custody mechanism", we can experiment with such features on RGB assets. We can implement this functionality at the RGB contract level - although it only applies to RGB assets that use it (not Bitcoin), it will undoubtedly open up an interesting space.

Research on existing restriction clauses shows that they can expand the programming space for UTXO-based transactions and provide many features. However, these studies are mainly based on Bitcoin, and we are more conservative on protocols like Bitcoin. On RGB, we can boldly generalize the core ability of restriction clauses - the ability to read transactions that spend themselves at the script level - to provide more flexible programmability: the ability to cross-access contracts.

交叉访问

translates to

Cross Access

The minimum restriction clause means that when a UTXO is spent, its script can read the output of the spending transaction. However, a fully generalized restriction clause means that it can read all parts of the transaction that spends it. This means that it can also read other inputs of the transaction, and if we do not specify that other inputs must 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 state of two different contracts at the same time. If RGB transactions allow spending assets from two different contracts at the same time, such cross-contract access may have use cases (although it can be imagined that it would make transaction verification more complex).

Actually, there are already on-chain contract systems based on UTXO-like structures (such as Nervos Network), which use this to achieve cross-contract access capabilities 11. This is a very new field, opening up areas that previous Bitcoin research has rarely touched, and perhaps there are some surprises hidden within.

Conclusion

In this article, readers will discover a concept that is frequently mentioned and runs through all the processes of reasoning and imagination: "UTXO". This is precisely my intention. If you do not understand UTXO, you cannot understand the starting point of the design of protocols such as RGB, nor can you understand the advantages of the design of RGB protocols, nor can you imagine how people use it. The characteristics of the RGB protocol are largely shaped by its UTXO, which is a one-time seal. Correspondingly, the research on UTXO accumulated in the Bitcoin research field can also be applied to the study of RGB.

This also explains why those who do not understand Bitcoin will find it difficult to understand RGB. Those who like Bitcoin, on the other hand, will appreciate the design that RGB has already made.

Due to excessive annotations in the article, please refer to the following link: