Nervos CKB Research Report

The following content is reprinted from Mirror, authored by NingNing, with the original title "CKB: A New Chapter in Bitcoin Programmability," and the original link: https://mirror.xyz/0xB239e7668B6dAF0122166E2De879Da87FF47858C/hkXPFe0uBy2fQNIzjVrL0rMUONj2hTJklaN14Rbguuk

Copy the following link into your browser to view and download the PDF version: https://drive.google.com/file/d/1KPNbTGIueA0dtINso6LGX-vK4nU1Syid/view

Introduction#

In the fourth round of the Bitcoin halving cycle, the explosive adoption of the Ordinals protocol and similar protocols has made the crypto industry aware of the positive externality value of issuing and trading assets based on Bitcoin's L1 layer for the consensus security and ecological development of the Bitcoin mainnet, marking it as the "Uniswap moment" of the Bitcoin ecosystem.

The evolution and iteration of Bitcoin's programmability is the result of the governance of the opinion market within the Bitcoin community, rather than being driven by purposes for BTC holders or builders of block space.

Currently, enhancing Bitcoin's programmability to increase the utilization of Bitcoin mainnet block space has become a new design space for consensus within the Bitcoin community.

Unlike Ethereum and other high-performance public chains, the design space for Bitcoin programmability is highly constrained to ensure the simplicity and lightweight nature of the UTXO set, fundamentally limited to how scripts and OP Codes operate on UTXOs.

Classic Bitcoin programmability solutions include state channels (Lightning Network), client validation (RGB), sidechains (Liquid Network, Stacks, RootSock, etc.), CounterParty, Omni Layer, Taproot Assets, DLC, and so on. Emerging Bitcoin programmability solutions since 2023 include Ordinals, BRC20, Runes, Atomicals, Stamps, and more.

After the end of the second wave of inscriptions, a new generation of Bitcoin programmability solutions has emerged, such as CKB's UTXO isomorphic binding solution, EVM-compatible Bitcoin L2 solutions, DriveChain solutions, and more.

Compared to EVM-compatible Bitcoin L2 solutions, the Bitcoin programmability solution of CKB (Common Knowledge Base) is a native, secure solution that does not introduce social trust assumptions within the modern design space of Bitcoin programmability. Unlike the DriveChain solution, it does not require any changes at the Bitcoin protocol level.

In the foreseeable future, the growth curve of Bitcoin programmability will experience an accelerated growth phase, with assets, users, and applications in the Bitcoin ecosystem ushering in a wave of explosive growth. The UTXO Stack of the CKB ecosystem will provide newly incoming Bitcoin developers with the ability to build protocols using a modular stack. Additionally, CKB is exploring the integration of the Lightning Network with the UTXO Stack to achieve interoperability between new protocols using Bitcoin's native programmability.

The Namespace of Bitcoin Programmability#

Blockchain is a machine for creating trust, and the Bitcoin mainnet is the zero machine within it. Just as all Western philosophy is a footnote to Plato, everything in the crypto world (assets, narratives, blockchain networks, protocols, DAOs, etc.) is a derivative and byproduct of Bitcoin.

In the co-evolution process between Bitcoin Maxis and scalability proponents, the debate over whether the Bitcoin mainnet supports Turing completeness has led to forks, creating new crypto projects and reinforcing Bitcoin's community consensus. This is a process of self-confirmation while othering.

Due to Satoshi Nakamoto's mysterious disappearance, Bitcoin community governance does not have the "enlightened monarchic" governance structure like Ethereum, but rather an open game model achieved through miners, developers, communities, and markets to reach equilibrium. This gives Bitcoin's community consensus a characteristic of being exceptionally robust once formed.

Currently, the characteristics of Bitcoin community consensus include: consensus is not command and control, trust minimization, decentralization, censorship resistance, pseudonymity, open source, open collaboration, permissionless, legally neutral, homogeneity, forward compatibility, minimal resource usage, verification > computation, convergence, transaction immutability, resistance to DoS attacks, avoidance of entry competition, robustness, incentive alignment, solidification, immutable consensus, conflict principles, and collaborative advancement, among others.[1]

