Original title: "The True Potential of RGB" Original author: Ajian

This article attempts to provide a concise description of RGB, an asset issuance protocol on Bitcoin (it can also be understood as an off-chain smart contract system), and points out its differences from other protocols that aim to achieve the same or similar functions. These differences make the RGB protocol far more scalable and leave a wider programming space. In addition to introducing RGB’s completed design, we will also explore these programming possibilities1.

What is the RGB protocol?

The idea of ​​issuing assets on Bitcoin is old 2 3. But the Bitcoin protocol has its own characteristics 4: its state is expressed by and only by Bitcoin UTXO ("unspent transaction output"); a UTXO carries only two data: its own denomination (Bitcoin value), and a "script public key" (also called a "locking script"), which is used to program the spending conditions of this fund, such as providing a signature of a certain public key; the opcodes that allow the programming of 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 inside 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 block space. This means that we need to design an off-chain smart contract system and require that the steps to change the state of the contract - for example, contract A changes parameters, B transfers a certain amount of a certain asset to C - be uploaded to the blockchain, so that the latest state of this smart contract system can be obtained by collecting this information.

A rough design idea is to upload the information of the steps to change the contract status intact to the Bitcoin blockchain. This can certainly work, but it will face several problems: (1) Since the complete information is uploaded, it may consume more block space. When users need to change the state of the contract (such as transferring money), they will also need to pay more on-chain fees. In particular, when we hope that such an off-chain contract system has 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 may change the off-chain smart contract. Therefore, users must obtain all Bitcoin block data to obtain the latest state of this off-chain contract system, that is, its verification cost is higher; (3) Depending on the design of the off-chain smart contract system, it may only be able to obtain privacy comparable to Bitcoin, or even worse privacy; and if more privacy can be provided, it may require more block space 5.

In the past, a widely used protocol called "Omni" would not upload the complete information of off-chain contract transactions, but only the hash value of the transaction. This approach solves the above problem 1, decoupling the complexity of off-chain contract transactions from their economic costs; however, users still need to obtain the full amount of Bitcoin block data to obtain 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 is to be changed, this UTXO must be spent and the transaction that spends it must be confirmed by the blockchain; in addition, the Bitcoin transaction that spends it must also provide the hash value of the state transition content 6 to indicate the UTXO to which the changed state is attached.

In the eyes of RGB developers, this design is similar to a numbered plastic seal: it is easy to see if it has been opened, and once it has been opened, it cannot be used again. However, another perspective is to regard the possessed UTXO as a container or a ceramic piggy bank in this state - if you want to take out the money in the piggy bank, you must break the piggy bank and put the money in a new jar.

This design is in stark contrast to the previous protocol that treats the entire block as a large writing board: using UTXO as a container means that transactions that do not spend this UTXO cannot have any impact on the contract state in the container. Therefore, to verify a certain state of a certain contract, we do not need to obtain the data of the entire block. All we need is a series of Bitcoin transactions, evidence of the existence of these Bitcoin transactions in a certain block, and the RGB state transitions promised by these Bitcoin transactions (paired with the relevant Bitcoin transactions one by one). These data that can be connected in series 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 who are familiar with on-chain smart contract systems (such as Ethereum), one of the things that is difficult to understand about this process is: 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 the security of this smart contract system be guaranteed? How can you ensure that the assets you receive are the ones you want, and how can you ensure that the assets have not been illegally issued?

The answer is also very simple, it is called "client-side validation" - you verify it yourself. In the on-chain contract system, the node verifies each state transition operation according to the public state transition rules, rejects invalid operations, and calculates the latest state based on the initial state. However, as long as the state transition rules and the initial state are known, verification through on-chain consensus is not the only way. Users can verify whether each step of the state transition follows 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 asset) can also check for illegal state transitions and refuse to accept them.

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

Now, Alice owns UTXO A', which holds X units of asset Y issued according to the RGB protocol. She wants to transfer Z units of Y to Bob. This batch of assets has gone through 5 previous owners (including the asset issuer) before it reaches Alice. Therefore, Alice needs to provide Bob with evidence of these 4 state transitions (the evidence of the first 3 times is provided to Alice by the previous owner), including the initial state and state transition rules of the contract, the Bitcoin transaction used for each transfer, the RGB transaction promised by each Bitcoin transaction, and the evidence that these Bitcoin transactions are confirmed by a certain block, and send them together 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 arranges 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' to complete the 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 that has no descendants (each point represents a state stored in the UTXO container). And, for the owner P in the figure below, he will only know the process from the initial state G of the contract to his, that 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 with the asset issuance protocol (off-chain contract system) that appeared on Bitcoin before, RGB greatly reduces the cost of verification (a certain state of a contract). When trading, the recipient 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 exchanges, and the blocks of these Bitcoin transactions contain evidence (based on the Merkle evidence of the block header) to be sure that the payer really owns a certain amount of a certain asset.

This reduction in verification costs also greatly reduces users' reliance (trust) on large infrastructure providers. In previous protocols, due to the high verification costs, it was difficult for users to calculate the latest status of the contract by themselves, so users had to trust some providers (such as the contract status provider used by their own wallets); at the same time, because there were fewer providers who could afford such calculation costs, this also meant the centralization of providers. But in RGB, users only need to use the Bitcoin light client to check the part of the transaction with Bitcoin and use the RGB protocol to check the part of the RGB transaction, and they can afford it themselves.

Compared with some on-chain contract systems, RGB is also lighter. This is reflected in the fact that RGB can specifically verify a certain state of a contract; in systems that are not based on UTXO, due to the lack of a mechanism to control access such as UTXO, any transaction may change any state, so it is almost impossible to specifically verify a certain state, and you can only determine a certain 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-access between contracts, it also determines that its verification cost will be higher and it will be more difficult to obtain trustlessness.

