CKB: A New Chapter in Bitcoin Programmability

Author: NingNing

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 a "Uniswap moment" for 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 teleological 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's 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 more. Emerging Bitcoin programmability solutions since 2023 include Ordinals, BRC20, Runes, Atomicals, Stamps, and others.

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, CKB (Common Knowledge Base)'s Bitcoin programmability solution is a native, secure solution that does not introduce social trust assumptions in the modern design space of Bitcoin programmability. Unlike DriveChain solutions, 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, and the assets, users, and applications of the Bitcoin ecosystem will usher 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 expansionists, from the debate over whether the Bitcoin mainnet supports Turing completeness to the debate over Segregated Witness solutions and large block expansion solutions, Bitcoin is constantly forking. This not only creates new crypto projects and community consensus but also reinforces and consolidates Bitcoin's own community consensus, 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 the interplay of miners, developers, the community, and the market. This endows Bitcoin's community consensus with an exceptionally robust characteristic 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, resource usage minimization, verification > computation, convergence, transaction immutability, resistance to DoS attacks, avoidance of rush entry, robustness, incentive alignment, solidification, consensus that should not be tampered with, conflicting principles, and collaborative advancement.[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.

The Classic Design Space of Bitcoin Programmability

While other public chains explore modularization, parallelization, and other solutions to tackle 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: the Segwit hard fork and the Taproot soft fork.

The Segwit hard fork in August 2017 added 3MB of block space outside the 1MB 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 UTXO output, preventing the abuse of UTXO change that increases the inflation rate of the UTXO set.

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.

1 UTXO key-value pair (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. Every transaction on the Bitcoin mainnet consumes one UTXO as input while creating n new UTXO outputs. Simply put, UTXOs can be viewed as dollar or euro bills running on the chain; they can be spent, change, split, combined, etc., with the smallest atomic unit being a satoshi (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 inflation rate of the Bitcoin mainnet's state has successfully stabilized at a level consistent with Moore's Law, ensuring the participatory nature of Bitcoin full nodes 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 key to 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 utilize scripts and opcodes (OP Code) to programmatically operate on UTXOs, transaction input fields, output fields, and witness data.

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

Within 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, which are 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 akin to 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) under various consensus vector limitations.

Taking the adoption of Bitcoin mainnet script types as an example, we can clearly perceive the changes. The scripts used for Bitcoin mainnet output types can be divided into three main categories: original scripts (pubkey, pubkeyhash), enhanced scripts (multisig, scripthash), and witness scripts (witnessv0keyhash, witnessv0scripthash, witnessv1taproot).

All historical output types of the Bitcoin mainnet (Source: Dune)

From the trend chart of all 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 consume 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 not only a continuation of the historical trend of Bitcoin mainnet programmability but also a new phase of Bitcoin mainnet programmability.

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

For example, the Ordinals protocol achieves its functional design by combining the Bitcoin mainnet script taproot script-path spend with opcodes (OPFALSE, OPIF, OPPUSH, OPENDIF).

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 others.

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

The new paradigm of the Ordinals protocol has sparked enthusiasm among 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 first Bitcoin address 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 makes the Ordinals protocol and its followers, such as BRC20, Runes, Atomicals, Stamps, etc., suitable only for asset issuance application scenarios. Support for transaction and lending scenarios in DeFi applications 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 an asset's vitality. Due to the inherent characteristics of Ordinals-type Bitcoin programmability protocols, inscriptions tend to emphasize asset reissuance over liquidity provision, which in turn affects the value generated throughout the lifecycle of an inscription asset.

Moreover, the Ordinals and BRC20 protocols are suspected of abusing witness data space, objectively causing a state explosion 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, among others. Compared to the Ethereum mainnet, the income types of the Bitcoin mainnet are singular, cyclical, and highly 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 natively achieve Turing-complete programmability for Bitcoin while constraining the negative impact on the scale of Bitcoin mainnet state has become a prominent academic focus in the Bitcoin ecosystem.

The CKB Solution for Bitcoin Programmability

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

BitVM constructs a native Bitcoin VM using a set of OP Codes to build NAND logic gates, then constructs other basic logic gates through NAND gates, ultimately creating a Bitcoin-native VM from these basic logic gate circuits. This principle is somewhat similar to the famous sci-fi novel "The Three-Body Problem" and is presented in specific scenes in the Netflix adaptation of the same name. 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, participant number limitations, challenge-response interaction counts, 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 being to store the state and logic of smart contracts on the outputs of Bitcoin transactions, while maintaining the 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 to quickly reuse mature Rollup L2 stacks to build Bitcoin L2. However, given that 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 being to use Bitcoin as the underlying blockchain, creating sidechains by locking Bitcoin to achieve bidirectional interoperability between Bitcoin and sidechains. The engineering implementation of DriveChain requires protocol-level changes to Bitcoin, specifically deploying the proposed BIP300 and BIP301 to the mainnet.

The aforementioned Bitcoin programmability solutions either face significant engineering challenges that make them difficult to implement in the short term, 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 proposed a relatively balanced solution. This solution consists of the Bitcoin L1 asset protocol RGB++, the Bitcoin L2 Raas service provider UTXO Stack, and an interoperability protocol integrated with the Lightning Network.

Native UTXO Primitives: 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 UTXOs) through isomorphic binding, using scripts on CKB and Bitcoin chains to verify the correctness of state computations 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 onto 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 and can contain 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 Type Script 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. RGB++ then maps this state information container built by RGB to a Cell on CKB, storing the state information in the Cell's type and data, with this container UTXO serving as the owner of the Cell's state.

