Renaissance of Bitcoin Scaling VI — Nervos

14 min readMay 21, 2024

Author: F.F from LBank Labs Research team

TL;DR

In our fourth episode, we explore an old protocol known as RGB. As of the current writing, it is on the verge of being released in version 0.11 after years of development. Many ecosystem protocols are eagerly awaiting this release to launch the first RGB token.

Over the past weeks and months, there has been considerable debate and arguments between RGB and Nervos. The latter has proposed an alternative solution called RGB++. The LNP/BP association labeled them as scams, but Nervos asserted that they have made improvements to enhance usability.

So, what exactly sets RGB and RGB++ apart? In essence, they are completely different solutions with distinct architectures and trade-offs. There is no code reuse, and RGB++ is not a forked version of RGB. Hence, we omitted the name RGB++ from the title and believe it is best to distinguish and treat them separately.

To provide users with a better understanding of the developments, we will delve into the technical implementation of RGB++ in the first section. We will analyze various terminologies and explain their true significance.

Following that, we will outline the three most common use cases: Bitcoin mainnet transactions, bridging assets from Layer 1 to Layer 2, and bridging assets back to Layer 1 from Layer 2. This approach aims to make the mechanism more comprehensible for general users.

Lastly, we will assess the current state of the ecosystem post the short-term bubble and discuss what lies ahead in the future. As the saying goes, you only discover who is swimming naked when the tide goes out.

Technical Implementation

High-level Comparison between RGB and RGB++

At a high level, distinguishing between RGB and RGB++ is relatively straightforward. The architecture of RGB involves the combination of single-use seals and CSV (Client-Side Validation), whereas RGB++ integrates single-use seals and Nervos L2 verification.

Single-use seals refer to the spending and generation of UTXOs during state transitions. When a new state is created, the previous state is disclosed and closed, resulting in the generation of a new UTXO. This process ensures that the state transition rules necessitate spending the existing UTXO and creating a new one. By taking a closer look at the state inclusion in RGB and RGB++:

In RGB, only the Pedersen root hash is disclosed to commit the RGB asset state. On the other hand, RGB++ commits the hash of the transaction on CKB, and the Inputs and Outputs of UTXOs on Bitcoin, for example, commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2).

In terms of the verification layer, the core concept of RGB revolves around CSV. CSV enables nodes to verify state transitions pertaining to their specific contract state without the need to validate all transactions globally. This approach not only enhances scalability but also ensures privacy and data compression within RGB.

On the other hand, for RGB++, the verification process involves Nervos itself. All states are publicly published on the chain, making it akin to a general ledger like other chains equipped with built-in data storage and P2P networks.

Isomorphic Bindings

Isomorphic Binding is a new term introduced by RGB++. To clarify any confusion, it can be broken down into two components: Cell Model and Cell Script. The Cell Model mimics the UTXO model on Bitcoin, while the Cell Script functions as the logic to bind Cells and UTXOs.

Cell Model

A Cell serves as the foundational data storage unit in Nervos. It extends the UTXO model and is not only Turing-complete but also more robust in its ability to store additional data.

Cell structures play a vital role in defining ownership, enforcing validation rules, and managing data storage. Let’s delve into the key components that make up these cell structures and their respective functions:

Capacity Usage: In Nervos CKB, Capacity Usage is a crucial element that highlights the declared and occupied capacity within a cell. Declared Capacity refers to the total capacity declared by the cell, while Occupied Capacity represents the capacity actually utilized by the cell. For efficient resource allocation, a transaction in CKB must create an output cell with an occupied capacity lower than the cell’s declared capacity.
Lock Script: The Lock Script in Nervos CKB serves as a determinant of cell ownership by typically assigning ownership to a single user. It can also facilitate complex operations, such as multi-signature schemes or conditional usage within specific timeframes, which must be satisfied for spending the cell’s capacity. During transaction verification, the Lock Script is executed by the CKB VM.
Type Script: Attached to a cell’s type field, the Type Script in Nervos CKB plays a crucial role in imposing additional validation rules on the cell’s data. While the Lock Script governs ownership, the Type Script enables customization of data formats and intricate validation logic beyond the capabilities of the Lock Script. During transaction verification, the Type Script is executed within the CKB VM to enforce these rules. Although optional, CKB runs the Type Scripts in both input and output cells during a transaction.
Data Storage: The data storage in Nervos CKB is versatile, accommodating various data types such as CKBytes, tokens, JavaScript code, and serialized data like JSON strings. This flexibility enables diverse use cases, providing extensive options for data representation and storage within cell structures.

