TL;DR
The article compares Ordinals and RGB protocols from the dimensions of security, scalability, transaction fees, and transaction speed, and analyzes the possible future direction of the RGB narrative.
Author: Jerry Luo
Reviewers: Mandy, Joshua
1. Market Overview
Currently, BTC accounts for about 49% of the total cryptocurrency market value. However, due to its non-Turing complete script language, the lack of smart contracts on the main network, and slow transaction speed, its long-term development is severely hindered. To address these issues, Bitcoin developers have made numerous attempts in scaling and speeding up, mainly focusing on the following 4 solutions:
RGB Protocol: RGB is a second-layer protocol built on the Bitcoin network, with its core transaction data stored on the BTC main network. RGB utilizes the security model of Bitcoin to support the creation of tokens with customized properties and smart contract functionality on the Bitcoin network. In 2016, RGB protocol was initially proposed by Peter Todd; in 2023, during the development boom of smart contract ecosystem on Bitcoin, RGB protocol gained attention again.
Segregated Witness (SegWit): In August 2017, Bitcoin implemented the SegWit upgrade. By separating transaction information from signature information, the effective block size was increased from 1M to 4M, alleviating congestion to a certain extent. However, due to the limitation of the Bitcoin block size, there is a limit to the expansion of storage information for a block.
Lightning Network: The Lightning Network is a second-layer scaling solution based on Bitcoin, allowing transactions to be conducted off-chain, greatly increasing throughput. The Lightning Network has been implemented on the Bitcoin main network, and existing Lightning Network solutions include OmniBOLT, Stacks, etc., but the Lightning Network faces significant centralization risks.
Sidechain Technology: Sidechain technology involves building a sidechain outside the Bitcoin network, with assets on the sidechain anchored to BTC at a 1:1 ratio. Sidechains have significantly improved transaction performance compared to the main network, but they can never achieve the same level of security as the BTC main network.
Since March of this year, the transaction fees on the Bitcoin network and the transaction volume of BRC20 protocol assets have seen a significant increase. In early May, BTC main network transaction fees reached a peak, and although the fees have since declined, the transaction volume of BRC20 assets has remained at a high level. This indicates that the development enthusiasm for the smart contract ecosystem on the Bitcoin network has not waned along with the decline in enthusiasm for BTC ecosystem, and developers continue to seek the optimal solution for smart contract development on the Bitcoin network.
2. Ordinals Protocol
2.1 Satoshi Numbering
The Satoshi on the Bitcoin network, unlike the wei on Ethereum, is calculated based on the UTXO owned by each address. To distinguish different sats, it is necessary to differentiate between different UTXOs and then distinguish between sats under the same UTXO. The Ordinals protocol proposes a new solution, numbering sats based on the first-in-first-out principle.
Distinguishing Different UTXOs: BTC Builder records from the time when UTXOs are mined, with each UTXO corresponding to a unique block, and each block having a unique block height on the Bitcoin network, allowing differentiation of different UTXOs based on different block heights.
Distinguishing sats under the same UTXO: By using block height, the approximate range of sats under a UTXO can be determined. For example, if the earliest block can mine 100 BTC, which is $10^{10}$ sats, then the sats under block height 0 are numbered from 0 to $10^{10}-1$, the sats under block height 1 are numbered from $10^{10}$ to $210^{10}-1$, and so on. To specifically distinguish a particular sats under this UTXO, it is necessary to track the spending process of the UTXO. The Ordinals protocol follows the first-in-first-out principle, where in the outputs generated when a UTXO is used as input, the earlier outputs correspond to earlier numbered sats. For example, if miner A, who mined block height 2, wants to transfer 50 out of his 100 BTC to B, the earlier output is allocated to A, and the later output is allocated to B, resulting in A receiving sats numbered from $210^{10}$ to $2.510^{10}-1$, and B receiving sats numbered from $2.510^{10}$ to $3*10^{10}-1$.
2.2 Ordinals Inscription
The Bitcoin network initially provided a 80-byte storage space for each transaction through the addition of the OPRETURN operator. However, the 80-byte area cannot accommodate the writing of complex code logic, and writing data to the blockchain also increases transaction costs and the likelihood of network congestion. To address this issue, the Bitcoin network has successively undergone the SegWit and Taproot soft forks. Through a Tapscript script that starts with an OPFALSE opcode and will not be executed, the Bitcoin transaction process provides a 4M space. In this area, ordinals inscriptions can be written to achieve on-chain text, image, or BRC20 protocol token issuance, etc.
2.3 Shortcomings of Ordinals
Ordinals significantly enhance the programmability of the Bitcoin network, breaking the limitations imposed on the BTC ecosystem's narrative and development, and providing functionality beyond transactions on the Bitcoin network. However, many issues are still criticized by BTC ecosystem developers.
Centralization of Ordinals: Although the recording and modification of states in the ordinals protocol are conducted on-chain, the security of the ordinals protocol itself cannot be equated with the Bitcoin network. Ordinals cannot prevent the duplicate on-chain inscription, and the identification of invalid inscriptions needs to be done by the off-chain ordinals protocol. This emerging protocol has not been tested for a long time and has many potential issues. Additionally, if the underlying services of the ordinals protocol encounter problems, it may lead to the loss of user assets.
Limitations of Transaction Fees and Speed: Because the inscription is carved through isolated verification areas, meaning that completing a transfer of ordinals assets requires corresponding UTXO spending. Due to the 10-minute block generation time of the Bitcoin network, the transaction process cannot be accelerated. Additionally, on-chain inscription also increases transaction costs.
Damage to Bitcoin's Original Properties: Since ordinals assets are bound to the valuable sats of the Bitcoin network, the use of ordinals itself will cause the alienation of Bitcoin's original assets, while on-chain inscription also leads to a significant increase in miner fees. Many BTC supporters are concerned that this will damage Bitcoin's original payment functionality.
3. RGB Protocol
With the surge in network transaction volume, the shortcomings of the ordinals protocol have become apparent. In the long run, if this issue is not properly addressed, the smart contract ecosystem of Bitcoin will be difficult to compete with the Turing complete public chain ecosystem. Among the many alternative solutions to ordinals, many developers have chosen the RGB protocol, which has made significant breakthroughs in scalability, transaction speed, and privacy compared to ordinals. Ideally, assets built on the Bitcoin ecosystem based on the RGB protocol can achieve similar levels of transaction speed and scalability as assets on Turing complete public chains.
3.1 RGB Core Technology
Client Verification
Unlike the broadcast of transaction data in the Bitcoin main network, the RGB protocol moves this process off-chain, with information only transmitted between the sender and receiver. After the receiver verifies the transaction, there is no need to synchronize with all nodes on the network, recording all transaction data in the network, as required in the Bitcoin main network. The receiving node only needs to record the data related to the transaction and meet the requirements for on-chain verification, greatly improving the network's scalability and privacy.
One-time Seal
In real-life material exchanges, materials often change hands multiple times, posing a significant threat to the authenticity and integrity of the materials. To prevent malicious tampering of materials before submission for verification, people use seals to determine whether the contents have been tampered with. The role of a one-time seal in the RGB network is similar, specifically with the natural one-time property of electronic seals - UTXOs - in the Bitcoin network.
Similar to smart contracts on Ethereum, issuing tokens under the RGB protocol also requires specifying the name and total supply of the tokens. The difference is that there is no specific public chain as a carrier in the RGB network. Each token in RGB must correspond to a specific UTXO on the Bitcoin network. If someone owns a specific UTXO on the Bitcoin network, they also own the RGB token recorded for that UTXO in the RGB protocol. To transfer an RGB token, the holder needs to spend the corresponding UTXO. Due to the one-time nature of UTXOs, once spent, they are gone, which corresponds to spending the RGB asset in the Ordinals protocol. This spending of UTXO is the process of breaking the one-time seal.
UTXO Blinding
In the Bitcoin network, each transfer can be traced back to the input and output UTXOs. This increases the efficiency of UTXO tracing on the Bitcoin network and effectively prevents double-spending attacks. However, due to the completely transparent nature of the transaction process, the privacy of both parties is not considered. To enhance transaction privacy, the RGB protocol proposes the concept of blinding UTXOs.
In the process of transferring RGB tokens, the sender A cannot obtain the specific address of the receiving UTXO, but only receives a result obtained by hashing the receiving UTXO address with a random password value. When the recipient B wants to use the received RGB protocol token, they need to inform the recipient C of the address corresponding to their UTXO and send the corresponding password value to verify to recipient C that A did indeed send the RGB protocol token to B.
3.2 Comparison of RGB and Ordinals
Security: Each transaction or state transfer in Ordinals smart contracts requires spending a UTXO, while in RGB, this process heavily relies on the Lightning Network or off-chain RGB channels. The storage of a large amount of data during the RGB transaction process is in the RGB client (local cache or cloud server), which introduces a high level of centralization and the possibility of data being utilized by centralized institutions. Additionally, if the server crashes or local cache is lost, it could result in loss of customer assets. From a security perspective, Ordinals has an advantage.
Verification Speed: Since RGB uses client-side verification, each verification of a transaction in the RGB protocol needs to start from scratch, which will take a lot of time to confirm each step of the RGB asset transfer process, significantly slowing down the verification speed. Therefore, in terms of verification speed, Ordinals has an advantage.
Privacy: The transfer and transaction verification of RGB assets occur off the blockchain, establishing a unique channel between the sender and receiver. Additionally, the blinding of UTXOs makes it impossible for the sender to trace the destination of the UTXO. In contrast, the transfer process of Ordinals assets is recorded through UTXO spending on the Bitcoin network, and the input and output of UTXOs can be queried on the Bitcoin network, offering no privacy. Therefore, from a privacy perspective, the RGB protocol has an advantage.
Transaction Fees: Transfers in RGB heavily rely on client-side RGB channels or the Lightning Network, resulting in almost zero transaction fees. Regardless of how many intermediate transactions occur, only one UTXO needs to be spent and confirmed on the blockchain. However, each step of the transfer in Ordinals needs to be recorded in the tapscript, and combined with the cost of recording inscriptions, the transaction process will incur significant fees. Additionally, the RGB protocol proposes a method of batch transaction packaging, where multiple recipients of RGB assets can be specified in a single tapscript, while in Ordinals, the default output UTXO recipient is the recipient of the Ordinals asset, allowing only one-to-one transfers. RGB significantly reduces the cost of this process through sharing. Therefore, in terms of transaction fees, the RGB protocol has an advantage.
Scalability: In RGB smart contracts, transaction verification and data storage are completed by the client (receiving node), not on the BTC chain, eliminating the need for broadcasting and global verification on the main network. Each node only needs to confirm the data related to a specific transaction. In contrast, the inscription data in Ordinals needs to be recorded on-chain, and given the processing speed and scalability of the Bitcoin network itself, its ability to handle transaction volume will be greatly limited. Therefore, in terms of scalability, the RGB protocol has an advantage.
4. RGB Ecosystem Projects
After the release of RGB v0.10.0, it provides a more developer-friendly environment for development on the RGB network. Therefore, the development of the RGB protocol ecosystem has only been in progress for about six months, and most of the following RGB ecosystem projects are still in the early stages of development:
Infinitas: Infinitas is a Turing complete Bitcoin application ecosystem that combines the advantages of the Lightning Network and the RGB protocol, supporting and complementing each other to achieve a more efficient Bitcoin ecosystem. It is worth mentioning that Infinitas has also proposed a method of recursive zero-knowledge proof to address the inefficiency of client verification. If this method is effectively implemented, it will greatly solve the verification speed issue in the RGB network.
RGB Explorer: RGB Explorer is the first browser to support the query of RGB assets and the sending of assets (Fungible token and None Fungible token), supporting three standard assets: RGB20, RGB21, and RGB25.
Cosminmart: Cosminimart is essentially a Bitcoin Lightning Network compatible with the RGB protocol. It aims to create a new ecosystem for deploying smart contracts on Bitcoin. Unlike the above projects with a single function, Cosminmart provides a wallet, derivative trading market, and early project exploration market. It provides a one-stop service for the development, promotion, and trading of smart contracts on the Bitcoin network.
DIBA: DIBA aims to create an NFT market for the Bitcoin network using the Lightning Network and the RGB protocol. It is currently running on the Bitcoin testnet and is expected to go live on the mainnet soon.
5. RGB Future Outlook
With the release of RGB v0.10.0, the overall framework of the protocol program is becoming more stable, and the potential for large-scale incompatibility issues during version updates is gradually being addressed. Additionally, developer tools and various API interfaces are becoming more complete, reducing the difficulty for developers to use RGB for development.
Recently, Tether announced the transfer of the deployment of USDT contracts on the Bitcoin second-layer network from OmniLayer to RGB. This move by Tether is seen as a signal of the crypto giant's attempt to enter the RGB. With a mature development protocol, a large developer community, and recognition from crypto giants, RGB developers are now attempting to compress the volume of client verification using recursive zero-knowledge proof. If this improvement is successful, the verification speed of the RGB network will be greatly increased, thereby alleviating the network latency issues faced during large-scale usage.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
