A comprehensive understanding of the Bitcoin Layer 2 that proposed the RGB++ protocol: CKB

Compilation | GaryMa Wu on Blockchain

Since the emergence of Ordinals & inscriptions on Bitcoin, it has brought further traffic and attention to the Bitcoin network. Although protocols like Ordinals greatly enhance the programmability of the Bitcoin network, they essentially just "cleverly utilize" the "op_if" opcode in Bitcoin scripts, leading to these new asset issuance methods. Bitcoin is fundamentally just a decentralized ledger system, and its scripting system lacks Turing completeness, meaning these assets have no application beyond trading. Therefore, to further develop and prosper the Bitcoin ecosystem, exploring suitable L2 solutions for smart contract development on the Bitcoin network is urgent.

Currently, the categories of Bitcoin L2 solutions can be roughly divided into state channels (like Lightning Network), sidechains (like Liquid, Merlin), Rollups (like Rollkit), and client validation (like RGB, RGB++, Taro), among others. The most famous of these is the Lightning Network, which is an excellent choice in terms of scalability, security, and privacy, although progress appears relatively slow at the moment.

Therefore, given the current market heat and trends, we can tentatively categorize the current Bitcoin L2 camp into two types:

● EVM Camp: such as the currently popular staking airdrop Merlin, B²

● UTXO Camp: a faction derived from the UTXO model, such as CKB proposing RGB++

For the EVM camp, it primarily adopts sidechain technology, building a sidechain outside the Bitcoin network and using cross-chain bridges to transfer BTC and assets from EVM chains to L2, which can significantly improve performance but cannot achieve the security of the BTC mainnet. Meanwhile, leveraging the operation of staking airdrops and users' familiarity with EVM and related L2 technologies makes it easier to capture user mindset and market share.

For the UTXO camp, it represents a more native technical faction. The main character analyzed in this article, CKB, is a popular player in this track and has recently proposed the RGB++ extension protocol. However, while the UTXO camp may be relatively native and homogenous in technology, this very understanding barrier makes it difficult for many to grasp the advantages of such designs. This article will explain this type of Bitcoin L2 solution in conjunction with the CKB UTXO public chain and its related technical route.

Technical Background: UTXO Model & RGB

UTXO Model and Account Model

The account model is relatively easy to understand, similar to a bank account, where the total amount of funds is intuitively displayed as an overall balance, and the system only needs to track changes in user account balances. This is the model adopted by most public chains today, such as Ethereum.

The UTXO model, on the other hand, is closer to cash transactions, where you might have many different denominations of bills in hand. Each bill can be seen as a UTXO, meaning a sum of money you can use. In a system like Bitcoin, when you receive a Bitcoin transfer from someone else, that money is like a new bill in your wallet that you haven't used to pay for anything yet, so it is "Unspent Transaction Output." When you make a transaction, such as using 100 yuan to buy an item worth 40 yuan and receiving 60 yuan in change, this corresponds to using your current unspent UTXO (100 yuan) to create two new UTXOs: one for the item (40 yuan) and one for the change (60 yuan). Note: Understanding the UTXO model is key to understanding RGB and subsequent content.

RGB

In simple terms, we can say that Ordinals are about numbering and tracking the originally homogeneous smallest unit of Bitcoin, Satoshi, while inscriptions are about writing data content (which can be images, text, or even code) into the witness isolation area based on this, achieving the binding of data and Satoshis to complete the issuance and circulation of assets. However, as the Ordinals protocol has developed, people have gradually realized that storing all data on the Bitcoin mainnet has many drawbacks, including high transaction fees and increased congestion on the Bitcoin network, and fundamentally does not bring a programmable smart contract system to the Bitcoin network.

Years ago, developers proposed the idea of "only putting the most important parts of the data on-chain," which is the concept of RGB: only use the Bitcoin blockchain when necessary, moving the validation work of token transfers from the full-chain consensus layer to off-chain, verified only by the client of the receiving party, while leveraging Bitcoin's decentralized network to prevent double spending and censorship resistance.

Perhaps comparing the differences between Ordinals and RGB can help readers understand more easily:

● RGB binds related assets to UTXOs, while Ordinals binds them more specifically to the smallest unit, Satoshi;

● RGB only writes the transaction commitment of related assets (i.e., a hash value) to the Bitcoin main chain, while the specific verification process is kept off-chain, whereas all data and verification logic of Ordinals rely on the Bitcoin mainnet.

