What is the real potential of RGB, the Bitcoin asset issuance protocol?
Original author: A Jian, Wu Shuo Blockchain
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 that it is very different from other protocols that aim to achieve the same or similar functions. These differences make the RGB protocol far more scalable than them and leave a wider programming space. In addition to introducing RGBs completed designs, we will also explore these programming possibilities.
What is RGB protocol?
The idea of issuing assets on Bitcoin has been around for a long time. But the Bitcoin protocol has its own characteristics: its state is expressed by and only by Bitcoin UTXO (unspent transaction output); a UTXO only carries two data: its own denomination (Bitcoin value), and a Script public key (also known as lock script), used to program the conditions for spending the funds, for example: providing a signature of a certain public key; the opcode that allows the programming of the lock script is determined by Bitcoins consensus rules provided that they cannot be used to implement arbitrary security rules. Therefore, it is not possible to create other assets inside UTXOs - 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 information about the steps that change the contract state - for example, contract A changes parameters, and B transfers a certain amount of an asset to C - Upload to the blockchain, so that the latest status of this smart contract system can be obtained by collecting this information.
A rough design idea is to upload the information of the steps that change the contract state to the Bitcoin blockchain intact. This can certainly work, but it will face several problems: (1) Since complete information is uploaded, it may consume more block space when the user needs to change the status of the contract (such as transfer) At this time, you will also need to pay more on-chain handling 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 expense of consuming more block space; (2) Almost anything within the block Information in one place may change the smart contract outside the chain. Therefore, users must obtain all Bitcoin block data to get the latest status of the off-chain contract system, that is, its verification cost is higher; (3 ) Depending on the design of the off-chain smart contract system, you may only be able to obtain privacy comparable to that of Bitcoin, or even worse; and if you can provide more privacy, you may need to consume 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 the hash value of the transaction. This approach solves the above problem 1 and decouples the complexity of off-chain contract transactions from its 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 There is no specific enhancement of privacy.
RGB uses a new paradigm called single-use seals. Its usage is very simple: RGB requires that every state of each contract must be attached to a certain Bitcoin UTXO; and once you want to change this state, you must spend this UTXO and let the transaction that spends it get the blockchains confirmation; in addition, the Bitcoin transaction that spends it must also provide a hash of the contents of the state transition to indicate the UTXO attached to the changed state.
To RGB developers, the design is similar to a numbered plastic seal: its easy to tell if its been removed, and once its removed, it cant be reused. However, another perspective is to regard the possessed UTXO as a container in this state or a ceramic piggy bank - if you want to take out the money in the piggy bank, you must break the piggy bank and then take out the money inside. Put the money in the new jar.
This design is in sharp contrast to previous protocols that treated 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 all blocks. All we need is a series of Bitcoin transactions, evidence that these Bitcoin transactions exist in a certain block, and these bits The RGB state conversion promised by the currency exchange (one-to-one pair with the relevant Bitcoin transaction) is enough. These data, which can be connected into a chain, should allow us to trace back to the initial state of this contract, allowing us to identify the essence of this state.
For readers who are familiar with on-chain smart contract systems (such as Ethereum), one thing that is difficult to understand about this process is that 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 each node), how is the security of this smart contract system guaranteed? How to ensure that the assets you receive are the ones you want, and how to 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, nodes verify each state transition operation according to the public state transition rules, reject invalid operations, and then calculate 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 based on the information provided by the payer. rule. In this way, the verifying party (assumed to be the recipient of the asset) can also detect illegal state transitions and refuse to accept them.
Finally, we use an example to demonstrate 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 went through a total of 5 previous owners (including the asset issuer) before reaching Alices hands. Therefore, Alice needs to provide Bob with evidence of these four state transitions (the first three of which were provided to Alice by the previous owner), including the initial state of the contract and the state transition rules, and the bits used for each transfer. Bitcoin transactions, the RGB transactions committed by each Bitcoin exchange, and the evidence that these Bitcoin transactions have been confirmed by a certain block are sent to Bob. Bob will verify that these four transfers do not violate the rules according to the state transition rules of the contract. , and then decide whether to accept it. When Alice constructs the RGB transaction, since Z is smaller than X, she also has 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 costs 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 a UTXO container). Moreover, for the owner P in the figure below, he will only know the process from the initial state G of the contract to reach him, that is, the process marked by the red circle, and will know nothing about the gray points:
RGB Advantages
cool verifiable status
As mentioned above, compared with the previous asset issuance protocols (off-chain contract systems) that appeared on Bitcoin, RGB significantly reduces the cost of verification (a certain state of a contract). During the transaction, the receiver no longer needs to traverse all blocks to collect information about changes in contract status, 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 in the block header), you can be sure that the payer really owns a certain amount of a certain asset.
This reduction in verification costs also greatly reduces users’ dependence (trust) on large infrastructure providers. In previous protocols, due to the high verification cost, 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 wallet); at the same time, because they could afford such There are fewer suppliers to calculate costs, which also means supplier centralization. But in RGB, users only need to use the Bitcoin light client to check the part of the transaction with Bitcoin and the RGB protocol to check the part of the RGB transaction, and they can afford it.
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; on those systems that are not based on UTXO, due to the lack of a mechanism to control access like UTXO, any transaction may change any state, so you It is almost impossible to specifically verify a certain state, but only to determine a certain state while calculating all the latest states - in this sense, the characteristics expressed as global state should actually be It is 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 on these on-chain contract protocols is to require block headers to commit to the latest state (state root), allowing light clients to verify a certain state of a contract obtained from the full node based on these commitments. . This is a method of reusing calculations that have already occurred (calculations that have been run by the full node), and it is also very efficient, so if trustlessness is not considered, it can be considered more efficient than RGB. However, it means after all that light nodes rely on full nodes for basic transaction verification and contract status calculation. In the RGB wallet that uses the Bitcoin light client, the trust assumption it relies on is that the relevant Bitcoin transaction is a valid transaction, and the part related to the contract status has been personally verified by the client, so it is more trust-free. . 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:
1. Embedded in the Bitcoin transaction is only a hash value, which means that there is no limit on the volume of the RGB transaction (except for the custom rules of the contract) - even if you divide one RGB asset into 100 parts (RGB The transaction itself will be very large) and there is only one hash that 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 will consume the on-chain space of a hash value; the other is to hide the script public key output by Taproot On the committed script tree - this does not consume any on-chain space. This also means that users do not have to sacrifice economics for programmability - only considering 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, which means concurrency is allowed. 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 get stuck, so it can also be regarded as a security benefit.
One point that has been criticized for RGBs scalability is that each transfer requires the recipient to verify all transactions involved from the initial state to the payer state - as the number of times the asset changes hands increases, the verification burden on subsequent recipients increases. It will get heavier and heavier. This criticism is true. And optimizing it means we also have to find a way to reuse operations that have already occurred. Proof system technologies such as SNARKs promise to provide such a solution.
Differentiation of asset definition and customs declaration mechanism
The last benefit is still related to UTXO and depends on how we understand the locking script mechanism of UTXO.
A locking script can be used to program the unlocking conditions for a fund and, therefore, it can implement custody rules. For example, if a locking script contains one and only one public key, that means that only the owner of the corresponding private key can control it. However, such custody rules are also the basis for Bitcoin contract protocol programming. 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 pay each other almost countless times without any change in the on-chain form of the funds. 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 form of funds on the chain.
Such a mechanism can be used for the Bitcoin value carried by UTXO. Naturally, it can also be used for the RGB assets carried by it. We can issue an RGB asset and attach it to a 2-of-2 multi-signature UTXO, thereby using the lightning channel mechanism to pay this asset to each other an unlimited number of times. In the same way, RGB assets can also be entered into other contracts based on Bitcoin scripts.
Here, the UTXO script and the RGB protocol form a functional differentiation: the former is committed to realizing 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 something that people are striving for in some other on-chain contract systems.
Designs already made by RGB
The above characteristics are actually true for all protocols based on UTXO one-time sealing and client verification. But on this basis, 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 aspects:
Blind UTXO. In an RGB transaction, the recipient only needs to use the obfuscated UTXO identifier to receive the asset without exposing the characteristics of the UTXO that actually received the asset. This does nothing to impair the recipients ability to provide evidence to the next owner, while enabling subsequent asset recipients to defend themselves against the prying eyes of the previous asset owner.
Bulletproof. Can be used to hide the specific amount in each transaction. However, subsequent asset owners can still verify that no additional issuance has occurred before.
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 RGB contract templates (schema) that have been proposed focus on asset issuance. However, since RGB uses the client-side validation paradigm, we can actually add any feature to it that can be ensured with client-side validation - only limited by the structure of UTXO.
Restrictions
On the basis of UTXO, a concept that can broaden programmability is called covenants. The original intention of a restriction clause is to limit the destination to which a sum of money can be transferred. With this ability, we can program many interesting applications, such as:
Fund pool for non-interactive withdrawals. We can pool the funds of many people in the same UTXO and use restriction clauses to ensure that any of them can withdraw their own funds without the help of others. This can have the effect of helping people exit high-risk places at low cost when demand for block space is high.
Vault Contract. A fund must first be spent somewhere and go through a time lock before it can be spent freely; during the time lock period, the safe owner can interrupt this process with an emergency key and immediately transfer the funds to another place. This device can be a great help for autonomous custody.
Current Bitcoin Script does not have this capability, so enabling restrictions on Bitcoin Script requires a soft fork.
However, as long as we are willing to sacrifice some of the benefits brought by differentiation of asset definition and custody mechanisms, we can experiment with such features on RGB assets, and we can implement such functions at the RGB contract level - although it can only Doesnt work for RGB assets that use it (and not Bitcoin), but will definitely open up an interesting space.
Existing research on restriction clauses shows that it can broaden the programming space of UTXO-based transactions and provide many features. But these studies are basically based on Bitcoin, and on protocols like Bitcoin, we will be more conservative. 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
Minimally restrictive terms mean that when a UTXO is spent, its script can read the output of the spending transaction. But a fully generalized constraint 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. If we do not limit other inputs to come from the same contract, it means that it can read the status of 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 a user to hold the status of two different contracts at the same time. If RGB transactions allowed the simultaneous spending of assets from both contracts, such cross-access capabilities might have applications (although it could conceivably make verification of transactions more complicated).
In fact, there are already on-chain contract systems based on UTXO similar structures (for example: Nervos Network), which use this to achieve cross-access capabilities of contracts11. This is a very new field, opening into areas rarely touched upon 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 used throughout all processes of reasoning and fantasy: UTXO. This is exactly my intention. If you dont understand UTXO, you cant understand the starting point of the design of a protocol like RGB, nor can you understand the advantages of RGB protocol design, nor can you imagine the way people use it. The characteristics of the RGB protocol are largely shaped by its one-time sealed form of UTXO. Correspondingly, the research on UTXO accumulated in the Bitcoin research field can also be applied to the research on RGB.
This also explains why people who don’t understand Bitcoin will have a hard time understanding RGB. People who like Bitcoin will recognize the design that RGB has made.
