TLDR:

Various smart contract solutions exist on the current Bitcoin network, with the Ordinals protocol and the RGB protocol being the most mainstream. The advent of the Ordinals protocol enabled smart contract development on the Bitcoin network, tying its security to the Bitcoin blockchain. However, the confirmation and recording of Ordinals asset transfers occur on the main Bitcoin network and are bound to a transfer of 1 satoshi. This results in high transaction fees and further congests the already slow Bitcoin main network.

In contrast, the RGB protocol introduces off-chain channels and batch transaction processing, significantly reducing transaction fees and improving speed. Client-side validation also greatly reduces the data required to maintain network operations, enhancing network scalability. While the RGB protocol improves transaction speed and scalability, it also introduces new challenges. Off-chain channels optimize transaction costs and speed but raise security concerns for off-chain records. Client-side validation reduces data storage but significantly slows down verification speeds.

This article compares the Ordinals and RGB protocols across dimensions of security, scalability, transaction fees, and speed, and explores possible future directions for the RGB narrative.

1. Market Overview

Bitcoin currently accounts for about 49% of the total cryptocurrency market value. However, its development is severely hindered by the lack of Turing completeness in its scripting language, the absence of mainnet smart contracts, and slow transaction speeds. To address these issues, Bitcoin developers have attempted various expansion and acceleration solutions, mainly including:

• RGB Protocol: A second-layer protocol built on the Bitcoin network, storing its core transaction data on the BTC mainnet. RGB uses Bitcoin’s security model to support the creation of tokens with custom properties and smart contract functions on the Bitcoin network. Initially proposed by Peter Todd in 2016, the RGB protocol regained attention in 2023 amid the smart contract development boom on Bitcoin.

• Segregated Witness (SegWit): Implemented in August 2017, SegWit separates transaction and signature information, increasing the effective block size from 1MB to 4MB, partially alleviating congestion. However, due to Bitcoin block size limitations, further expansion of block storage is not feasible.

• Lightning Network: A second-layer scaling solution for Bitcoin, allowing transactions without accessing the blockchain, significantly increasing throughput. However, the Lightning Network, with solutions like OmniBOLT and Stacks, faces substantial centralization risks.

• Sidechain Technology: Building a sidechain outside the Bitcoin network, sidechain assets are pegged 1:1 to BTC. Sidechains offer improved transaction performance but can never match the security of the BTC mainnet.

Image Source: Dune

Since March this year, transaction fees on the Bitcoin network and the volume of BRC20 protocol assets have surged. In early May, BTC mainnet transaction fees peaked, and while they have since declined, the trading volume of BRC20 assets remains high. This indicates that the enthusiasm for smart contract development in the Bitcoin network has not waned, even as the fervor around inscriptions in the BTC ecosystem has decreased. Developers continue to seek the optimal solution for smart contract development on the Bitcoin network.

2. Ordinals Protocol

2.1 Satoshi Numbers

Unlike Ethereum’s wei, which is recorded as data, Bitcoin’s Satoshi is calculated based on the UTXO owned by each address. To differentiate sats, it’s necessary first to distinguish UTXOs, then to differentiate sats within a UTXO. The former is relatively straightforward, as different UTXOs correspond to different block heights. Since mining generates original sats, it suffices to number UTXOs in coinbase transactions. The challenge lies in numbering sats within the same UTXO. The Ordinals protocol proposed a solution based on the first-in-first-out principle.

Differentiating UTXOs: BTC Builder begins recording from the time a UTXO is mined, with each UTXO corresponding to a unique block, and each block having a unique block height on the Bitcoin network. Different block heights can distinguish different UTXOs.

Differentiating Sats Within a UTXO: Block height determines the range of sats in a UTXO. For instance, the earliest block could mine 100 BTC, or 1010 sats. Thus, sats in a block with height 0 would be numbered [0,1010-1], those in a block with height 1 would be [1010,21010-1], and so on. To specify a particular sat within a UTXO, one must look at the UTXO’s consumption process. The Ordinals protocol numbers sats in outputs of a UTXO based on the first-in-first-out principle. For example, if a miner A at block height 2 transfers 50 of their 100 BTC to B, the earlier output assigned to A would correspond to sats numbered [21010,2.51010-1], while B would receive sats [2.51010,3*1010-1].

Image Source: Kernel Ventures

2.2 Ordinals Inscription

Initially, Bitcoin added an OP_RETURN operator to provide an 80-byte storage space for each transaction. However, this was insufficient for complex code logic and increased transaction costs and network congestion. To address this, Bitcoin implemented two soft forks, SegWit and Taproot. A Tapscript script, starting with an OP_FALSE opcode and not executed, provided a 4MB space for transactions. This space can store ordinals inscriptions, enabling text, image on-chain, or BRC20 protocol token issuance.

