What is the real potential of the BTC asset issuance protocol RGB?

Author**|**A Jian

Original link:

This article attempts to provide a succinct description of RGB, an asset distribution protocol on the BTC (which can also be understood as an off-chain smart contract system), and points out how it differs from other protocols that aim to achieve the same or similar functionality, which makes the RGB protocol far more scalable than they are, and leaves more room for programming. In addition to introducing RGB’s already completed designs, we’ll also explore these programming possibilities.

What is the RGB protocol?

The idea of issuing assets on BTC has been around for a long time. However BTC protocol has its own characteristics: its state is expressed by and only by BTC UTXOs (“unspent transaction outputs”), a UTXO carries only two pieces of data: its own denomination (BTC value), and a “script public key” (also known as a “lock script”) that is used to program the conditions under which the funds are spent, such as providing a signature for a public key, and opcodes that allow the locking script to be programmed are provided by the consensus rules of the BTC, which cannot be used to implement arbitrary security rules. As a result, it’s not possible to create other assets inside the UTXO — BTC scripts can’t program security checks for those assets. This means that all the idea of issuing assets on BTC is essentially a creative use of BTC block space. This means that we need to design an off-chain smart contract system and require that information about the steps that change the state of the contract - for example, contract A changes parameters, B transfers a certain amount of an asset to C - is uploaded to the blockchain, so that the latest state of the smart contract system can be obtained by collecting this information.

A crude design idea is to upload the information of the steps that change the state of the contract to the BTC blockchain intact. Of course, this can work, however, it will face several problems: (1) due to the upload of complete information, it may consume more block space, and when users need to change the state of the contract (such as transfers), they will also need to pay more on-chain fees. In particular, when we want such an off-chain contract system to have better programmability than BTC, the increase in programmability may come at the cost of consuming more block space: (2) the information almost anywhere in the block has the potential to change the off-chain smart contract, so the user must obtain all the BTC block data in order to get the latest state of the off-chain contract system, that is, it is more expensive to verify, (3) depending on the design of the off-chain smart contract system, it may only obtain the same or even worse privacy as BTC, and if it can provide more privacy, it may need to consume more block space。

In the past, a heavily used protocol called “Omni” did not upload the full information of off-chain contract transactions, only the hash of the transaction. This approach solves the above problem 1 by decoupling the complexity of off-chain contract transactions from its economic costs, but users still need to get the full amount of BTC block data to get the latest state of the Omni protocol, and it does not specifically enhance privacy.

RGB, on the other hand, uses a new paradigm called “single-use seals”. The way it works is simple: RGB requires that every state of each contract must be attached to a BTC UTXO, and once that state is to be changed, the UTXO must be spent so that the transaction that spent it is confirmed by the blockchain, and the BTC transaction that spends it must also provide a hash of the state transition to indicate the UTXO to which the changed state is attached.

In the eyes of RGB developers, this design is similar to numbered plastic seals: it’s easy to tell if it’s been removed, and once it’s removed, it’s no longer usable. However, the other way to look is to use the possessed UTXO as a container or a ceramic piggy bank in this state - to get the money out of the piggy bank, you have to break the piggy bank and put the money inside into a new one.

This design is in stark contrast to previous protocols that treat the entire block as a large letterboard: using UTXO as a container means that transactions that do not spend this UTXO cannot have any effect on the state of the contract in the container, so to verify a certain state of a contract, we don’t need to get all the block data, all we need is a series of BTC transactions, proof that these BTC transactions exist in a block, and these RGB BTC the exchange’s commitments State transitions (in pairs with related BTC transactions). This data, which can be concatenated into a chain, should allow us to trace back to the initial state of the contract, allowing us to identify the essence of this state.

For readers who are familiar with on-chain smart contract systems (such as ETH Fang), one of the things that is difficult to understand about this process is that if it does not depend 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 to ensure that the security of this smart contract system is guaranteed, how to ensure that the assets you receive are the kind you want, and how to ensure that the assets are not illegally issued?

The answer is simple, it’s called “client-side validation” – you verify it yourself. In the on-chain contract system, nodes verify each state transition operation and reject invalid operations according to the public state transition rules, so as to calculate the latest state according to the initial state. However, as long as the state transition rules and initial state are knowable, verification through on-chain consensus is not the only way, and users can verify that each step of the state transition follows the originally defined state transition rules based on the information provided by the payer. In this way, the verifying party (presumably the recipient of the asset) 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 asset Y of X units issued under the RGB license, and she wants to transfer Z units of Y to Bob. It took a total of 5 previous owners (including the issuer) of the assets to reach Alice. Therefore, Alice wants to provide Bob with evidence of these 4 state transitions (the first 3 of which were provided to Alice by the previous owner), including the initial state of the contract and the state transition rules, the BTC transactions used for each transfer, each RGB transaction committed BTC the exchange, and the evidence that these BTC transactions have been confirmed by a block, and send them to Bob, who will verify these 4 according to the state transition rules of the contract transfer without breaking the rules, and then decide whether to accept it or not. When Alice constructs an RGB transaction, since Z is less than X, she also arranges a UTXO for herself to receive the rest. Finally, Alice embeds the hash of the RGB transaction into the BTC transaction that costs UTXO A’ to complete the payment.