The current form of the Bitcoin mainnet can be seen as the instantiated result of the above characteristics of Bitcoin community consensus. The design space of Bitcoin programmability is also defined by the characteristics of Bitcoin community consensus.

Classic Design Space of Bitcoin Programmability#

While other public chains explore modularization, parallelization, and other solutions to address the blockchain trilemma, the design space of the Bitcoin protocol has always focused on scripts, OP Codes, and UTXOs.

Two typical instances are the two major upgrades of the Bitcoin mainnet since 2017: Segwit hard fork and Taproot soft fork.

The Segwit hard fork in August 2017 added 3M of block space outside the 1M main block specifically for storing signatures (witnesses) and set the weight of signature data to 1/4 of the main block data when calculating miner fees, maintaining consistency in the cost of spending a UTXO output and creating a new UTXO output, preventing the abuse of UTXO change increasing the speed of UTXO set expansion.

The Taproot soft fork in November 2021 introduced the Schnorr multi-signature scheme, saving UTXO verification time and the block space occupied by multi-signatures.

A key-value pair of 1 UTXO (Image source: learnmeabitcoin.com)

UTXO (Unspent Transaction Output) is the fundamental data structure of the Bitcoin mainnet, characterized by atomicity, non-homogeneity, and chain coupling. Each transaction on the Bitcoin mainnet consumes one UTXO as input while creating n new UTXO outputs. Simply put, UTXOs can be seen as running dollars, euros, and other paper currencies on the chain; they can be spent, changed, split, combined, etc., with the smallest atomic unit being satoshis (sats). One UTXO represents the latest state at a specific time. The UTXO set represents the latest state of the Bitcoin mainnet at a specific time.

By maintaining the simplicity, lightweight nature, and verifiability of the Bitcoin UTXO set, the speed of state inflation on the Bitcoin mainnet has successfully stabilized at a level compatible with Moore's Law, ensuring the participatory nature of full nodes on the Bitcoin mainnet and the robustness of transaction verification.

Correspondingly, the design space of Bitcoin programmability is also constrained by the characteristics of Bitcoin community consensus. For example, to prevent potential security risks, Satoshi Nakamoto decided in August 2010 to remove the OP-CAT opcode, which was a key logic for achieving Turing completeness in Bitcoin programmability.

The implementation path of Bitcoin programmability does not adopt on-chain virtual machine (VM) solutions like Ethereum or Solana, but instead chooses to programmatically operate on UTXOs, transaction input fields, output fields, and witness data using scripts and opcodes (OP Codes).

The main toolbox for Bitcoin programmability includes: multi-signatures, time locks, hash locks, and flow control (OP_IF, OP_ELIF).[2]

Under the classic design space, Bitcoin programmability is very limited, supporting only a few verification programs and not supporting on-chain state storage and on-chain computation, while on-chain state storage and on-chain computation are precisely the core functional components for achieving Turing completeness.

The Renaissance of Bitcoin Programmability#

However, the design space of Bitcoin programmability is not a fixed state. On the contrary, it is more like a dynamic spectrum that changes over time.

Contrary to the stereotype that Bitcoin mainnet development has stagnated, the development, deployment, adoption, and promotion of new scripts and opcodes on the Bitcoin mainnet have always been ongoing, even triggering fork wars in the crypto community at certain times (such as the Segwit hard fork).

Taking the adoption of Bitcoin mainnet script types as an example, we can clearly perceive the changes. The scripts used in Bitcoin mainnet output types can be divided into three main categories:

Original scripts: pubkey, pubkeyhash
Enhanced scripts: multisig, scripthash
Witness scripts: witness_v0_keyhash, witness_v0_scripthash, witness_v1_taproot

Historical output types of the Bitcoin mainnet; Source: Dune

From the trend chart of historical output types of the Bitcoin mainnet, we observe a basic fact: the enhancement of Bitcoin mainnet programmability is a long-term historical trend, with enhanced scripts consuming the share of original scripts, while witness scripts are consuming the share of enhanced scripts. The wave of asset issuance on Bitcoin L1 initiated by the Ordinals protocol based on Segwit enhanced scripts and Taproot witness scripts is both a continuation of the historical trend of Bitcoin mainnet programmability and a new phase of Bitcoin mainnet programmability.