Cell Script

RGB++ Lock Script

In the realm of RGB++, integrating a specific lock script within each binding cell plays a vital role in recording the assets held by Bitcoin mainnet assets. A key component is the RGB++ Lock Script outlined below, which encompasses the necessary details for pinpointing the consumable Bitcoin transaction hash (tx_hash) and the specific consumable Bitcoin UTXO index (index). This setup facilitates accurate tracking and management of assets within the framework of Bitcoin integration. Consequently, the Cell on CKB becomes consumable by the UTXO on Bitcoin, which defines the essence of binding. When the UTXO on Bitcoin is spent, it also unlocks the RGB++ Lock Script and spends the Cell on Nervos.

{
"code_hash": "0xbc6c568a1a0d0a09f6844dc9d74ddb4343c32143ff25f727c59edf4fb72d6936",
  "hash_type": "type",
  "out_point": {
    "tx_hash": "0x04c5c3e69f1aa6ee27fb9de3d15a81704e387ab3b453965adbe0b6ca343c6f41",
    "index": "0x0"
  },
  "dep_type": "code"
}

BTC Time Lock Script

In the context of asset bridging and locking on Nervos, the BTC Time Lock script plays a crucial role. This mechanism involves the utilization of a specified lock script, a particular Bitcoin transaction, and a confirmation time window. An illustrative BTC Time Lock configuration can be outlined as follows: the relevant transaction for bridging Bitcoin assets (new_bitcoin_tx), along with the necessary confirmation threshold (after), ensuring the smooth and secure transfer of Bridge RGB++ assets to Nervos.

{
  "code_hash": "0x70d64497a075bd651e98ac030455ea200637ee325a12ad08aff03f1a117e5a62",
  "hash_type": "type",
  "out_point": {
    "tx_hash": "0x6257bf4297ee75fcebe2654d8c5f8d93bc9fc1b3dc62b8cef54ffe166162e996",
    "index": "0x0"
  },
  "dep_type": "code"
}

xUDT Script

To reflect the issuance and circulation of RGB++ tokens on Nervos, xUDT, the unique token standard within the Nervos ecosystem, is utilized to enhance the functionality and interoperability of assets. The following is a sample configuration of xUDT interoperability, which encompasses the fundamental specifications required to facilitate the seamless integration and utilization of xUDT tokens within the broader Nervos ecosystem. This initiative aims to promote improved asset management and interoperability.

{
  "code_hash": "0x50bd8d6680b8b9cf98b73f3c08faf8b2a21914311954118ad6609be6e78a1b95",
  "hash_type": "data1",
  "out_point": {
    "tx_hash": "0xc07844ce21b38e4b071dd0e1ee3b0e27afd8d7532491327f39b786343f558ab7",
    "index": "0x0"
  },
  "dep_type": "code"
}

Scenario Analysis

To provide clarity on the workflow of RGB++ assets, we have outlined three common scenarios and their corresponding real-case transactions on the chain. This will assist the community in understanding the process better.

L1 Transaction

The primary transaction involves the transfer of RGB++ assets on Bitcoin. As per the documentation from the Nervos team, the transfer of RGB++ assets can be divided into four distinct steps