With the above content as a foundation, we can introduce the two core technologies of RGB:

One-Time Seal: Binding with UTXO

Assets issued under the RGB protocol do not exist on a specific public chain as a carrier (the same goes for current protocols like Ordinals/Atomicals), and each RGB-related asset token must specify a particular UTXO on the Bitcoin network corresponding to it. If someone owns a certain UTXO in the Bitcoin network, they also own the RGB-related asset token recorded in that specific RGB protocol. To transfer RGB-related assets, the holder must spend that UTXO. Due to the one-time nature of UTXOs, once spent, it is gone, which corresponds to the spending of that RGB asset in the RGB protocol. This process of spending the UTXO is the process of opening the one-time seal. The advantage of this design is that when we need to verify a certain state of a contract, we do not need to obtain all the block data; each state of a contract must be attached to a specific Bitcoin UTXO, and once that state needs to change, the UTXO must be spent, and the transaction spending it must be confirmed by the blockchain. Moreover, through the transaction information attached to the UTXO, we can trace back to the initial state of this contract, allowing us to identify the essence of this state. Of course, RGB transactions are not verified like Bitcoin transactions between Bitcoin nodes; the RGB solution is client validation, meaning users verify themselves off-chain.

Client Validation

Unlike the Bitcoin mainnet, which broadcasts transaction data and synchronizes transaction verification records across all nodes, the RGB protocol places this process off-chain, with transaction information only transmitted between the sender and receiver. After the receiver verifies the transaction, they only need to record the data related to that transaction to meet the on-chain verification requirements.

Challenges and Difficulties Faced by RGB

Although the RGB protocol is excellently designed, it still faces numerous challenges:

● DA Problem: As mentioned earlier, transaction information is only transmitted between the sender and receiver, and the information needed (such as the historical branches of that UTXO) is difficult for ordinary users to obtain. Additionally, the data stored by various clients is independent of each other, leading to data island problems, making it impossible to view the global state of the contract.

● P2P Network Problem: RGB transactions, as an extension of Bitcoin, need to rely on a P2P network for propagation. When users conduct transfer transactions, they also need to perform interactive operations, and the receiver needs to provide a receipt. All of this relies on a P2P network independent of the Bitcoin network.

● Virtual Machine and Contract Language: The virtual machine of the RGB protocol currently mainly uses AluVM, which, as a new virtual machine, lacks comprehensive development tools and practical code.

● Unowned Contract Problem: The RGB protocol currently lacks a complete interaction scheme for unowned contracts (public contracts), making multi-party interactions difficult to achieve.

CKB Enters BTC L2 with RGB++

CKB's Transformation to BTC L2

CKB launched its mainnet in November 2019, adopting a PoW consensus mechanism and improving the UTXO model. CKB generalizes the UTXO model and names it the Cell model. Like UTXOs, Cells are transaction outputs, but Cells generalize the amount in UTXOs into capacity and data, transforming the original space for storing integers into a space that can hold arbitrary data.

Against the backdrop of the rising Bitcoin ecosystem, CKB has formulated the BTCKB "BTC+CKB" plan, hoping to transform into the first Bitcoin Layer 2 that is completely isomorphic with BTC (based on PoW+UTXO) through CKB's characteristics like "PoW+UTXO."

RGB++: An RGB Extension Protocol Based on CKB

On February 13, CKB officially released the RGB++ light paper.

RGB++ is an extension protocol based on the principles of RGB, leveraging the core point of RGB "UTXO" and the underlying architecture of CKB being homogenous, combining two key points of the RGB protocol with CKB's architecture:

● Isomorphic Binding: UTXOs as RGB containers can be bound and mapped to CKB's Cells.

● The off-chain client validation of RGB can be transformed into on-chain public validation in CKB, with the verified data and state corresponding to the data and type in the Cell.

In the RGB protocol, the two most important components are UTXOs for ownership identification and commitments for state management and one-time seals. The isomorphic binding of RGB++ maps each Bitcoin UTXO to CKB's Cells, using Bitcoin locks to achieve ownership synchronization and using the data and type of Cells to maintain state.

This not only solves the challenges faced by RGB mentioned above but also gives RGB more possibilities:

● The CKB blockchain will serve as an enhanced validation client: all RGB++ transactions will have a corresponding transaction on both the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter replaces the client validation process, allowing users to check the relevant transactions on CKB to verify whether the state calculation of this RGB++ transaction is correct. This eliminates the aforementioned DA problem and data island issues.