2.3 Ordinals Shortcomings

Ordinals significantly enhance the programmability of the Bitcoin network, breaking free from limitations on BTC ecosystem narratives and development, and providing functionality beyond Bitcoin transactions. However, several issues remain a concern for BTC ecosystem developers.

Centralization of Ordinals: Although state recording and changes in the ordinals protocol occur on-chain, the protocol’s security is not equivalent to the Bitcoin network. Ordinals cannot prevent duplicate inscriptions on-chain, and identifying invalid inscriptions requires off-chain ordinals protocol intervention. This emerging protocol, untested over a long period, has numerous potential issues. Also, problems with the underlying service of the ordinals protocol could lead to asset loss for users.

Limitations on Transaction Fees and Speed: Inscriptions are engraved through segregated validation areas, meaning each transfer of ordinals assets must correspond to a spent UTXO. Given Bitcoin’s block time of around 10 minutes, transactions cannot be sped up. Additionally, on-chain inscriptions increase transaction costs.

Harming Bitcoin’s Original Properties: Since ordinals assets are tied to Bitcoin’s inherently valuable sats, ordinals usage itself causes an alienation of Bitcoin’s original assets, and inscriptions increase miners’ fees. Many BTC supporters worry this will harm Bitcoin’s original payment function.

3. The RGB Protocol

With the surge in online transaction volume, the limitations of the ordinals protocol have become increasingly apparent. In the long run, if this issue isn’t adequately addressed, Bitcoin’s smart contract ecosystem will struggle to compete with Turing-complete public chain ecosystems. Among the many alternatives to ordinals, many developers have opted for the RGB protocol, which offers significant advancements in scalability, transaction speed, and privacy compared to ordinals. Ideally, Bitcoin ecosystem assets built on the RGB protocol can achieve transaction speeds and scalability comparable to assets on Turing-complete public chains.

3.1 Core Technologies of RGB

Client-Side Validation

Unlike the broadcast of transaction data on the Bitcoin mainnet, the RGB protocol operates off-chain, with information transmitted only between the sender and receiver. After validating a transaction, the receiving node doesn’t need to synchronize with the entire network or record all transaction data on the network like the Bitcoin mainnet. The receiving node only records data related to that transaction, sufficient for blockchain validation, significantly enhancing network scalability and privacy.

Image Source: Kernel Ventures

One-Time Seals

In real-world material transfers, materials often change hands multiple times, posing a significant threat to their authenticity and integrity. To prevent malicious tampering before submission for verification, seals are used in real life, with the seal’s integrity indicating whether the content has been altered. The role of one-time seals in the RGB network is similar. Specifically, they are represented by the naturally one-time attribute of electronic seals in the Bitcoin network - UTXO.

Similar to smart contracts on Ethereum, issuing Tokens under the RGB protocol requires specifying the token’s name and total supply. The difference is that there isn’t a specific public chain as a carrier in the RGB network. Every Token in RGB must be linked to a specific UTXO in the Bitcoin network. Ownership of a certain UTXO in the Bitcoin network implies ownership of the corresponding RGB Token in the RGB protocol. To transfer an RGB token, the holder needs to spend the UTXO. The one-time nature of UTXOs means that once spent, they are gone, mirroring the spending of the associated RGB asset. This process is akin to opening a one-time seal.

Image Source: Kernel Ventures

UTXO Blinding

In the Bitcoin network, every transaction can be traced to its input and output UTXOs. This enhances the efficiency of UTXO tracing in the Bitcoin network and effectively prevents double-spending attacks. However, the fully transparent transaction process compromises privacy. To enhance transaction privacy, the RGB protocol proposes the concept of blinded UTXOs.

During the transfer of RGB Tokens, the sender A cannot obtain the exact address of the receiving UTXO but only a hash result of the receiving UTXO address concatenated with a random password value. When the receiver B wishes to use the received RGB Protocol Token, they must inform the next receiver C of the UTXO address and send the corresponding password value to C to verify that A indeed sent the RGB Protocol Token to B.

Image Source: Kernel Ventures

3.2 Comparison of RGB and Ordinals

Security: Every transaction or state transition in Ordinals smart contracts must be executed through spending a UTXO, while in RGB, this process largely relies on the Lightning Network or off-chain RGB channels. RGB stores a significant amount of data in the RGB client (local cache or cloud server), leading to a high degree of centralization and the potential for exploitation by centralized institutions. Additionally, server downtime or local cache loss could cause asset loss for clients. In terms of security, Ordinals has an advantage.

Verification Speed: As RGB uses client-side verification, verifying each transaction in the RGB protocol requires starting from scratch. This consumes substantial time in confirming every step of RGB asset transfer, significantly slowing down the verification process. Hence, Ordinals has the upper hand in verification speed.

