RGB V0.11版本发布路线图揭晓：探秘资产发行概要

Currently, the RGB protocol version 0.11 embeds three asset types, including RGB 20 (tokens), RGB 21 (NFTs), and RGB 25. Taking RGB 20 as an example, we discuss the implementation steps and executory rights of the current protocol.

1. First, the issuer of the contract needs to set up the initial state of the RGB token according to the RGB 20 protocol, such as defining the contract's details: asset name, initial supply, total supply, minting, renaming, burning, and other permissions.

2. Then, the contract issuer specifies a UTXO to receive the initial supply, thus creating a simple RGB asset. State transitions can be applied to changing ownership rights of assets or other types of rights. For example:

• Minting interface: When the contract enables minting permissions, an address needs to be specified to receive the minted assets. However, RGB 20 restricts the upper limit of minting, and the contract issuer cannot mint infinitely.

• Burning interface: The contract issuer can specify one or multiple individuals with burning permissions for the tokens. As RGB 20 adopts P2P transactions (to be introduced in the transactions section), it is difficult for users to send tokens to a black hole address for burning.

• Renaming interface: The contract allows for updating the asset name.

Since the RGB contract code is stored off-chain, if the contract issuer does not authorize open-source, it is difficult for users to verify asset information. Once the RGB contract is issued, both users and issuers must abide by the state definition at the time of issuance to prevent malicious behavior from the issuer.

RGB Asset Transfer

RGB's transaction model adopts Peer to Peer (P2P) transfer, which is quite different from ETH's. This transfer mode requires both parties to be online. As an example,"A wants to send 100 tokens to B. The operation is as follows:

1. B creates an invoice specifying the transfer of 100 tokens.

2. Receiver A requests the transfer.

3. B confirms and signs the transfer.

4. A broadcasts the transaction.

5. A and B acknowledge the transaction.

In this process, B sends the invoice to A, and once A receives the invoice, they must comply with the invoice and send 100 tokens to B. B needs to confirm that they have received the 100 tokens for the transaction to be successful.

• Q: Why does both parties need to be online?

• A: Because the invoice has a time limit, it becomes invalid if not used within a certain period. Therefore, A must transfer the tokens immediately upon receiving B's invoice. B also needs to ensure that the invoice can be immediately used by A before creating it. This imposes the requirement for both parties to complete the transfer within the validity period of the invoice.

Figure: Lightning Network Channel Transaction

Because the transaction channel used by RGB integrates the Lightning Network, the transaction process can refer to the transfer process of the Lightning Network, with the addition of a step for the "receiver's confirmation." This transaction step ensures that the receiver does not receive miscellaneous and fraudulent tokens, thus protecting the security of user wallets.

RGB Asset Transaction

Technical Points in the RGB Asset Transfer Process

1.  One-time Sealing

This technique was first proposed by Peter Todd in 2016. The main idea is to "attach a seal to a message to ensure that the message can only be used once, as you need to remove the seal to know the message."

One simple method is to set up a notarized third-party server that publishes a certificate in a public registry whenever a seal is opened or locked. This way, anyone can verify the status of the seal they are concerned about.

If there is no trusted entity to achieve one-time sealing, Bitcoin's UTXO can be used as a seal. Because any UTXO of Bitcoin can only be spent once. Therefore, using UTXO as a seal, it can be locked when the UTXO is created and opened when it is spent.

RGB utilizes this "one-time sealing" technique by "wrapping" the information of RGB assets and the state of contracts inside UTXOs. When a UTXO is spent, the ownership of the assets and the state of the contracts undergo a transformation. This means that whenever an RGB transaction occurs, it is actually a sender creating a state change for a contract (the one that defines the right being transferred).

2. Client Verification

RGB's verification is different from the traditional "global consensus" verification. It adopts the technique of "client verification." In the traditional Bitcoin verification method, a node connected to the network continuously downloads and verifies blocks and transactions in the transaction pool (full node). Such a node has a real-time updated view of the UTXO set (the set of all unspent outputs on the blockchain). When it sees a new transaction, it only needs to verify that all inputs of the transaction are part of the latest state of the UTXO set.