The opcodes of the Bitcoin mainnet also have a similar evolutionary process to the Bitcoin mainnet scripts.

For example, the Ordinals protocol achieves its functional design by combining the Bitcoin mainnet script taproot script-path spend with opcodes (OP_FALSE, OP_IF, OP_PUSH, OP_ENDIF).

An inscription instance of the Ordinals protocol

Before the official birth of the Ordinals protocol, classic Bitcoin programmability solutions mainly included state channels (Lightning Network), client validation (RGB), sidechains (Liquid Network, Stacks, RootSock, etc.), CounterParty, Omni Layer, DLC, and so on.

The Ordinals protocol serializes the smallest atomic unit of UTXO, satoshis, engraves the data content in the witness field of the UTXO, and associates it with a specific serialized satoshi, then an off-chain indexer is responsible for indexing and executing these data state programmability operations. This new paradigm of Bitcoin programmability is vividly likened to "carving flowers on gold."

The new paradigm of the Ordinals protocol has sparked enthusiasm in a broader range of the crypto community to use Bitcoin mainnet block space for issuing, minting, and trading NFT collectibles and meme-type tokens (collectively referred to as inscriptions), with many people owning their Bitcoin addresses for the first time in their lives.

However, the programmability of the Ordinals protocol inherits the limitations of Bitcoin's programmability, supporting only three functional methods: Deploy, Mint, and Transfer. This means that the Ordinals protocol and its followers, such as BRC20, Runes, Atomicals, Stamps, etc., are only suitable for asset issuance application scenarios. Support for transaction and lending DeFi application scenarios that require state computation and state storage is relatively weak.

Number of TX types for the Ordinals protocol (Image source: Dune)

Liquidity is the source of vitality for assets. Due to the inherent characteristics of the Ordinals type Bitcoin programmability protocol, the emphasis on reissuing inscription assets rather than providing liquidity affects the overall lifecycle value generated by an inscription asset.

Moreover, the Ordinals and BRC20 protocols are suspected of abusing witness data space, objectively causing an explosion of state on the Bitcoin mainnet.

Changes in Bitcoin block space size (Image source: Dune)

As a reference, the main sources of Ethereum mainnet gas fees are DEX trading gas fees, L2 data availability fees, and stablecoin transfer gas fees. Compared to the Ethereum mainnet, the income types of the Bitcoin mainnet are singular, highly periodic, and volatile.

The programmability capabilities of the Bitcoin mainnet are still insufficient to meet the supply-side demand for Bitcoin mainnet block space. Achieving a stable and sustainable block space income state like the Ethereum mainnet requires native DEX, stablecoins, and L2 in the Bitcoin ecosystem. The prerequisite for implementing these protocols and applications is that Bitcoin programmability protocols need to provide Turing-complete programming capabilities.

Therefore, how to achieve Turing-complete programmability for Bitcoin natively while constraining the negative impact on the scale of Bitcoin mainnet state has become a current hot topic in the Bitcoin ecosystem.

CKB's Solution for Bitcoin Programmability#

Currently, the solutions to achieve native Turing-complete programmability for Bitcoin include: BitVM, RGB, CKB, EVM-compatible Rollup L2, DriveChain, and so on.

BitVM constructs a Bitcoin-native VM using a set of OP Codes to build NAND logic gates, and then builds other basic logic gates through NAND logic gates, ultimately constructing a Bitcoin-native VM from these basic logic gate circuits. This principle is somewhat similar to the Qin Wang array diagram from the famous science fiction novel "The Three-Body Problem." The Netflix adaptation of the same name presents specific scenes. The BitVM solution's paper has been fully open-sourced and is highly anticipated by the crypto community. However, its engineering implementation is very challenging, facing issues such as off-chain data management costs, limitations on the number of participants, challenge-response interaction times, and hash function complexity, making it difficult to land in the short term.