1. Off-chain Calculation: Initially, off-chain computations are conducted to generate an RGB++ transaction (CKB_TX_B) intended for the Nervos network. This process involves determining the commitment value using the formula: commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2), where the CKB transaction CKB_TX_B is combined with BTC inputs btc_utxo#1 and btc_utxo#2.

2. Submission of BTC Transaction: To commence the transaction, the BTC transaction is submitted, accompanied by the payment of the required transaction fees on the Bitcoin network. This transaction input includes UTXO#1, while the output contains the computed commitment value along with UTXO#2.

3. Submission of CKB Transaction: Simultaneously, the CKB transaction is submitted, with transaction fees paid during the network’s inaugural phase. The input for this transaction comprises Cell#1, with the output being Cell#2.

4. Verification Process: The verification stage is crucial for ensuring the accuracy and validity of the entire transaction sequence. The Nervos network’s light client meticulously verifies the presence of pertinent BTC transactions on the Bitcoin chain. Subsequently, these BTC transactions are included along with the Nervos transaction for comprehensive verification.

Following this, Nervos rigorously validates that the BTC transaction appropriately spends the designated UTXO and commits to the precise commitment value. Additionally, the on-chain state transition is examined to confirm adherence to the specified contract rules, ensuring a seamless and secure transaction flow within the ecosystem.

In a practical scenario, the transaction involves selling 1000 Seals from bc1psfpd...672q6rhuwp to bc1qhhl....50u4u. The seller and buyer can be identified in the Input section, with the first output representing the seller's revenue, the second output indicating the RGB++ transfer to the buyer, the third output denoting the service fee levied by the marketplace, and the final output serving as the change for the buyer. The commitment on Bitcoin appears as ff37309134....04bb4a5cd after OP_RETURN.

Going back to the Nervos Network, the transaction hash is 0x8881a4076…d2e11f78d9afaa, and the structure of the Input Cell and Output Cell is displayed below.

L1 -> L2 Bridge

When a user needs to bridge the RGB++ assets to the Nervos network, two CKB transactions are required, as opposed to general transfers.

The first CKB transaction should contain at least 1 BTC_TIME_Lock cell, while the other can be an RGB_lock cell similar to a standard RGB++ asset transfer. This process is illustrated below:

# BTC_TX
input:
  btc_utxo_1
  ...
output:
  OP_RETURN: commitment
  btc_utxo_3

# CKB_TX
input:
  rgb_xudt:
    type: xudt
    lock:
      code: RGB_lock
      args: out_index | source_txoutput:
  rgb_xudt:
    type: xudt
    lock：
      code: BTC_TIME_lock
      args: lock_script | after | %new_bitcoin_tx%  rgb_xudt:
    type: xudt
    lock:
      code: RGB_lock
      args: out_index=1 | %new_bitcoin_tx%

As mentioned earlier, the BTC Time Lock Script is utilized to lock the cell after a specific number of confirmations. Subsequently, another CKB transaction is required to unlock the time lock and enable its usage on the Nervos Network.

# CKB_TX
input:
  rgb_xudt:
    type: xudt
    lock:
      code: BTC_TIME_lock
      args: lock_script | 6 | btc_tx

output:
  rgb_xudt:
    type: xudt
    lock:
      lock_scriptwitness:
  # proof of 6 confirmations after #btx_tx

L2 -> L1 Bridge

The bridge from Nervos Layer 2 to Bitcoin Layer 1 is currently in development and is anticipated to be launched in the near future. The concept involves allowing users to provide the UTXO they own, identified by the transaction hash & Index. Subsequently, we can construct the CKB transaction to include it, thereby marking the ownership of the RGB++ assets. Consequently, when the user spends the UTXO on the Bitcoin Layer 1, they are essentially spending the RGB++ assets.

# CKB TX
input:
  xudt:
    type: xudt
    lock:
      ckb_address1

output:
  xudt:
    type: xudt
    lock:
      ckb_address2  rgb_xudt:
    type: xudt
    lock:    
      args: btc_utxo