Eventually, thanks 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 yet (each point represents a state stored inside a 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 him, which is the process circled in red, and will not know anything about the gray dots:

Advantages of RGB

Cool Verifiable Status

As mentioned above, RGB significantly reduces the cost of validating (a certain state of a contract) compared to the asset issuance protocols (off-chain contract systems) that have previously emerged on BTC. At the time of the transaction, the receiver no longer needs to iterate through all the blocks to gather information about the change in the state of the contract, but only needs to obtain a series of BTC transactions, as well as the RGB transactions promised by these exchanges, and the block containing evidence of these BTC transactions (according to the Merkle proof of the block header), to be confident that the payer really owns a certain amount of a certain asset.

This reduction in the cost of verification also greatly reduces the user’s dependence (trust) on large infrastructure providers. In previous protocols, due to the high cost of verification, it was difficult for users to calculate the latest state of the contract by themselves, so users had to trust some vendors (such as the contract state provider used by their wallets), and at the same time, because there were fewer suppliers who could bear such computational costs, which also meant that the vendor was centralized. However, in RGB, users only need to use BTC light client to check the part of the transaction with the BTC, and use the RGB protocol to check the part of the RGB transaction, and they can afford it.

Compared to 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, while on systems that are not based on UTXOs, due to the lack of a mechanism to control access such as UTXOs, any transaction can change any state, so it is almost impossible to verify a certain state in a targeted manner, but can only determine a certain state while calculating all the latest states - in this sense, the feature expressed as a “global state” should actually be called " uniform state", although it provides cross-access between contracts, it also determines that it will be more expensive to verify and more difficult to obtain trust-free.

A significant optimization on these on-chain contract protocols is the requirement for block headers to commit to the latest state (“state root”), allowing light clients to validate a certain state of a contract from full nodes against these commitments. It’s a way to reuse computations that have already happened (computations that have already been run by a full node), and it’s also very efficient, so it can be considered more efficient than RGB if trustlessness is not taken into account. However, it does mean that light nodes rely on full nodes for transaction base verification and contract state calculation. In an RGB wallet that uses a BTC light client, it relies on the trust assumption that the transaction is relevant BTC transaction is valid, and the part related to the state of the contract is verified by the client himself, so trustlessness is better. The disadvantage is that the verification delay is longer and more data needs to be kept.

Scalability

RGB’s scalability is twofold:

1. Only one hash is embedded in BTC transaction, which means that there is no limit to the size of the RGB transaction (other than the rules customized by the contract) - even if you divide one RGB asset into 100 (the RGB transaction itself will be very large), there is only one hash that needs to be embedded in BTC transaction. As noted in Note 6, there are two ways to embed such a hash: either by using the OP_RETURN output, which means that it consumes one hash of on-chain space, or by hiding it in the script tree promised by the script public key of the Taproot output - which does not consume any on-chain space. This also means that users don’t have to sacrifice economics for programmability – just on-chain fees.

2. 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 without affecting each other, that is, concurrency is allowed. This is actually a feature inherited from UTXO as well. This also means that invalid changes (invalid transactions) that occur on one branch will not affect the other branches, let alone cause the entire contract to freeze, so it can also be considered a security benefit.

RGB has been criticized for its scalability: with each transfer, the recipient needs to verify all the transactions involved from the initial state to the payer state - as the number of asset transfers increases, the verification burden on subsequent recipients increases. This criticism is true. Optimizing it means finding a way to reuse computations that have already occurred. Proof system technologies, such as SNARKs, are expected to provide such a solution.

Differentiation of asset definition and customs declaration mechanism

The last benefit is still related to UTXOs, depending on how we understand UTXO’s locking scripting mechanism.

A locking script can be used to program the conditions under which a fund will be unlocked, so it can implement custodial 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 custodial rules are also the basis for BTC contractual protocol programming. For example, a UTXO that uses a 2-of-2 multi-signature locking script could be a lightning channel, and during the channel’s operation, two parties can pay each other almost an infinite number of times without any change in the on-chain form of the funds. In other words, at this point, the 2-of-2 multi-signature locking script constitutes a value transfer mechanism that allows both parties to transfer value without changing the form of on-chain funds.

Such a mechanism can be used for the value of the BTC carried by the UTXO and, naturally, for the RGB assets it carries. We can issue an RGB asset and attach it to a 2-of-2 multi-signature UTXO, using the mechanism of the lightning channel to pay each other an unlimited number of times. Similarly, RGB assets can also be used in other BTC script-based contracts.

Here, UTXO’s scripts and RGB protocols form a functional differentiation: the former focuses on implementing the rules of value custody and value 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 security improvement, and one that people are looking for in some other on-chain contract systems.

RGB has been designed

The above features are true for virtually all protocols based on UTXO one-time sealing and client-side verification. But on top of that, the RGB protocol has been further designed.

In the current development of the RGB protocol, developers are particularly concerned about the privacy of the protocol, so RGB strengthens privacy in two ways:

• Blinded UTXOs. In an RGB transaction, the receiver only needs to use the obfuscated UTXO identifier to receive the asset, without exposing the characteristics of the UTXO that actually receives the asset. This in no way compromises the recipient’s ability to provide evidence to the next owner, while at the same time allowing subsequent recipients of the asset to defend themselves against the prying eyes of the previous asset owner.
• Bulletproof。 It can be used to hide the exact amount in each transaction. However, subsequent asset owners can still verify that there has been no additional issuance before.

Explorable Space

In this part, I’m going to talk about the areas where the RGB protocol can continue to explore, mainly related to programmability.

At present, the proposed RGB contract templates (schemas) are focused on asset issuance. However, since RGB uses the “client-side validation” paradigm, in fact, we can add anything to it that can be ensured by client-side verification - limited only by the UTXO structure.

Restrictions

On top of UTXOs, a concept that broadens programmability is called “covenants”. The original intention of the restriction clause is to limit the destination where a sum of money can be transferred. With this ability, we can program many interesting applications, such as:

• Pools of funds for non-interactive withdrawals. We can pool many people’s funds in the same UTXO and use restrictions to guarantee that no one of them can withdraw their own funds without the help of others. This can serve to help people exit from high-risk places at a low cost when the demand for block space is high.
• Vault contract. Make a fund have to go somewhere, pass through a timelock before you can spend it freely, and during the timelock, the vault owner can interrupt the process with an emergency key and immediately move the funds somewhere else. Such a device can be of great help for self-storage.

Current BTC scripts don’t have this capability, so enabling restrictions on BTC scripts requires a soft fork.

However, as long as we are willing to sacrifice some of the benefits of the “asset definition and custody differentiation”, we can experiment with such a feature on RGB assets, and we can implement this functionality at the level of RGB contracts - although it can only work for the RGB assets that use it (and not BTC), but it will undoubtedly open up an interesting space.

Studies of existing restrictions have shown that it broadens the programming space for UTXO-based transactions, offering a number of features. But these studies are basically based on BTC, and we would be a little more conservative on BTC protocols like this. On RGB, we can boldly generalize the core capability of the restriction clause – the ability to read transactions that cost itself at the script level – to provide more flexible programmability: the ability to cross-access contracts.

Cross Access

The minimal restriction clause means that when a UTXO is spent, its script can read the output of the spending transaction. But a fully generalized restriction means that it can read all parts of the transaction that cost it. This means that it can also read the other inputs of the transaction, and if we don’t limit the other inputs to the same contract, it means that it can read the state of the other contracts.

In RGB, we default that each contract is an independent universe with its own directed acyclic graph. However, it is still possible for one user to hold two different contracts at the same time. If RGB transactions allow assets from both contracts to be spent at the same time, such cross-access capabilities may have a use case (although it is conceivable that it would complicate the verification of transactions).

In fact, there are already on-chain contract systems based on UTXO-like structures (e.g., Nervos Network) that use this to achieve cross-access capabilities for contracts11. This is a very new field, opening up to areas that have rarely been touched by previous BTC studies, and there may be some surprises buried in it.

Conclusion

In this article, the reader will notice that there is one concept that is frequently mentioned throughout the process of reasoning and fantasy: “UTXO”. That’s exactly what I intended. If you don’t understand UTXO, you can’t understand the starting point of the design of a protocol like RGB, the advantages of RGB protocol design, and the way people can use it. The nature of the RGB protocol is largely shaped by its UTXO, a form of one-time seal. Correspondingly, the research on UTXOs accumulated in BTC research field can also be applied to the research of RGB.

This also explains why people who don’t understand BTC, will have a hard time understanding RGB. And those who like BTC will recognize the designs that RGB has already made.