|
|
Edited by Iti9 at 25-12-2023 01:03 PM
Recently, there has been increasing interest in tokens based on Bitcoin and the Lightning Network. The idea of creating tokens to represent assets is not new, with protocols like Counterparty and OmniLayer (formerly Mastercoin) pioneering the concept in 2013, later adopted by Ethereum and other altcoins. However, using altcoins to secure financial assets is not ideal due to their inability to provide the same level of security and decentralization as Bitcoin. For this reason, over the years, projects have emerged aiming to modernize token protocols on the Bitcoin network and make them compatible with the Lightning Network, such as RGB, OmniBolt, and the recent Taro. This article will focus on RGB, providing a comprehensive overview of its workings and value propositions.
1. **Token Heritage on the Bitcoin Protocol**
Old Bitcoin-based token protocols, like Counterparty and OmniLayer, ""color"" Bitcoin transactions by embedding metadata, signaling that they should be considered token transfers. This signal often occurs in OP_RETURN outputs, ignored by regular Bitcoin nodes but interpretable by token protocol-aware nodes, which then enforce token protocol validation rules.
While effective, this design has drawbacks:
- The amount of information related to token transfers is limited by the byte size of OP_RETURN outputs (standardized at 80 bytes), sufficient for basic transaction data encoding but not for more complex use cases.
- Token protocol nodes must scan the entire blockchain to find token transfers relevant to users in OP_RETURN outputs, becoming more resource-intensive as the blockchain grows.
- Privacy protection for users is poor since all transaction data is visible to anyone on the chain, and the anonymity of the tokens you use may be significantly weaker than that of Bitcoin.
2. **Off-Chain Transfers**
To improve this design, the RGB project proposes a more scalable, privacy-aware, and future-oriented solution based on client-side validation and the concept of single-use seals introduced by Peter Todd in 2017.
The core idea is to use the Bitcoin blockchain only when necessary, leveraging its proof-of-work and decentralized network properties for double-spending protection and censorship resistance. All token transfer verification work can be moved out of the global consensus layer and maintained in an off-chain form, delegated only to the client receiving payment.
How does this work? In RGB, tokens essentially always need to be assigned to Bitcoin UTXOs (existing or specially created). To transfer tokens, you need to spend such UTXOs. When spending a UTXO, the Bitcoin transaction must include a message commitment, promising that the message contains RGB payment information, input definition, the Bitcoin UTXO to which the token will be sent, asset ID, amount, spending conditions, and any additional data you may want to attach.
Therefore, to transfer RGB tokens assigned to Bitcoin UTXOs, a Bitcoin transaction is necessary. However, the output of an RGB transfer does not need to match the output of a Bitcoin transaction! As seen in the example above, an RGB transaction can output a UTXO entirely unrelated to the Bitcoin transaction submitted to it. This means RGB tokens can be ""teleported"" from one UTXO to another without leaving any trace in the Bitcoin transaction graph—a significant privacy advantage!
In this design, Bitcoin UTXOs are used as one-time seals containing RGB assets, and to transfer assets, you essentially need to break the old seal and apply a new one.
RGB-specific payment data is transmitted from the payer's client to the payee's client through a dedicated communication channel, ensuring compliance with RGB protocol rules. This way, blockchain observers cannot extract any information about RGB user activity.
Unfortunately, verifying received payments is not enough to ensure that the sender is the true owner of the assets just sent to you. To consider received payments as final, you must receive all transaction histories related to the tokens from the payer, all the way back to the initial issuance. By verifying all transaction histories, you can ensure that the assets have not inflated, and all spending conditions related to the assets have been adhered to.
This design aids scalability since you don't have to verify the entire history of the assets, only those transactions relevant to you. Additionally, transactions are not broadcast to the global ledger, enhancing privacy because fewer people know about your transactions.
3. **Blinding Secrets**
To further enhance privacy, RGB supports blinding outputs, meaning that when requesting payment from someone who needs to pay you, you do not disclose the UTXO to receive the tokens. Instead, you ask the payer to send the tokens to a hash value, generated by connecting the UTXO to a random blinding key. This way, the payer does not know the UTXO receiving the tokens, preventing exchanges or other service providers from knowing if they are facilitating the withdrawal of a UTXO blacklisted by a regulatory authority or monitoring when the tokens will be spent in the future.
Note that when paying with tokens, the blinding key must be revealed to the recipient so they can verify all Bitcoin transactions in the transaction history. This means that with RGB, you currently have complete privacy when receiving and holding tokens, but the confidentiality of your past financial activities will decrease over time as the tokens transfer among people, approaching the privacy level of our past Bitcoin transaction history.
4. **Lightning Network Compatibility**
Since RGB is built on Bitcoin, RGB tokens can also be transferred to the Lightning Network, and some research has been done on this issue. The Lightning Network is a scalability solution based on payment channels, requiring some effort to ensure good channel liquidity for various assets. This can be achieved through widespread adoption of assets or by directly connecting channel management software to nodes supporting assets of interest, creating a specific asset subnetwork.
Another solution for making less popular assets feasible on the Lightning Network is to introduce nodes providing exchange services between specific assets and Bitcoin. Once exchanged for Bitcoin, the value can flow through the network using Bitcoin's liquidity. When reaching the other end of the path, another exchange node converts the Bitcoin back into the original asset. This eliminates the need for a specific liquid asset network. However, to make this a reality, the trading volume of each asset with Bitcoin needs to be sufficiently large to incentivize market makers to operate trading nodes across the network, providing a low enough bid-ask spread to avoid losing too much value from payments between two transactions.
5. **Advanced Smart Contracts**
By using Bitcoin transactions, RGB automatically inherits all smart contract functionalities of Bitcoin but goes beyond! When transferring tokens to a counterparty, you can define additional spending conditions that the counterparty must meet in the future. These additional spending conditions are not enforced by the global consensus of the blockchain but by the RGB node verification process. This means that if someone attempts to spend tokens without adhering to RGB-specific spending condition rules, the recipient's node will fail to verify successfully and consider the payment not final, which is particularly bad for the sender. In fact, while the RGB payment fails, the Bitcoin transaction spending the UTXO (to which the tokens are assigned) may have been confirmed on the blockchain, meaning these tokens will no longer be assigned to any UTXO and can be considered "burnt." This dynamic factor needs to be considered when writing RGB smart contracts.
Another trade-off to note is that, while RGB contracts can offer more privacy and scalability than any alternative, their state is not globally accessible, and they cannot be ownerless (as seen in other blockchains). For some use cases, this also represents a certain degree of limitation.
Due to the client-centric |
|
Post time 13-11-2023 20:36:21