Ecosystem Development Post Short-Term Bubble

On-chain Statistics

On-chain statistics do not lie, as the transactions of RGB++ are confined within CKB transactions. By examining Nervos network activity, we can gauge the impact of RGB++ on Nervos.

Between April 3, 2024, and April 3, 2024, there was a noticeable rise in the number of addresses, from 3.35 million to 3.66 million. This surge indicates that the wave of RGB++ has led to approximately 310,000 new addresses being created.

When it comes to transaction count, as illustrated in the diagram below, the daily Transactions Per Second (TPS) remains consistently below 1, hovering around 20,000 transactions per day, equivalent to 0.25 TPS. During a surge in activity related to RGB++, it peaked at 107.94K transactions during this timeframe, almost five times the average level. However, it still falls short of our expectations. We are not surprised by the exceptionally high TPS achieved by some new Layer 1s. The reason the TPS remains at around 1 TPS is due to the fact that the mechanism of RGB++ emulates transactions on the Bitcoin network, thus its ceiling is constrained by the limitations of the Bitcoin mainnet.

Core Assets

There are three major assets on the Nervos Network.

The first is the recently popular RGB++, represented as xUDT on Nervos. Among them, Seal is the initial RGB++ asset deployed by JoyID founder. Initially intended as a test token, it eventually emerged as the top memecoin on Nervos.

Secondly, the inscription assets emerged during the wave of inscription in the early days of this year. The most prominent among them is called MEMES, but its volume and market cap cannot be compared with that of Seal.

The third aspect is the DOB, the NFT form on Nervos. The largest one to date is the Unicorn Box, which is owned by the most loyal stakers and long-term users in the community. It offers a more composable future and other features. Another highly anticipated collection is NerveApe, which was launched in recent days.

Ecosystem and Future Protocol Development

Behind the core assets mentioned above are several robust teams working on building the infrastructure, many of whom have direct connections to the Nervos team. Here are some of the most useful products listed below:

JoyID

JoyID serves as the native passkey wallet that supports both Nervos L2 and Bitcoin L1. It also extends its support to EVM networks such as Ethereum, Polygon, Arbitrum, and Scroll. Additionally, it features a built-in marketplace for trading DOBs, potentially being the first marketplace to facilitate the trading of Unicorn Box.

HueHub

HueHub stands out as the first marketplace supporting the trading of RGB++ assets from day one. It also launched its own launchpad to assist the community in launching their tokens.

Omiga

Omiga is the first inscription platform that remained silent until the RGB++ wave and returned with a marketplace that now supports all xUDT tokens.

UTXO Stack

UTXO Stack represents a beacon of hope for Nervos’ future. Its goal is to construct a technology stack incorporating the UTXO model and a PoS chain.

On the positive side, Nervos boasts a robust foundation that only necessitates transitioning from a Proof of Work (PoW) consensus mechanism to a Proof of Stake (PoS) system. As the sole UTXO Layer 2 solution for Bitcoin, Nervos occupies a unique position within the ecosystem, highlighting its relevance and importance in facilitating scalability and additional functionalities for the Bitcoin network. This distinct advantage potentially opens up new opportunities for innovation and diverse usage scenarios.

Nevertheless, Nervos encounters challenges due to the scarcity of developers proficient in UTXO model contracts. The ecosystem’s shortcomings in this area underscore the necessity of talent acquisition and skill development to fully capitalize on the capabilities of the UTXO model. The lack of skilled developers could impede the network’s advancement, emphasizing the critical need to bolster the developer community.

Another area of concern pertains to the alliance’s efforts in constructing a UTXO chain, which may require token incentives to attract and retain participants. The limited demand for UTXO models beyond Bitcoin poses a significant challenge, as incentives and compelling use cases are crucial for establishing and sustaining a thriving ecosystem centered around this model.

