By Federico Tenga, Bitfinex RGB Team Member, Iris Wallet Developer; Translation: Golden Finance xiaozou
Recently, there has been a growing interest in comparing Bitcoin-based and Lightning Network-based tokens. The idea of creating tokens to represent assets that can be transferred and stored safely and conveniently, just like Bitcoin, is not new. Indeed, in 2013, protocols such as Counterparty and OmniLayer (formerly Mastercoin) had pioneered the idea, which was later adopted by Ethereum and other altcoins. However, using altcoins to secure financial assets is not ideal, as they do not offer the same level of security and decentralization as Bitcoin. For this reason, there have also been projects over the years that have emerged in an attempt to modernize the token protocol on the Bitcoin network and make it compatible with the Lightning Network, specifically RGB, OmniBolt and most recently Taro. This article will focus on RGB, providing a comprehensive overview of how it works and its value proposition.
1, Token Legacy on the Bitcoin Protocol
Old Bitcoin-based token protocols, such as Counterparty and OmniLayer, “colored” it by putting metadata into Bitcoin transactions and signaling that it should be considered a token transfer. This signal usually occurs in the OP_RETURN output, which is ignored by a normal Bitcoin node, but can be interpreted by a token protocol-aware node, which then enforces the token protocol validation rules.
! [mWMQA4cCFyxXoXu0rU5vn5oBWdvOm88zGE9uQMCV.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-609dae0ddc-dd1a6f-cd5cc0.webp “7133079”)
While this design is effective, there are some drawbacks:
· The amount of information related to the token transfer is limited by OP_RETURN output bytes, which is 80 bytes according to standard rules, which is sufficient for basic transaction data encoding, but not enough to support more complex use cases.
· Token protocol nodes need to scan the entire blockchain for token transfers that may be relevant to users in OP_RETURN output, a process that becomes more resource-intensive as the blockchain grows in size.
· The privacy protection for users is terrible because all transaction data is visible to anyone on the chain, and the anonymity of the token you use may be orders of magnitude weaker than the Bitcoin you normally use.
2, off-chain transfers
To improve this design, the RGB project proposed a more scalable, privacy-conscious, and future-proof solution based on the concept of client-side verification and single-use seals, which was originally proposed by Peter Todd in 2017.
At the heart of the idea is the idea of using the Bitcoin blockchain only when it has to, i.e., using its proof-of-work and decentralized nature of the network for double-spend protection and censorship resistance. All token transfer verification work can be moved off the global consensus layer and maintained off-chain, delegating it only to clients who receive payments.
How does it all work? In RGB, basically tokens always need to be allocated to Bitcoin UTXOs (already existing or specially created), and in order to transfer tokens, you need to spend such UTXOs. When spending UTXOs, Bitcoin transactions must include a message promise that the message contains RGB payment information, definition inputs, the Bitcoin UTXO the token will be sent to, the asset id, amount, spending conditions, and any other additional data you may want to attach.
! [LnBQoqrWgI47Ivmp7lSrEoRoyGV4VefYNgqG3gR6.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-ec28de3486-dd1a6f-cd5cc0.webp “7133083”)
Therefore, to transfer RGB tokens allocated to Bitcoin UTXOs, Bitcoin transactions must be required. However, the output of an RGB transfer does not need to be the same as the output of a Bitcoin transaction! As we saw in the example above, an RGB transaction can output a UTXO that is completely unrelated to the Bitcoin transaction submitted to it. This means that RGB tokens can be “transferred” from one UTXO to another without leaving any trace in the Bitcoin transaction graph. It’s good for privacy!
In this design, the Bitcoin UTXO is used as a one-time seal containing RGB assets, and to transfer assets, you basically need to open the old seal and put on the new seal.
RGB-specific payment data is transmitted from the payer’s client to the receiver’s client via a dedicated communication channel that verifies that the RGB protocol rules are being followed. This way, blockchain watchers will not be able to extract any information about RGB user activity.
Unfortunately, verifying the payment received is not enough to ensure that the sender is the true owner of the asset just sent to you, so for the payment received to be considered final, you must receive all transaction history related to the token you just sent from the payer, all the way up to the initial issuance. By verifying all transaction history, you can ensure that the asset is inflation-free and that all spending conditions related to the asset are being adhered to.
! [zZVf5MlHozml9TA3HMdyWavHbBD9OISh9cWrjsEz.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-bbef455287-dd1a6f-cd5cc0.webp “7133084”)
This design helps with scalability because you don’t have to verify the entire history of the asset, only those transactions that are relevant to you. In addition, transactions are not broadcast to the global ledger, improving privacy because fewer people know that your transactions exist.
3, Blinding secrets
To further improve privacy, RGB supports blinding of the output, which means that in the payment request you send to the person who needs to pay you, you don’t disclose the UTXO you want to receive the token, you just ask the payer to send the token to a hash that you generate by concatenating the UTXO with a random blinding key. This way, the payer will not know the UTXO receiving the tokens, so it is impossible for the exchange or other service provider to know if they are helping with a UTXO withdrawal that is “blacklisted” by a regulator, or to monitor when the tokens will be spent in the future.
Note that when paying tokens, the blinded key must be disclosed to the receiver so that the receiver can verify all Bitcoin transactions in the transaction history. This means that with RGB, you currently have complete privacy, but future token holders will be able to see the full UTXO involved in the transfer. So, while users enjoy perfect privacy when receiving and holding tokens, the confidentiality of users’ past financial activities decreases over time as tokens are constantly transferred between people, approaching the level of privacy of our past Bitcoin transaction history.
4, Lightning Network compatibility
Since RGB is built on Bitcoin, it is also possible to transfer RGB tokens to the Lightning Network, and this is already being studied. The Lightning Network is a payment channel-based scalability solution that actually requires some work to bootstrap good channel liquidity across assets, either through widespread adoption of the asset, or through channel management software that connects directly to nodes that support the assets that the user is interested in, creating some kind of asset-specific sub-network.
Another solution to make less popular assets viable on the Lightning Network is to introduce nodes that provide an exchange service between a particular asset and Bitcoin. In this way, once exchanged with Bitcoin, the value can be transferred across the network through the liquidity of Bitcoin, and when it reaches the other end of the path, another exchange node converts the Bitcoin back to the original asset. This will eliminate the need for a specific network of liquid assets. However, in order to make this a reality, the trading volume of each asset with Bitcoin needs to be large enough to incentivize market makers to operate trading nodes in multiple locations on the network, offering bid-ask spreads that are low enough to avoid losing too much value from the payouts between the two trades.
! [fhtSwIHlaPktkY8QF0YxwdPwpVowif3GioSbk6ev.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-fb083d697f-dd1a6f-cd5cc0.webp “7133085”)
5, advanced smart contracts
By using Bitcoin transactions, RGB automatically inherits all of Bitcoin’s smart contract functionality, but it’s not limited to that! When you transfer tokens to a counterparty, you can define in the payment the additional spending conditions that that counterparty must meet in the future. This additional spending condition is not enforced by blockchain-wide consensus, but by the RGB node verification process. This means that if someone tries to spend tokens without adhering to RGB’s specific spending condition rules, the receiver’s node will not be able to successfully validate and will consider the payment not final, which is especially bad for the sender. In fact, while RGB payments fail, Bitcoin transactions that cost UTXOs (tokens are allocated to UTXOs) may have already been confirmed on the blockchain, meaning that these tokens will no longer be allocated to any UTXOs and they can also be considered burned (burnt), which is a dynamic factor to consider when writing RGB smart contracts.
Another trade-off to be aware of is that while RGB contracts can provide more privacy and scalability than any alternative, their state is not globally accessible, and they can’t be ownerless (as happens in other blockchains), which also represents a degree of limitation for some use cases.
Due to the client-side nature of RGB, multiple smart contract frameworks can be proposed and implemented in a permissionless manner. At the time of writing, there is a project called AluVM that is working in this direction.
6, RGB and alternatives
Anyone interested in adopting RGB will find themselves wondering how it compares to other token protocols. Let’s break down a few examples:
Altcoin-based tokens
Most altcoin-based token protocols (e.g., ERC-20) offer smart contracts with a global ownerless state, which makes it fairly easy to deploy DEXs and other financial applications, but is difficult to scale, has no privacy, and inherits all the drawbacks of these altcoins, such as high node running costs, low decentralization, and weak censorship resistance.
Liquid Assets
Liquid is a Bitcoin federated sidechain that offers some interesting features, such as native asset backing and secret transactions, which can hide the payment amount and the ID of the transferred asset from blockchain observers. Again, however, the federated model raises the same problem: low decentralization and weak censorship resistance.
OmniBolt is a Lightning-compatible version of OmniLayer, which is briefly covered at the beginning of this article. It has very similar trade-offs to RGB, but it offers less privacy protection and scalability because all token-related data is kept on-chain.
Bitcoin 2022 Miami announced that Taro, a project backed by Lightning Labs, aims to put assets on top of the Lightning Network. According to the published specification notes, the design is very similar to RGB, with essentially the same features and trade-offs. At the time of writing, the main difference between RGB and Taro seems to be that RGB has released some reviewable code, while Taro has only released specifications, but on the other hand, you could say that Taro is backed by one of the best teams in the lightning ecosystem, making future implementations promising. Considering the similarities between the two designs, it would be great if the Taro and RGB were finally able to interoperate, but only time will tell if that will happen.