Privacy: The transfer and verification of RGB assets occur outside the blockchain, establishing a unique channel between sender and receiver. Additionally, UTXO blinding ensures that even the sender cannot trace the UTXO’s destination. In contrast, Ordinals asset transfers are recorded through UTXO spending on Bitcoin, and both the input and output UTXOs are traceable on the Bitcoin network, offering no privacy. Therefore, from a privacy perspective, the RGB protocol has an advantage.

Transaction Costs: RGB transfers largely rely on client-side RGB channels or the Lightning Network, resulting in almost zero transaction costs. Regardless of the number of transactions, only one UTXO spend is required for final confirmation on the blockchain. However, every transfer in Ordinals requires recording in the tapscript script. Coupled with the cost of recording inscriptions, this incurs a considerable transaction fee. Moreover, the RGB protocol proposes batched transactions, allowing a single tapscript script to specify multiple RGB asset recipients. In contrast, Ordinals defaults to transferring UTXO to one recipient at a time, but RGB reduces costs significantly by sharing the burden. Thus, RGB has the advantage in transaction fees.

Scalability: In RGB smart contracts, transaction verification and data storage are managed by the client (receiving node) and do not occur on the BTC chain, eliminating the need for broadcasting and global validation on the mainnet. Each node only needs to ensure confirmation of transaction-related data. However, inscription data in Ordinals requires on-chain operations. Given Bitcoin’s processing speed and scalability limitations, its transaction volume capacity is greatly restricted. Therefore, RGB has a superior advantage in scalability.

4. RGB Ecosystem Projects

Following the release of RGB v0.10.0, the development environment on the RGB network has become more user-friendly for developers. Consequently, the large-scale development of the RGB protocol ecosystem has only been half a year, and most of the following RGB ecosystem projects are still in their early stages:

Infinitas: Infinitas is a Turing-complete Bitcoin application ecosystem that combines the advantages of the Lightning Network and RGB protocol, supporting and complementing each other to create a more efficient Bitcoin ecosystem. Notably, Infinitas also proposed recursive zero-knowledge proof to address the inefficiency of client-side validation. If this method is effectively implemented, it could significantly resolve the validation speed issues in the RGB network.

RGB Explorer: RGB Explorer is one of the earliest browsers to support querying and transferring RGB assets (Fungible and Non-Fungible tokens), supporting assets like RGB20, RGB21, and RGB25 standards.

Cosminimart: Cosminimart is essentially a Bitcoin Lightning Network compatible with the RGB protocol, attempting to create a new Bitcoin ecosystem capable of deploying smart contracts. Unlike the aforementioned projects with singular functions, Cosminimart provides a wallet, a derivatives trading market, and an early project discovery market. It offers one-stop services for Bitcoin network smart contract development, product promotion, and trading.

DIBA: Leveraging the Lightning Network and RGB protocol, DIBA is committed to building a Bitcoin network NFT market. It is currently operating on the Bitcoin testnet and is expected to launch on the mainnet soon.

5. RGB’s Future Prospects

With the release of the RGB v0.10.0 version, the overall framework of the protocol has become increasingly stable, and the potential compatibility issues during version updates are being progressively resolved. Concurrently, the development of tools and a variety of API interfaces is being refined, significantly reducing the complexity for developers working with RGB.

Today #Tether announces the ending of the support of 3 blockchains $USDt: OmniLayer, BCH-SLP and Kusama. Customers will be able to continue to redeem and swap $USDt tokens (to another of the many supported blockchains), but Tether won’t issue any new additional $USDt on those 3 blockchains.

Recently, an official announcement from Tether indicated a shift of the USDT contract deployment on the Bitcoin layer-2 network from OmniLayer to RGB. This move by Tether is perceived as a signal of major players in the Crypto world venturing into RGB. RGB now boasts a well-established development protocol, a substantial developer community, and recognition from crypto giants. Presently, RGB developers are experimenting with recursive zero-knowledge proofs to reduce the size of client-side validations. If successful, this enhancement will significantly accelerate verification speeds on the RGB network, thus alleviating network latency issues during extensive use.

Kernel Ventures is a crypto venture capital fund driven by a research and development community. It has made over 70 early investments, focusing on infrastructure, middleware, dApps, and specifically on ZK, Rollups, DEX, modular blockchains, and verticals poised to serve billions of future crypto users. These include account abstraction, data availability, scalability, and more. For the past seven years, we have been dedicated to supporting core development communities and university blockchain associations worldwide.

Disclaimer：

1. This article is reprinted from [techflowpost]. All copyrights belong to the original author [Will 阿望；Diane Cheung]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.