Looking ahead, numerous aspects warrant observation. Securing sufficient capital support is essential for expanding and enhancing Nervos’ ecosystem. Adequate funding can drive development, innovation, and community involvement, propelling the network’s growth and sustainability in the long term. Moreover, the growth of the developer community will play a pivotal role in shaping Nervos’ trajectory. By cultivating a dynamic and diverse community of skilled developers, Nervos can tap into a wealth of expertise, foster creativity and collaboration, accelerate the network’s progress, and cultivate a vibrant ecosystem of applications and solutions.

Comprehensive Evaluation

Technical Perspective

From a technical viewpoint, the concept of encrypting messages and validating them through an indexer or another layer is not entirely new, as it is shared by protocols like Ordinals and RGB, among others. However, most protocols differentiate themselves in one way or another.

The Nervos team’s rationale for dubbing their new protocol “RGB++” is to address the perceived limitations of RGB. Nonetheless, these may not necessarily be weaknesses but rather trade-offs inherent in the protocol’s design.

At the core of RGB lies its utilization of CSV, which, while entailing technical complexities, ultimately offers scalability and heightened privacy for users. The security framework of RGB is rooted in Bitcoin and user verification, enabling users to authenticate the state of their own assets.

In contrast, RGB++ trades off security, privacy, and scalability — key objectives that RGB aims to achieve — in favor of quick deployment and gaining an early market presence. Privacy is compromised as all information is exposed on-chain, and scalability is constrained on the Bitcoin mainnet as Layer 2 solely reconstructs cells to incorporate UTXOs on Bitcoin without data compression or parallelization mechanisms.

The security model for RGB++ entails Bitcoin and Nervos, mirroring transactions on Nervos and validating them on Bitcoin to establish trust in the Nervos network. While theoretically compatible with RGB, it is improbable that LNP/BP will back RGB++ assets in the short or long term.

The terminologies introduced in the initial section are not revolutionary but essentially rebrand certain elements, such as renaming “Bridge” to “Leap” and “Lock Script” to “Binding.”

Marketing Perspective

From a marketing and storytelling standpoint, Nervos has undoubtedly achieved short-term success by capturing the community’s attention and reemerging after years of dormancy. By bypassing RGB’s challenges and launching ahead of the v0.11 release, they have generated significant buzz.

One noteworthy aspect is Nervos’ assertion that their UTXO and PoW design make it the most suitable Layer 2 solution for Bitcoin. While we won’t delve into the UTXO vs. Account Model or PoW vs. PoS debates, the success of Ethereum and its various EVM-compatible Layer 2 solutions underscores the advantages of having a large developer community and user base.

On the developer front, utilizing existing resources from Ethereum ecosystems streamlines the creation of new layers, that’s reason why both Ethereum and Bitcoin Layer 2 build with EVM compatibility. The scarcity of UTXO model experts and Bitcoin’s lack of Turing completeness hinder the adoption of UTXO-based scaling solutions until development matures.

From a user perspective, seamless wallet migration to Layer 2 promotes adoption, although only a limited number of wallets, such as JoyID by Nervos insiders, currently support both Bitcoin and Nervos simultaneously. There is still progress to be made in convincing other wallet builders to integrate Nervos.

Insights

In conclusion, amidst Bitcoin’s scaling exploration, a degree of consensus and cohesion has been achieved within the ecosystem. Until Bitcoin’s mainnet upgrades to enable Turing complete scripts, offloading verifications to external layers and treating Bitcoin as a publishing layer may be the preferred approach. The UTXO model serves as an irreversibly secure state record, embodying the crux of single-use seals.

This approach diverges significantly from Ethereum’s scaling solutions, hinting at the emergence of similar protocols in the near future. At the same time, we would also expect the Bitcoin Layer 1 script could bring out some novel designs.

Reference

Disclaimer: This article is provided for informational purposes only and should not be considered as financial advice. The cryptocurrency market is highly volatile and unpredictable. Always conduct thorough your own research and consult with a qualified financial professional before making any investment decisions.