The RGB protocol achieves Turing-complete programmability using client validation and one-time sealing technology, with the core design idea of storing the state and logic of smart contracts on the outputs of Bitcoin transactions, executing the maintenance of smart contract code and data storage off-chain, with the Bitcoin mainnet serving as the final state commitment layer.

EVM-compatible Rollup L2 is a solution that quickly reuses mature Rollup L2 stacks to build Bitcoin L2. However, since the Bitcoin mainnet currently cannot support fraud proofs/validity proofs, Rollup L2 needs to introduce social trust assumptions (multi-signatures).

DriveChain is a sidechain expansion solution, with the basic design idea of using Bitcoin as the underlying blockchain, creating sidechains by locking Bitcoin, thus achieving bidirectional interoperability between Bitcoin and sidechains. The implementation of the DriveChain project requires protocol-level changes to Bitcoin, specifically deploying the proposed BIP300 and BIP301 to the mainnet.

The above Bitcoin programmability solutions either have extremely high engineering difficulty and are unlikely to land in the short term, or introduce excessive social trust assumptions, or require protocol-level changes to Bitcoin.

Bitcoin L1 Asset Protocol: RGB++#

In response to the shortcomings and issues of the above Bitcoin programmability protocols, the CKB team has provided a relatively balanced solution. This solution consists of the Bitcoin L1 asset protocol RGB++, the Bitcoin L2 Raas service provider UTXO Stack, and interoperability protocols integrated with the Lightning Network.

The native primitive of UXTO: isomorphic binding

RGB++, is a Bitcoin L1 asset issuance protocol developed based on the RGB design philosophy. The engineering implementation of RGB++ inherits the technical primitives of both CKB and RGB. It utilizes RGB's "one-time sealing" and client validation technology while mapping Bitcoin UTXOs to CKB mainnet Cells (an extended version of UTXO) through isomorphic binding, using CKB and Bitcoin chain scripts to verify the correctness of state computation and the validity of ownership changes.

In other words, RGB++ expresses the ownership relationship of RGB assets using Cells on the CKB chain. It moves the asset data originally stored locally in the RGB client to the CKB chain in the form of Cells, establishing a mapping relationship with Bitcoin UTXOs, allowing CKB to serve as a public database and off-chain pre-settlement layer for RGB assets, replacing the RGB client to achieve more reliable data hosting and RGB contract interaction.

Isomorphic binding of RGB++ (Image source: RGB++ Protocol Light Paper)

Cells are the basic data storage unit of CKB, capable of containing various data types, such as CKBytes, tokens, TypeScript code, or serialized data (like JSON strings). Each Cell contains a small program called a Lock Script, which defines the owner of the Cell. The Lock Script supports scripts from the Bitcoin mainnet, such as multi-signatures, hash locks, time locks, etc., and also allows the inclusion of a TypeScript to execute specific rules to control its usage. This enables developers to customize smart contracts based on different use cases, such as issuing NFTs, airdropping tokens, AMM swaps, and more.

The RGB protocol attaches the state root of off-chain transactions to the output of a UTXO using the OP RETURN opcode, treating that UTXO as a container for state information. Then, RGB++ maps this state information container built by RGB to a Cell on CKB, storing the state information in the Cell's type and data, treating this container UTXO as the owner of the Cell state.

Lifecycle of RGB++ transactions (Image source: RGB++ Protocol Light Paper)

As shown in the above diagram, a complete lifecycle of an RGB++ transaction is as follows:

Off-chain computation. When initiating a transaction with isomorphic binding, a new UTXO btc_utxo#2 from the Bitcoin mainnet must first be selected as a one-time sealing container, then an off-chain hash computation is performed on the original Cell's isomorphic bound UTXO btc_utxo#1, the new Cell's isomorphic bound btc_utxo#2, and a CKB TX that uses the original Cell as input and the new Cell as output to generate a commitment.
Submit Bitcoin transaction. RGB++ initiates a Bitcoin mainnet transaction, using the isomorphic bound btc_utxo#1 as input, and outputs the commitment generated in the previous step using OP RETURN.
Submit CKB transaction. Execute the CKB transaction generated from the off-chain computation before the CKB mainnet execution.
On-chain verification. The CKB mainnet runs a lightweight Bitcoin mainnet client to verify the entire system's state changes. This is very different from RGB, where state change verification uses a P2P mechanism, requiring the initiator and receiver of the transaction to be online simultaneously and interactively verify only the relevant TX graph.