However, for RGB, there is no globally propagated data, so there is no global view of the UTXO set. After an RGB client receives a transaction, it not only needs to verify that the latest state of the transaction is valid but also needs to verify all past state transitions related to the transaction, tracing back to the initial state of the issuance contract. This seems to bring an obvious drawback: it leads to long verification time. However, this only happens when "an asset with a long transaction history" is involved, and this part of transaction history can be verified in advance through a data sharing layer (voluntarily).

It can bring several benefits at the same time: The client does not need to know or verify all the transactions happening globally. It only needs to know the transactions related to its own wallet, and it does not need to verify other transactions, so each client needs to verify less data, significantly enhancing the system's scalability. The problem of client verification of the complete chain is completely solved by BiHelix's proposal of recursive zero-knowledge proof.

3. Deterministic Bitcoin Commitments

RGB prevents "double spending" by implementing RGB commitments. Such commitments need to achieve:

• Multiple state transitions involving contracts can be committed to a single Bitcoin transaction

• Each contract state transition can only be committed to a Bitcoin transaction once

The specific implementation is as follows:

1. First, all state transitions related to a contract (or asset ID) need to be deterministically aggregated into a commitment.

2. Then, commitments of all transferred assets need to be aggregated into a Merkle tree.

3. The final root hash is the final RGB commitment.

4. In order to ensure compatibility with other protocols that require the use of deterministic Bitcoin commitments but are unrelated to RGB, the RGB commitment and commitments of other protocols need to be aggregated again (as described in LNPBP-4 standard). The resulting hash value is the message actually embedded in the Bitcoin transaction.

4. Batch processing reduces costs

As mentioned earlier, we can "package" any number of state changes into a single Bitcoin commitment, theoretically achieving large-scale batch processing, thereby providing more application scenarios for UTXO service providers.

• Scenario: A wants to make payments to multiple people simultaneously, transfer an RGB 20 asset to B, transfer an RGB 21 asset to C, and transfer ownership of a contract to D

left;">• Result: A only needs to create a status transition for B, C, and D respectively, and all the status transitions can be committed to the same Bitcoin transaction, without occupying more bytes. This means that the state changes of different states are batch-processed because they are wrapped in one commitment.The on-chain transaction fee marginal cost for each RGB payment can be very small because the same transaction fee is shared by any number of transfers.

There are also limitations here: these state transition information must be "wrapped" in the same UTXO. If there are multiple ones, then the inputs of this transaction need to be increased, and the corresponding costs will also increase. However, compared to the case where a separate transaction is required for each state change in traditional methods, there has been a great improvement.

5. Communication between clients

Client communication is common in the implementation process of an RGB transfer. The sender needs to share the "consignment" with the recipient(s), which is a data structure that contains all the information required to validate the transfer, including all the state transitions that can be traced back to the contract's initial state, and needs to be transferred from the sender to the recipient(s) through communication. However, in the RGB protocol, communication channels are not restricted, and there are multiple ways to share data. The two common methods of sharing data are:

• Storm: a peer-to-peer instant messaging and storage system based on the Lightning Network.

• RGB proxy server: a standardized HTTP JSON-RPC server, whose clients can upload and download data. Users can run their own proxy server or use a third-party server. Depending on a third-party server will affect privacy and resistance to censorship, but not security.

The client communication BiHelix also proposes an adaptive communication protocol for optimization.

Conclusion

Although the current RGB v0.11 version is still in the Beta stage, we can see that many RGB ecosystem project teams are actively contributing to it, working together to promote the fine optimization of the v0.11 version.As advocates of the RGB ecosystem projects and the RGB protocol, the BiHelix team has been working hard to achieve the realization of RGB.; Engineering and commercial landing of the agreement. Accelerate the compatibility of the Lightning Network and RGB protocol, and actively attract more high-quality application ecosystem developers to deeply learn and apply the RGB protocol will be its primary goal.

Believe that the more mature asset issuance function set of the RGB protocol will bring more innovation to the Bitcoin ecosystem and once again push the entire Bitcoin ecosystem to new heights. With the widespread application of the RGB protocol in the Bitcoin network, this article will also become an indispensable important reference material for understanding the mechanism and design behind RGB. In this vibrant ecosystem, the future of RGB looks bright, injecting new vitality and possibilities into the evolution of Bitcoin.