● Transaction Folding: The isomorphic binding of Bitcoin UTXOs and CKB Cells enables Turing-complete Bitcoin UTXO transactions supported by CKB Cell validation. If we further utilize the programmable capabilities of CKB Cells, we can correspond multiple CKB transactions to a single Bitcoin RGB++ transaction, thus allowing the low-speed, low-throughput Bitcoin chain to be scaled using the high-performance CKB chain.

● Non-Interactive Transfers: One issue with the original RGB protocol is that the receiving party must be online to complete a regular transaction, increasing user comprehension difficulty and product complexity. RGB++ can leverage the advantages of a Turing-complete environment to place interactive behavior within the CKB environment, using a send-receive two-step operation to achieve non-interactive transfer logic.

In summary, RGB++ inherits the core ideas of the RGB protocol, adopting different virtual machines and validation schemes. Users do not need a separate RGB++ client; they only need to access Bitcoin and CKB light nodes to complete all validations independently. RGB++ can also bring Turing-complete contract extensions and dozens of times performance improvements to Bitcoin. It does not use any cross-chain bridges but instead employs a native client validation scheme, ensuring security and censorship resistance.

What Advantages Does CKB Have in the BTC L2 Competition? What Are Its Future Plans?

Camp Comparison

As mentioned earlier, based on the current market heat and trends, Bitcoin L2 can be roughly divided into the "EVM Camp" and the "UTXO Camp."

● The "EVM Camp," led by Merlin and B², is engaged in a heated competition for staking TVL, attempting to seize the initial time window of the Bitcoin ecosystem to gain first-mover advantages and capture market share.

● The "UTXO Camp," led by CKB, leverages its technical accumulation of being completely isomorphic with BTC (based on PoW+UTXO) and the relatively recognized RGB and other extension protocols in the Bitcoin community, occupying a high ground of technical advantage, capable of providing Bitcoin with Turing-complete contract extensions and performance enhancements without cross-chain interactions or loss of security. However, it may not have the immediate impact of staking airdrop incentives in attracting ecological assets in the initial stages.

Route Arrangement

CKB's first product, RGB++, is expected to launch in early April, at which point RGB++ assets can be issued on the Bitcoin mainnet, potentially reigniting the asset issuance wave seen with protocols like Ordinals/Atomicals/Runes. Therefore, it may be worth paying attention to related asset issuance tools at that time, as there may be opportunities similar to inscriptions.

To promote the BTCKB plan, CKB has also established a CELL Studio company. For ease of understanding, one can compare CELL Studio to ConsenSys in the Ethereum ecosystem, focusing on bridging the BTC and CKB ecosystems.

In terms of market operations, CKB will hold two Bitcoin conferences:

● In March, Bitcoin Singapore will be held in Singapore, with around 100 participants, mainly targeting those who are very interested in the Bitcoin ecosystem, have some understanding of Bitcoin technology, but are not very familiar with the latest developments.

● In early April, the Wanxiang Blockchain Summit will co-host a Bitcoin special session with Bitcoin Magazine, which will be larger and more mainstream.

From a long-term perspective, CKB co-founder Cipher has expressed hope to integrate RGB++ with the Lightning Network by the end of the year. The Lightning Network will be the main battlefield for CKB's long-term efforts, allowing related RGB++ assets to circulate in the Bitcoin ecosystem through the Lightning Network without the need for cross-chain bridges.

Conclusion

Previously, CKB may have been seen as an "outlier" by most, as it chose the Bitcoin public chain technology route of PoW+UTXO while Ethereum shifted towards PoS. Thus, in the narrative context of new public chains and Rollup L2, CKB remained lukewarm. Now, as the market ignites the narrative of the Bitcoin L2 ecosystem, CKB has timely seized this opportunity, rapidly becoming a leading technical player in the current Bitcoin L2 track with its completely isomorphic characteristics and the launch of its innovative RGB++ protocol. It is no longer just focused on technology but is also engaging in market operations and brand promotion, establishing the ecosystem-leading company CELL Studio. Although CKB may not be the fastest to start in the current market for BTC L2, its technical advantages still position it as an important part of the Bitcoin ecosystem. After all, the current Bitcoin L2 narrative is unlikely to be a fleeting bubble but rather the beginning of the expansion of the Bitcoin network ecosystem.