Based on the above isomorphic binding logic, RGB++ gains some new features while relinquishing part of its privacy: blockchain-enhanced client validation, transaction folding, shared state of ownerless contracts, and non-interactive transfers.

Blockchain-enhanced client validation. RGB++ allows users to choose to maintain consensus security through PoW, validating state computations and ownership changes of URXO-Cells.
Transaction folding. RGB++ supports mapping multiple Cells to a single UTXO, thus achieving elastic scalability for RGB++.
Ownerless smart contracts and shared state. One major difficulty in implementing Turing-complete smart contracts with UTXO state data structures is ownerless smart contracts and shared state. RGB++ can leverage CKB's global state Cells and intent Cells to solve this issue.
Non-interactive transfers. RGB++ makes the client validation process of RGB optional, no longer requiring interactive transfers. If users choose CKB to validate state computations and ownership changes, the transaction interaction experience remains consistent with the Bitcoin mainnet.

Additionally, RGB++ inherits the state space privatization feature of CKB mainnet Cells. Each RGB++ transaction, in addition to paying miner fees for using Bitcoin mainnet block space, also needs to pay an additional fee for leasing Cell state space (this fee is returned after the Cell is consumed). The privatization of Cell state space is a defensive mechanism invented by CKB to address the explosion of state on the blockchain mainnet, requiring state space lessees to continuously pay during usage (diluting value in the form of inflation of circulating tokens). This makes the RGB++ protocol a responsible Bitcoin mainnet programmability extension protocol, capable of limiting the abuse of Bitcoin mainnet block space to some extent.

Trustless L1<>L2 Interoperability: Leap

The isomorphic binding of RGB++ is a synchronous atomic implementation logic that either occurs simultaneously or reverses simultaneously, with no intermediate state. All RGB++ transactions will simultaneously appear as a transaction on both the BTC and CKB chains. The former is compatible with transactions of the RGB protocol, while the latter replaces the client validation process, allowing users to verify the correctness of the state computation of this RGB++ transaction by checking the relevant transactions on CKB. However, users can also choose not to use transactions on the CKB chain as a basis for verification, independently verifying RGB++ transactions using the local relevant Tx graph of UTXOs (some functions like transaction folding still rely on the block header hash of CKB for double-spending verification).

Thus, the cross-chain asset transfer between RGB++ and the CKB mainnet does not rely on introducing additional social trust assumptions, such as relay layers for cross-chain bridges or centralized multi-signature vaults for EVM-compatible Rollups. RGB++ assets can be natively and trustlessly transferred from the Bitcoin mainnet to the CKB mainnet or from the CKB mainnet to the Bitcoin mainnet. CKB refers to this cross-chain workflow as Leap.

RGB++ and CKB maintain a loosely coupled relationship. In addition to supporting Bitcoin L1 assets (not limited to RGB++ protocol native assets, including assets issued using Runes, Atomicals, Taproot Assets, etc.) to Leap to CKB, the RGB++ protocol also supports Leap to other UTXO Turing-complete chains like Cardano. At the same time, RGB++ also supports Bitcoin L2 assets to Leap to the Bitcoin mainnet.

The Extended Features and Application Examples of RGB++

The RGB++ protocol natively supports the issuance of fungible tokens and NFTs.

The fungible token standard of RGB++ is xUDT, and the NFT standard is Spore, among others.

The xUDT standard supports various methods of issuing fungible tokens, including but not limited to centralized distribution, airdrops, subscriptions, etc. The total supply of tokens can also be chosen between unlimited and preset limits. For tokens with preset limits, a state-sharing scheme can be used to verify that the total number issued each time is less than or equal to the preset limit.