A major optimization measure in these on-chain 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 way to reuse calculations that have already occurred (calculations that have already been run by full nodes), and it is also very efficient. Therefore, if trustlessness is not considered, it can be considered more efficient than RGB. However, it does mean that light nodes rely on full nodes for both transaction basic verification and contract state calculation. In the RGB wallet using 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 kept.

Scalability

The scalability of RGB is reflected in two aspects:

Embedded in a Bitcoin transaction is only a hash value, which means that there is no limit to the size of an RGB transaction (except for the contract's custom rules) - even if you split an RGB asset into 100 shares (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 a hash value: one is to use OP_RETURN output, which means it consumes a hash value on-chain space; the other is to hide in the script tree promised by the script public key of the Taproot output - this does not consume any on-chain space. This also means that users do not have to sacrifice economics for programmability - if only on-chain fees are considered.

The latest state of the RGB contract is an independent point on a directed acyclic graph with no descendants - this means that these states can be changed independently and do not affect each other, which means that concurrency is allowed. This is actually a feature inherited from UTXO. This also means that invalid changes (invalid transactions) on one branch will not affect other branches, let alone cause the entire contract to get stuck, so it can also be regarded as a security benefit.

One criticism of RGB’s scalability is that for every transfer, the recipient needs to verify all transactions from the initial state to the payer’s state — as the number of times the asset changes hands increases, the verification burden on subsequent recipients becomes heavier. This criticism is true. Optimizing it means we also need to find a way to reuse operations that have already occurred. Proof system technology (such as SNARKs) is expected to provide such a solution7.

Differentiation of asset definitions and custody mechanisms

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

Locking scripts can be used to program the conditions under which a fund is unlocked, and therefore can implement custody rules. For example, if a locking script contains only one public key, that means only the owner of the corresponding private key can control it. However, such custody rules are also the basis for Bitcoin contractual protocol programming 8. For example, a UTXO using a 2-of-2 multi-signature locking script can be a lightning channel; during the operation of the channel, the two parties can make almost an infinite number of payments to each other, and the on-chain form of the funds will not change. In other words, at this point, the 2-of-2 multi-signature locking script constitutes a value transfer mechanism that allows the two parties to transfer value without changing the on-chain form of the funds.

Such a mechanism can be used for the Bitcoin value carried by UTXO, and naturally, it can also be used for the RGB assets it carries. We can issue an RGB asset and attach it to a 2-of-2 multi-signature UTXO, so that the two parties can pay this asset to each other unlimited times using the mechanism of the lightning channel. 9 Similarly, RGB assets can also enter other contracts based on Bitcoin scripts.

Here, the UTXO script and the RGB protocol form a functional differentiation: the former is committed to implementing the rules of value custody and value transfer; while the latter focuses on asset definition. As a result, asset custody and asset definition can be separated. This is an important security improvement, and it is also something that people are striving for in some other on-chain contract systems.

RGB has made designs

The above characteristics 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 pay special attention to the privacy of the protocol, so RGB strengthens privacy in two aspects:

Blinded UTXO. In RGB transactions, the recipient only needs to use the obfuscated UTXO identifier to receive the asset without revealing the characteristics of the UTXO that actually received the asset. This does not in any way affect the recipient's ability to provide evidence to the next owner, while allowing subsequent asset recipients to resist the prying eyes of the previous asset owner.

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

Space to explore

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 all focused on asset issuance. However, since RGB uses the "client verification" paradigm, in fact, we can add any features that can be ensured by client verification to it - only limited by the UTXO structure.

Restrictions

On the basis of UTXO, a concept that can broaden programmability is called "covenants" 10. The original intention of covenants is to limit the destination to which funds can be transferred. With this ability, we can program many interesting applications, such as:

Pools for non-interactive withdrawals. We can pool funds from many people in the same UTXO and use restrictions to ensure that any of them can withdraw their own funds without help from others. This can help people exit high-risk places at a low cost when demand for block space is high.

Safe deposit contract. A sum of money must be spent somewhere before it can be spent freely after a time lock. During the time lock, the owner of the safe can interrupt the process with an emergency key and immediately transfer the funds to another place. This device can provide great help for autonomous custody.

Bitcoin Script currently does not have this capability, so enabling restrictions on Bitcoin Script would require 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 such functions at the RGB contract level - although it can only be effective for RGB assets that use it (and not for Bitcoin), it will undoubtedly open up an interesting space.

Existing studies on restriction clauses have shown that they can broaden the programming space of UTXO-based transactions and provide many features. However, these studies are basically based on Bitcoin, and we will be more conservative on protocols like Bitcoin. On RGB, we can boldly generalize the core capability 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.

Cross-access

The minimal restriction means that when a UTXO is spent, its script can read the output of the spending transaction. But the fully generalized restriction 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. If we do not restrict other inputs to come from the same contract, it means that it can read the status 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 status of two different contracts at the same time. If RGB transactions allow assets from two contracts to be spent at the same time, such cross-access capabilities may have application scenarios (although it is conceivable that it will make transaction verification more complicated).

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

in conclusion

In this article, readers will find that there is a concept that is frequently mentioned and runs through all the processes of reasoning and fantasy: "UTXO". This is exactly what I mean. If you don't understand UTXO, you can't understand the starting point of the design of a protocol like RGB, nor can you understand the advantages of the RGB protocol design, nor can you imagine how people use it. The characteristics of the RGB protocol are largely shaped by its one-time sealed form of UTXO. Accordingly, the research on UTXO accumulated in the field of Bitcoin research can also be applied to our research on RGB.

This also explains why people who don’t understand Bitcoin will find it difficult to understand RGB, while people who like Bitcoin will recognize the design that RGB has made.

Because the article has too many notes, see the link below for the source link