BiHelix RGB V0.11 Version Preview: Asset Issuance Overview
Author: Zoom, Echo, BiHelix
Introduction
With the proposal of the RGB++ scheme by Nervos co-founder Cipher, discussions and debates around the native RGB protocol have been growing in the market. RGB, as a scalable and confidential Bitcoin and Lightning Network smart contract system developed by the LNP/BP Standards Association, has always been favored by Bitcoin ecosystem developers and is seen as a significant potential component of the BTC native expansion protocol. As the infrastructure for Bitcoin decentralized finance (BTCfi) and applications (DApps), RGB marks a historic milestone in expanding Bitcoin's utility from a single value storage function to a broader range of fields. The technological innovations it leads are not only exciting but will also bring new development directions and possibilities to the entire cryptocurrency ecosystem.
At the end of 2023, the native RGB team, the LNP/BP Standards Association, announced that RGB will soon upgrade and release version 0.11 to better meet market challenges and promote the vigorous development of the Bitcoin ecosystem. This article will detail the features and technical foundations of the RGB v0.11 protocol upgrade, providing a comprehensive overview of the asset generation and transaction functionalities supported by RGB v0.11, including the adoption of trusted proof consensus, scalability optimizations, and key security enhancements. We delve into the fundamental principles and trade-offs of proof of belief compared to existing consensus schemes, as well as the quantitative benchmarks for gas savings and throughput increases unlocked by proof v0.11.
RGB Asset Generation
Currently, the RGB protocol version 0.11 includes three built-in asset types: RGB20 (tokens), RGB21 (NFTs), and RGB25. Taking RGB20 as an example, we discuss the implementation steps and executable rights of the current protocol.
- First, the issuer of the contract needs to set the initial state of the RGB token according to the RGB20 protocol, such as defining the contract details: asset name, initial issuance, total supply, issuance rights, renaming, destruction rights, etc.
- Next, the contract issuer designates a UTXO to receive the initial issuance, thereby creating a simple RGB asset. The state changes can apply to the rights of changing asset ownership or other types of rights. For example:
- Issuance interface: When the contract opens the issuance rights, an address must be specified to receive the newly issued assets. Of course, RGB20 limits the upper limit of issuance, and the contract issuer cannot issue endlessly.
- Destruction interface: The contract issuer can designate one or more individuals with the right to destroy tokens. Since RGB20 adopts P2P transactions (which will be introduced in the transaction section), it is difficult for users to send tokens to a black hole address for destruction.
- Renaming interface: The contract can update the asset name.
Since the RGB contract code is stored off-chain, if the contract issuer does not authorize open-source access, it is challenging for users to verify asset information. Once an RGB contract is issued, both users and issuers must adhere to the state definitions at the time of issuance, preventing malicious behavior by the issuer.
RGB Asset Transfer
The transaction model of RGB adopts P2P (Peer to Peer) transfers, which is quite different from ETH. This transfer model requires both parties to be online. For example, the operation "A wants to send 100 tokens to B" proceeds as follows:
- B creates an invoice specifying the sending of 100 tokens.
- The recipient A initiates the transfer.
- B confirms the transfer and signs it.
- A broadcasts the transaction.
- A and B accept the transaction.
In this process, B sends the invoice to A, and upon receiving the invoice, A can only comply with the invoice content to send 100 tokens to B. B needs to confirm that they have received the 100 tokens for the transaction to be successful.
- Q: Why do both parties need to be online?
- A: Because the invoice has a time limit; if not used within a certain period, it becomes invalid. Therefore, A must transfer immediately after receiving B's invoice. B must also ensure that the invoice can be used by A immediately before creating it. This constrains both parties to complete the transfer within the invoice's validity period.
Figure: Lightning Network Channel Transaction
Since the transaction channels used by RGB are integrated with the Lightning Network, the transaction process can refer to the transfer process of the Lightning Network, with the addition of the step "requiring the payee to confirm again." This transaction step ensures that the payee does not receive random phishing coins, thus protecting user wallet security.
RGB Asset Trading
Technical Points in the RGB Asset Transfer Process
- One-Time Seal
This technology was first proposed by Peter Todd in 2016, meaning "to attach a seal to a message, ensuring that the message can only be used once, as you must break the seal to know the message."
A simple method is to set up a notarized third-party service that publishes a certificate in a public registry whenever a seal is opened or locked, allowing anyone to verify the status of the seals they care about.
If a trusted entity is not used to implement the one-time seal function, Bitcoin's UTXO can be used as a seal. Since any UTXO in Bitcoin can only be spent once, using UTXO as a seal allows it to be locked when created and opened when spent.
RGB utilizes this "one-time seal" technology, wrapping the information of RGB assets, contract states, etc., inside the UTXO. When the UTXO is spent, the ownership of the asset and the contract state change. This means that every time an RGB transaction occurs, it is essentially a state change created by the sender to a specific contract (which defines the rights being transferred).
- Client Verification
RGB's verification differs from traditional "global consensus" verification, adopting "client verification" technology. In traditional Bitcoin verification methods, a node connected to the network continuously downloads and verifies blocks and transactions in the transaction pool (full node). Such nodes maintain a real-time updated view of the UTXO set (the collection of all unspent outputs on the blockchain). When it sees a new transaction, it only needs to verify that all inputs of that transaction are part of the latest state of the UTXO set to validate its validity.
However, for RGB, there is no globally propagated data, and thus no global view of the UTXO set. After an RGB client receives a transaction, it must not only verify that the latest state of the transaction is valid but also perform the same verification for all past state transitions related to the transaction, tracing back to the initial state of the issuing contract. This may seem to present a significant drawback: leading to long verification times. However, this only occurs when "an asset has a long transaction history," and can be pre-validated through a data sharing layer (voluntarily) to expedite the verification of this portion of transaction history.
This also brings a significant advantage: clients do not need to know or verify all transactions occurring globally. They only need to know the transactions related to their own wallets, and they do not need to verify other transactions, thus reducing the amount of data each client needs to verify, significantly enhancing system scalability. The issue of clients verifying the complete chain has been thoroughly resolved by BiHelix through a recursive zero-knowledge proof scheme.
- Deterministic Bitcoin Commitment
RGB prevents "double spending" through RGB commitments. Such commitments need to achieve:
- Multiple state transitions involving the contract can be committed to a single Bitcoin transaction.
- Each state transition of the contract can only be committed to a Bitcoin transaction once.
The specific implementation method is:
- First, all state transitions related to a specific contract (or asset ID) must be deterministically aggregated into a commitment.
- Then, the commitments of all transferred assets must be aggregated into a Merkle tree.
- The final root hash is the ultimate RGB commitment.
- To ensure compatibility with other unrelated RGB protocols that also require deterministic Bitcoin commitments, RGB commitments and commitments from other protocols must be aggregated again (as described in the LNPBP-4 standard). The resulting hash is the message actually embedded in the Bitcoin transaction.
- Batch Processing to Reduce Costs
From the previous section, we can see that we can "wrap" any number of state changes into a single Bitcoin commitment, theoretically achieving large-scale batch processing, thus providing more application scenarios for UTXO service providers.
- Scenario: A wants to pay multiple people at once, transferring an RGB20 asset to B, an RGB21 asset to C, and transferring ownership of a contract to D.
- Result: A only needs to create one state transition for B, C, and D, and commit all state transitions to the same Bitcoin transaction without occupying more bytes. This means that state changes of different statuses, because they are wrapped in a single commitment, achieve batch processing. The marginal cost of on-chain fees for each RGB payment can be very low, as the same fee is shared across any number of transfers.
There are also limitations, namely: these state transition information must be "wrapped" in the same UTXO. If there are multiple UTXOs, it will require adding inputs to this transaction, which will increase corresponding costs. However, compared to the traditional case where each state change requires a separate transaction, significant improvements can already be achieved.
- Communication Between Clients
Client communication is common in the implementation process of an RGB transfer. The sender needs to share a "consignment" with the receiver(s), a data structure that contains all the information needed to verify the transfer, including all state transitions traceable to the contract's initial state, which needs to be transferred from the sender to the receiver through communication. However, in the RGB protocol, there are no restrictions on communication channels, and multiple data sharing methods are available. Two common methods for sharing data are:
- Storm: A peer-to-peer instant communication and storage system based on the Lightning Network.
- RGB Proxy Server: A standardized HTTP JSON-RPC server that allows clients to upload and download data. Users can run their own proxy servers or use third-party servers. Relying on third-party servers may affect privacy and censorship resistance but does not compromise security.
Client communication has also been optimized by BiHelix through an adaptive communication protocol.
Conclusion
Although the current RGB v0.11 version is still in the Beta stage, it is not difficult to see that numerous RGB ecosystem project teams are actively contributing their efforts to collaboratively advance the fine-tuning of version 0.11. As advocates of the RGB ecosystem project and the RGB protocol, the BiHelix team has been fully committed to realizing the engineering and commercialization of the RGB protocol. Accelerating the compatibility of the Lightning Network and the RGB protocol while actively attracting more high-quality application ecosystem developers to deeply learn and apply the RGB protocol will be their primary goal.
It is believed that the increasingly mature asset issuance functionality of the RGB protocol will bring more innovations to the Bitcoin ecosystem, once again elevating the entire Bitcoin ecosystem to new heights. With the widespread application of the RGB protocol in the Bitcoin network, this article will also serve as an indispensable reference for understanding the mechanisms and designs behind RGB. In this vibrant ecosystem, the prospects for RGB appear bright, injecting new vitality and possibilities into the evolution of Bitcoin.