The Spore standard in NFTs will store all metadata on-chain, achieving 100% data availability security. Assets issued under the Spore protocol, known as DOB (Digital Object), are similar to Ordinals NFTs but have richer features and gameplay.

As a client validation protocol, the RGB protocol naturally supports state channels and the Lightning Network, but due to the limitations of Bitcoin's script computation capabilities, it is very challenging to trustlessly introduce assets outside of BTC into the Lightning Network. However, the RGB++ protocol can leverage CKB's Turing-complete scripting system to implement state channels and the Lightning Network for RGB++ assets based on CKB.

With the above standards and features, the use cases of the RGB++ protocol are not limited to simple asset issuance scenarios like other Bitcoin mainnet programmability protocols, but support complex application scenarios such as asset trading, asset lending, and CDP stablecoins. For example, the isomorphic binding logic of RGB++ combined with the native PSBT scripts of the Bitcoin mainnet can achieve a DEX in an order book grid form.

Bitcoin L2 RaaS Service Provider: UTXO Stack#

UTXO Isomorphic Bitcoin L2 vs EVM-Compatible Bitcoin Rollup L2

In the competitive market of Turing-complete Bitcoin programmability implementation solutions, DriveChain and the restoration of the OPCAT opcode require changes at the Bitcoin protocol layer, leading to significant uncertainty and unpredictability in time and cost. In contrast, the UTXO isomorphic Bitcoin L2 and EVM-compatible Bitcoin Rollup L2 are more recognized by developers and capital. UTXO isomorphic Bitcoin L2 is represented by CKB, while EVM-compatible Bitcoin Rollup L2 is represented by MerlinChain and BOB.

Realistically speaking, the Bitcoin L1 asset issuance protocol has just begun to form partial consensus within the Bitcoin community, while the community consensus on Bitcoin L2 is still in its early stages. However, in this frontier field, "Bitcoin Magazine" and Pantera have attempted to define the scope of Bitcoin L2 by borrowing the conceptual structure of Ethereum L2.

In their view, Bitcoin L2 should have the following three characteristics:

Use Bitcoin as the native asset. Bitcoin L2 must use Bitcoin as its primary settlement asset.
Use Bitcoin as a settlement mechanism to enforce transactions. Users of Bitcoin L2 must be able to enforce the return of their control over layer one assets (trustworthy or untrustworthy).
Demonstrate functional dependency on Bitcoin. If the Bitcoin mainnet fails but the Bitcoin L2 system can still operate, then that system is not Bitcoin's L2.[4]

In other words, they believe that Bitcoin L2 should have data availability verification based on the Bitcoin mainnet, an escape pod mechanism, and BTC as the gas token for Bitcoin L2. This suggests that they subconsciously view the EVM-compatible L2 paradigm as the standard template for Bitcoin L2.

However, the weak state computation and verification capabilities of the Bitcoin mainnet cannot achieve characteristics 1 and 2 in the short term. In this case, EVM-compatible L2s are entirely dependent on social trust assumptions as off-chain expansion solutions, even though they claim in their whitepapers to integrate BitVM for data availability verification and enhance security through joint mining with the Bitcoin mainnet.

Of course, this does not mean that these EVM-compatible Rollup L2s are not real Bitcoin L2s; rather, they have not achieved a good balance between security, trustlessness, and scalability. Moreover, introducing Ethereum's Turing-complete solutions into the Bitcoin ecosystem is likely to be viewed by Bitcoin Maxis as appeasement of the scalability route.

Therefore, UTXO isomorphic Bitcoin L2 naturally has superiority in orthodoxy and consensus within the Bitcoin community compared to EVM-compatible Rollup L2.

Characteristics of UTXO Stack: Fractal Bitcoin Mainnet

If Ethereum L2 is a fractal of Ethereum, then Bitcoin L2 should be a fractal of Bitcoin.