RGB++ Transaction Lifecycle (Image source: RGB++ Protocol Light Paper)

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

1. Off-chain computation. When initiating a transaction with isomorphic binding, a new UTXO btcutxo#2 from the Bitcoin mainnet must first be selected as a one-time sealing container, followed by off-chain hashing of the original Cell's isomorphic bound UTXO btcutxo#1, the new Cell's isomorphic bound btc_utxo#2, and the CKB TX that uses the original Cell as input and the new Cell as output to generate a commitment.

2. Submit the Bitcoin transaction. RGB++ initiates a Bitcoin mainnet transaction, using the isomorphic bound btc_utxo#1 as input and employing OP RETURN to output the commitment generated in the previous step.

3. Submit the CKB transaction. Execute the CKB transaction generated from the off-chain computation before running on the CKB mainnet.

4. On-chain verification. The CKB mainnet runs a light client for the Bitcoin mainnet to verify the entire system's state changes. This is very different from RGB, where state change verification uses a P2P mechanism that requires the initiator and receiver of the transaction to be online simultaneously and interactively verify only the relevant TX graphs.

Based on the above isomorphic binding logic, RGB++ gains some new features while relinquishing part of its privacy compared to the RGB protocol: blockchain-enhanced client validation, transaction folding, ownerless contracts with shared states, 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 UTXO-Cells.

• Transaction folding. RGB++ supports mapping multiple Cells to a single UTXO, enabling flexible scalability for RGB++.

• Ownerless smart contracts and shared states. One major difficulty in achieving Turing-complete smart contracts with UTXO state data structures is the issue of ownerless smart contracts and shared states. RGB++ can leverage CKB's global state Cells and intent Cells to address this issue.

• Non-interactive transfers. RGB++ makes the client validation process of RGB optional, no longer requiring interactive transfers. If users choose to validate state computations and ownership changes through CKB, the interactive experience of the transaction 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 incurs 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 state explosion of blockchain mainnets, where the lessee of Cell state space must continuously pay during usage (diluting value in the form of CKB circulating token inflation). This makes the RGB++ protocol a responsible Bitcoin mainnet programmability expansion protocol, which can limit 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 flips simultaneously, with no intermediate state. All RGB++ transactions will simultaneously appear as one 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 RGB++ transaction's state computation 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 locally relevant Tx graph of UTXOs (some functions like transaction folding still rely on the CKB block header hash for double-spending verification).