The UTXO Stack of the CKB ecosystem allows developers to launch UTXO Bitcoin L2 with one click and natively integrates RGB++ protocol capabilities. This enables seamless interoperability between the Bitcoin mainnet and UTXO isomorphic Bitcoin L2 developed using UTXO Stack through the Leap mechanism. UTXO Stack supports staking BTC, CKB, and Bitcoin L1 assets to secure UTXO isomorphic Bitcoin L2.

UTXO Stack architecture (Image source: Medium)

UTXO Stack currently supports the free flow and interoperability of RGB++ assets between the Bitcoin Lightning Network — CKB Lightning Network — UTXO Stack parallel L2s. In addition, UTXO Stack also supports the free flow and interoperability of assets based on UTXO Bitcoin L1 programmability protocols such as Runes, Atomicals, Taproot Assets, Stamps, etc., between UTXO Stack parallel L2s — CKB Lightning Network — Bitcoin Lightning Network.

UTXO Stack introduces a modular paradigm into the construction field of Bitcoin L2, cleverly circumventing the issues of state computation and data availability verification on the Bitcoin mainnet. In this modular stack, Bitcoin serves as the consensus layer and settlement layer, CKB serves as the data availability layer, while UTXO Stack parallel L2s serve as the execution layer.

The Growth Curve of Bitcoin Programmability and the Future of CKB#

In fact, the inherent tension between the narrative of Bitcoin as digital gold and the narrative of Bitcoin as programmable has led some OGs in the Bitcoin community to view the rise of Bitcoin L1 programmability protocols since 2023 as a new wave of dust attacks on the Bitcoin mainnet. To some extent, the verbal battles between Bitcoin core developer Luke and BRC20 fans represent the third world war between Bitcoin Maxis and scalability proponents, following the debates over Turing completeness and block size.

However, there exists another perspective that views Bitcoin as an APP Chain of digital gold. From this perspective, it is precisely the positioning of the decentralized ledger underlying digital gold that shapes the current form of the Bitcoin mainnet UTXO set and its programmability characteristics. But if I remember correctly, Satoshi's vision was to make Bitcoin a P2P electronic currency. The demand for programmability from digital gold is for vaults and safes, while the demand for programmability from currency is for the circulation network of central banks and commercial banks. Therefore, the enhancement of Bitcoin's programmability protocols is not a deviation from the norm, but a return to Satoshi's vision.

Bitcoin is the first AppChain (Image source: @tokenterminal)

Using the research methodology of the Gartner Hype Cycle, we can categorize Bitcoin programmability solutions into five stages:

Technology emergence: DriveChain, UTXO Stack, BitVM, etc.
Expectation inflation: Runes, RGB++, EVM Rollup Bitcoin L2, etc.
Bubble burst: BRC20, Atomicals, etc.
Steady recovery: RGB, Lightning Network, Bitcoin sidechains, etc.
Maturity plateau: Bitcoin scripts, Taproot scripts, hash time locks, etc.

The Future of CKB: OP Stack+EigenLayer of the Bitcoin Ecosystem#

Whether it is EVM-compatible Bitcoin Rollup L2, UTXO isomorphic Bitcoin L2, or new paradigms like DriveChain, various implementations of Turing-complete programmability ultimately point to the Bitcoin mainnet as the consensus and settlement layer.

Just as convergent evolution repeatedly occurs in nature, it can be expected that the development trend of Turing-complete programmability in the Bitcoin ecosystem will exhibit a certain degree of consistency with the Ethereum ecosystem in some aspects. However, this consistency will not be a simple replication of Ethereum's tech stack into the Bitcoin ecosystem, but rather the realization of a similar ecological structure using Bitcoin's native tech stack (programmability based on UTXO).

The positioning of CKB's UTXO Stack is very similar to that of Optimism's OP Stack, where OP Stack maintains strong equivalence and consistency with the Ethereum mainnet at the execution layer, while UTXO Stack maintains strong equivalence and consistency with the Bitcoin mainnet at the execution layer. Additionally, both UTXO Stack and OP Stack have a parallel structure.

Current status of the CKB ecosystem (Image source: CKB Community)

In the future, UTXO Stack will launch shared sequencers, shared security, shared liquidity, shared verification sets, and other RaaS services to further lower the cost and difficulty for developers to launch UTXO isomorphic Bitcoin L2. Currently, a large number of decentralized stablecoin protocols, AMM DEXs, lending protocols, and autonomous world projects plan to use UTXO Stack to build UTXO isomorphic Bitcoin L2 as their underlying consensus infrastructure.

Unlike other Bitcoin security abstraction protocols, CKB's consensus mechanism is consistent with the Bitcoin mainnet's PoW consensus mechanism, maintained by machine computing power to ensure the consistency of the consensus ledger. However, CKB's token economics has some differences from Bitcoin. To maintain consistency in the incentives for block space production and consumption, Bitcoin chooses to introduce a weight and vByte mechanism to calculate state space usage fees, while CKB opts for state space privatization.

The token economics of CKB consists of two parts: base issuance and secondary issuance. All CKB from base issuance is fully rewarded to miners, while the purpose of secondary issuance of CKB is to collect state rent, with the specific distribution ratio of secondary issuance depending on how the currently circulating CKB is used in the network.

For example, suppose that among all circulating CKB, 50% is used for state storage, 30% is locked in NervosDAO, and 20% is kept entirely liquid. Then, 50% of the secondary issuance (i.e., the rent for state storage) will be allocated to miners, 30% will be allocated to NervosDAO depositors, and the remaining 20% will be allocated to the treasury fund.

This token economic model can constrain the growth of global state, coordinate the interests of different network participants (including users, miners, developers, and token holders), and create an incentive structure that benefits everyone, which is different from the situation of other L1s in the market.

Additionally, CKB allows a single Cell to occupy a maximum of 1000 bytes of state space, granting CKB NFTs some unique characteristics not found in similar assets on other blockchains, such as native gas fee carrying and programmability of state space. These unique characteristics make UTXO Stack very suitable as the infrastructure for building digital physical realities in autonomous world projects.

UTXO Stack allows Bitcoin L2 developers to stake BTC, CKB, and other Bitcoin L1 assets to participate in its network consensus.

Conclusion#

The development of Bitcoin to the stage of Turing-complete programmability solutions is inevitable. However, Turing-complete programmability will not occur on the Bitcoin mainnet but will take place off-chain (RGB, BitVM) or on Bitcoin L2 (CKB, EVM Rollup, DriveChain).

Based on historical experience, one protocol will ultimately develop into a monopolistic standard protocol.

The key factors determining the competitiveness of Bitcoin programmability protocols are: 1. Achieving free flow of BTC between L1<>L2 without relying on additional social trust assumptions; 2. Attracting a sufficient scale of developers, capital, and users into its L2 ecosystem.

As a Bitcoin programmability solution, CKB utilizes isomorphic binding + CKB network to replace client validation, achieving the free flow of Bitcoin L1 assets between L1<>L2 without relying on additional social trust assumptions. Moreover, benefiting from the state space privatization feature of CKB Cells, RGB++ does not exert the same pressure of state explosion on the Bitcoin mainnet as other Bitcoin programmability protocols.

Recently, the initial asset issuance through RGB++ has successfully completed the hot start of the ecosystem, onboarding approximately 150,000 new users and a batch of new developers into the CKB ecosystem. For example, the one-stop solution for the Bitcoin L1 programmability protocol Stamps ecosystem, OpenStamp, has chosen to use UTXO Stack to build UTXO isomorphic Bitcoin L2 serving the Stamps ecosystem.

In the next phase, CKB will focus on building ecological applications, achieving the free flow of BTC between L1<>L2, and integrating the Lightning Network, striving to become the programmability layer for Bitcoin in the future.

Links mentioned in the article:

[1] https://nakamoto.com/what-are-the-key-properties-of-bitcoin/

[2] https://www.btcstudy.org/2022/09/07/on-the-programmability-of-bitcoin-protocol/# 一 - 引言

[3] https://medium.com/@ABCDE.com/cn-abcde - 我们为什么要投资 utxo-stack-91c9d62fa74e

[4] https://bitcoinmagazine.com/technical/layer-2-is-not-a-magic-incantation