Therefore, 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 vice versa. 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 Asset, 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 back to the Bitcoin mainnet.

Expansion 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, while the NFT standard is Spore, among others.

The xUDT standard supports various methods for issuing fungible tokens, including but not limited to centralized distribution, airdrops, subscriptions, etc. The total token supply 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 issued amount is less than or equal to the preset limit.

The Spore standard for NFTs stores 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 come with 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 also 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 script of the Bitcoin mainnet can realize 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, proposals like DriveChain and restoring the OP-CAT opcode require changes at the Bitcoin protocol layer, leading to significant uncertainty and unpredictability in time and costs. In contrast, the UTXO isomorphic Bitcoin L2 and EVM-compatible Bitcoin Rollup L2, represented by CKB, 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 a local consensus within the Bitcoin community, while the community consensus for 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 possess 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 a Bitcoin 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, subconsciously, they 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 situation, EVM-compatible L2s are entirely dependent on social trust assumptions as off-chain expansion solutions, even though they claim in their white papers 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 true 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 easily perceived by Bitcoin Maxis as appeasement of the expansionist route.

Therefore, UTXO isomorphic Bitcoin L2 naturally has an advantage in orthodoxy and consensus within the Bitcoin community over 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 BTC L1 assets to ensure the security of UTXO isomorphic Bitcoin L2.

UTXO Stack architecture (Image source: Medium)

The UTXO Stack currently supports the free flow and interoperability of RGB++ assets among Bitcoin Lightning Network, CKB Lightning Network, and parallel L2s built on UTXO Stack. Additionally, UTXO Stack supports the free flow and interoperability of UTXO-based Bitcoin L1 programmability protocol assets like Runes, Atomicals, Taproot Asset, and Stamps among parallel L2s on UTXO Stack, CKB Lightning Network, and Bitcoin Lightning Network.

UTXO Stack introduces a modular paradigm into the construction of Bitcoin L2, cleverly bypassing the issues of state computation and data availability verification on the Bitcoin mainnet. In this modular stack, Bitcoin serves as the consensus and settlement layer, CKB serves as the data availability layer, while the parallel L2s of UTXO Stack 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 war between Bitcoin core developer Luke and BRC20 fans is the third world war between Bitcoin Maxis and expansionists, following the debates over Turing completeness and block size.

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

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 in 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 occurs repeatedly 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 simply replicate Ethereum's technical stack in the Bitcoin ecosystem but will utilize Bitcoin's native technical stack (based on UTXOs) to achieve a similar ecological structure.

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, like the OP Stack structure, UTXO Stack is also a parallel structure.

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

In the future, UTXO Stack will launch RaaS services such as shared sequencers, shared security, shared liquidity, and shared validation sets, further reducing the cost and difficulty for developers to initiate 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, there are some differences in the token economics of CKB compared to 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 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 of all circulating CKB, 50% is used for state storage, 30% is locked in NervosDAO, and 20% is kept entirely liquid. In this case, 50% of the secondary issuance (i.e., the rent for state storage) will be distributed to miners, 30% will be distributed 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 differs 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 NFT assets on CKB some unique characteristics not found in similar assets on other blockchains, such as native gas fee carrying and state space programmability. 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 towards Turing-complete programmability is inevitable. However, Turing-complete programmability will not occur on the Bitcoin mainnet but rather off-chain (RGB, BitVM) or on Bitcoin L2 (CKB, EVM Rollup, DriveChain).

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

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

As a solution for Bitcoin programmability, 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++ has not exerted the pressure of state explosion on the Bitcoin mainnet like other Bitcoin programmability protocols.

Recently, the initial completion of the first batch of asset issuance through RGB++ has successfully hot-started the ecosystem, onboarding approximately 150,000 new users and a group of new developers to the CKB ecosystem. For instance, the one-stop solution OpenStamp for the Stamps ecosystem, a Bitcoin L1 programmability protocol, has chosen to use UTXO Stack to build a 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 future programmability layer for Bitcoin.