CKB: A New Chapter in Bitcoin's Programmability

Preface

During the fourth round of the Bitcoin halving cycle, the explosive adoption of protocols such as Ordinals has made the cryptocurrency industry realize the positive external value of issuing and trading assets on the Bitcoin L1 layer for the security and ecological development of the Bitcoin mainnet consensus, which can be described as the "Uniswap moment" of the Bitcoin ecosystem.

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

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

Unlike Ethereum and other high-performance public chains, the design space for Bitcoin's programmability is highly restricted in order to ensure the simplicity and lightweight nature of the UTXO set, with basic constraints on how to use scripts and OP Code to operate UTXOs.

Classic Bitcoin programmability solutions include state channels (Lightning Network), client-side validation (RGB), sidechains (Liquid Network, Stacks, RootSock, etc.), CounterParty, Omni Layer, Taproot Assets, DLC, and more. Since 2023, emerging Bitcoin programmability solutions include Ordinals, BRC20, Runes, Atomicals, Stamps, and others.

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

Compared to the EVM-compatible Bitcoin L2 scheme, CKB (Common Knowledge Base)'s Bitcoin programmability solution is a native, secure, and trustless solution in the modern design space of Bitcoin programmability. In comparison to the DriveChain scheme, it does not require any changes at the Bitcoin protocol level.

In the foreseeable future, the growth curve of Bitcoin's programmability will experience an accelerated growth phase, and the assets, users, and applications in the Bitcoin ecosystem will usher in a wave of Cambrian explosion. The UTXO Stack of the CKB ecosystem will provide the ability for newly incoming Bitcoin developers to build protocols using modular stacks. 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.

Namespace of Bitcoin Programmability

Blockchain is a trust machine, and the Bitcoin mainnet is the zeroth machine. Like all Western philosophy is a footnote to Plato, everything in the crypto world (assets, narratives, blockchain networks, protocols, DAOs, etc.) is a derivative and derivative of Bitcoin.

In the collaborative evolution process of Bitcoin Maximalists and scalability advocates, from the debate on whether the Bitcoin mainnet supports Turing completeness to the debate between the SegWit and large block scaling solutions, Bitcoin has been continuously forked. This process not only gives birth to new crypto projects and consensus in the crypto community, but also strengthens and consolidates the community consensus of Bitcoin itself, which is a process of self-affirmation while being otherized.

Due to Satoshi Nakamoto's mysterious disappearance, the governance of the Bitcoin community does not exist in a "benevolent autocracy" governance structure like Ethereum, but is balanced by open games among miners, developers, the community, and the market to achieve equilibrium governance model. This endows the community consensus of Bitcoin with the characteristic of once formed, exceptionally stable.

The current characteristics of Bitcoin community consensus include: consensus is not command and control, minimal trust, decentralization, censorship resistance, pseudo-anonymity, open source, open collaboration, permissionless, legal neutrality, homogeneity, forward compatibility, minimal resource usage, validation > computation, convergence, transaction immutability, resistance to DoS attacks, avoidance of contention, robustness, incentive consistency, 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 instantiation result of the characteristics of Bitcoin community consensus mentioned above. The design space of Bitcoin's programmability is also defined by the characteristics of Bitcoin community consensus.

Classic Design Space of Bitcoin Programmability

While other public chains are exploring the design space of blockchain with modularization, parallelization, and other solutions that are impossible to achieve, the design space of the Bitcoin protocol has always focused on scripts, OP Code, and UTXO.

Two typical examples 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 3M blocks outside the 1M main block to specifically store signatures (witnesses), and when calculating miner fees, the weight of the signature data was set to 1/4 of the main block data to maintain consistency in the cost of spending a UTXO output and creating a UTXO output, preventing the abuse of UTXO change and the inflation rate of the UTXO set.

The Taproot soft fork in November 2021, on the other hand, saved UTXO verification time and the block space occupied by multi-signatures by introducing the Schnorr multi-signature scheme.

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

UTXO (Unspent Transaction Output) is the basic data structure of the Bitcoin mainnet, with atomicity, non-fungibility, and chain coupling characteristics. Every transaction on the Bitcoin mainnet consumes 1 UTXO as input and creates n new UTXO outputs. In simple terms, UTXO can be seen as paper currency such as dollars and euros running on the chain, which can be spent, changed, split, combined, etc., with the smallest atomic unit being satoshis (sats). 1 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 rate of state expansion on the Bitcoin mainnet has been successfully stabilized at a level consistent with Moore's Law of hardware, thereby ensuring the participation of full nodes on the Bitcoin mainnet and the robustness of transaction verification.

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

The implementation path of Bitcoin's programmability does not adopt an on-chain virtual machine (VM) scheme like Ethereum or Solana, but chooses to use scripts and opcodes (OP Code) to program UTXOs, transaction input fields, output fields, and witness data on the chain.

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

In the classic design space, Bitcoin's programmability is very limited, supporting only a few verification programs, and does not support on-chain state storage and on-chain computation, which are the core functional components for achieving Turing-complete programmability.

Renaissance of Bitcoin Programmability

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

Unlike 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, despite the limitations of various consensus vectors restricting the design space, and at times have even sparked fork wars in the crypto community (such as the SegWit hard fork).

Bitcoin Mainnet Script Evolution

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

Historical output types of the Bitcoin mainnet Source: Dune

From the trend chart of historical output types on 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 primitive scripts, and witness scripts consuming the share of enhanced scripts. The Ordinals protocol, based on the SegWit enhanced scripts and Taproot witness scripts, has initiated a wave of Bitcoin L1 asset issuance, which is both a continuation of the historical trend of Bitcoin mainnet programmability and a new phase of Bitcoin mainnet programmability.

Bitcoin mainnet opcodes have also undergone a similar evolutionary process to Bitcoin mainnet scripts.

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

An instance of the Ordinals protocol's inscription

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

The Ordinals protocol serializes the minimum atomic unit of UTXO, satoshis, and then engraves the data content in the Witness field of the UTXO, associating it with a specific satoshi after serialization. The off-chain indexer is responsible for indexing and executing the programmability operations of these data states. This new paradigm of Bitcoin programmability is metaphorically described as "carving on gold."

The new paradigm of the Ordinals protocol has sparked a greater enthusiasm in the crypto community for using the Bitcoin mainnet block space to issue, mint, and trade NFT collections 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, only suitable for asset issuance applications. Support for transactions and DeFi applications requiring state computation and storage is relatively weak.

Three types of TX quantity in the Ordinals protocol (Image source: Dune)

Liquidity is the lifeblood of assets. Due to the inherent nature of the Ordinals-type Bitcoin programmability protocol, the reissuance of inscription assets provides low liquidity, which in turn affects the value generated throughout the entire lifecycle of an inscription asset.

Additionally, the Ordinals and BRC20 protocols are suspected of abusing witness data space, which objectively leads to a state explosion on the Bitcoin mainnet.

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

As a reference, the main sources of gas fees on the Ethereum mainnet are DEX trading gas fees, L2 data availability fees, and stablecoin transfer gas fees. Compared to the Ethereum mainnet, the Bitcoin mainnet has a single type of income, strong periodicity, and high volatility.

The programmability capability of the Bitcoin mainnet is currently unable to meet the supply-side demand for block space. To achieve a stable and sustainable block space income state similar to the Ethereum mainnet, native DEX, stablecoins, and L2 solutions are needed in the Bitcoin ecosystem. The prerequisite for implementing these protocols and applications is for the Bitcoin programmability protocol to provide Turing-complete programming capabilities.

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

CKB Solution for Bitcoin Programmability

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

BitVM uses a set of Bitcoin OP Codes to build non-logical gates and then constructs other basic logic gates through these non-logical gates, ultimately building a native VM for Bitcoin. This principle is somewhat similar to the famous science fiction novel "The Three-Body Problem" by Liu Cixin. The Netflix adaptation of the same name has specific scenes depicting this. The paper for the BitVM solution has been fully open-sourced and is highly anticipated by the crypto community. However, its engineering implementation difficulty is very high, facing challenges such as off-chain data management costs, participant quantity limitations, challenge-response interaction counts, hash function complexity, etc., making it difficult to land in the short term.

The RGB protocol uses client-side validation and one-time sealing technology to achieve Turing-complete programmability. The core design idea is to store the state and logic of smart contracts in the outputs of Bitcoin transactions, with the maintenance of smart contract code and data storage executed off-chain, with the Bitcoin mainnet serving as the commitment layer for the final state.

EVM-compatible Rollup L2 is a fast reuse of mature Rollup L2 stack to build a Bitcoin L2 solution. However, given that the Bitcoin mainnet currently cannot support fraud proofs/validity proofs, Rollup L2 needs to introduce a social trust assumption (multisig).

DriveChain is a sidechain extension solution, with the basic design idea of using Bitcoin as the underlying blockchain, creating sidechains by locking Bitcoin, and thus achieving bidirectional interoperability between Bitcoin and sidechains. The engineering implementation of DriveChain requires protocol-level changes to Bitcoin, namely the deployment of the proposed BIP300 and BIP301 by the development team.

The above Bitcoin programmability solutions either have extremely high engineering difficulty and are difficult to land in the short term, introduce too many 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 issuance 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++, based on the RGB design concept, is a Bitcoin L1 asset issuance protocol. The engineering implementation of RGB++ inherits both CKB and RGB's technical primitives. It uses RGB's "one-time sealing" and client-side validation technology, and through isomorphic binding, it maps Bitcoin UTXOs to Cells (an extended version of UTXOs) on the CKB mainnet. It uses CKB and Bitcoin's on-chain script constraints to verify the correctness of state computation and the validity of ownership changes.

In other words, RGB++ uses Cells on the CKB chain to express ownership relationships of RGB assets. 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 act as a public database for RGB assets and an off-chain settlement layer, replacing the RGB client and achieving more reliable data hosting and interaction with RGB contracts.

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

A Cell is the basic data storage unit of CKB, capable of containing various data types such as CKBytes, tokens, TypeScript code, or serialized data (such as JSON strings). Each Cell contains a small program called a Lock Script, which defines the owner of the Cell. The Lock Script supports Bitcoin mainnet scripts such as multisig, hash lock, time lock, and also allows for the inclusion of a Type Script to execute specific rules to control its usage. This allows developers to customize smart contracts for 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 an output of a UTXO using the OP_RETURN opcode, making that UTXO 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 type and data of the Cell, with the UTXO container serving as the owner of the Cell's state.

RGB++ transaction lifecycle (Image source: RGB++ Protocol Light Paper)

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

Off-chain computation: When initiating a binding Tx, a new Bitcoin mainnet UTXO btcutxo#2 is first selected as a one-time sealing container, and then a hash calculation is performed off-chain on the original Cell's isomorphic bound UTXO btcutxo#1, the new Cell's isomorphic bound btc_utxo#2, and a CKB TX with the original Cell as input and the new Cell as output to generate a commitment.
Submission of Bitcoin transaction: RGB++ initiates a Bitcoin mainnet Tx, using the isomorphic bound btcutxo#1 as input and using OPRETURN to output the commitment generated in the previous step.
Submission of CKB transaction: The off-chain computed CKB Tx is executed on the CKB mainnet.
On-chain verification: The CKB mainnet runs a Bitcoin mainnet light client to verify the entire system's state changes. This is very different from RGB, where state change verification uses a P2P mechanism and requires interactive verification of the relevant TX graph by the initiator and recipient.

Based on the isomorphic binding logic, RGB++ has gained some new features compared to the RGB protocol while relinquishing some 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 use PoW to maintain consensus security and CKB to verify state computation and URXO-Cell ownership changes.
Transaction folding: RGB++ supports mapping multiple Cells to a single UTXO, enabling flexible scaling of 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 use CKB's global state Cell and intent Cell to solve this problem.
Non-interactive transfers: RGB++ makes the client validation process optional, no longer requiring interactive transfers. If users choose to verify state computation and ownership changes using CKB, the transaction experience is consistent with the Bitcoin mainnet.

Additionally, RGB++ inherits the feature of privatizing the state space of CKB mainnet Cells. For each TX, in addition to paying the miner fee for using the Bitcoin mainnet block space, RGB++ also needs to pay an additional fee for renting the Cell state space (this fee is returned after the Cell is consumed). The privatization of Cell state space is a defense mechanism invented by CKB to counteract the state explosion on the blockchain mainnet. Renters of Cell state space need to continuously pay during usage (diluting value in the form of circulating tokens due to CKB inflation). This makes the RGB++ protocol a responsible extension protocol for the Bitcoin mainnet programmability, to some extent limiting the abuse of the Bitcoin mainnet block space.

Trustless L1>L2 Interoperability: Leap

The isomorphic binding of RGB++ is a synchronous atomic implementation logic, either happening simultaneously or not at all, with no intermediate state. All RGB++ transactions will appear 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 verify the state computation of the RGB++ transaction by checking the relevant transactions on CKB. However, users can also independently verify RGB++ transactions using the local relevant TX graph of UTXOs without relying on transactions on the CKB chain. (Some functions such as transaction folding still rely on CKB block header hashes for double-spending protection)

Therefore, the cross-chain asset transfer between RGB++ and the CKB mainnet does not rely on introducing additional social trust assumptions, such as a relay layer for cross-chain bridges, or a centralized multisig treasury for EVM-compatible Rollup. RGB++ assets can natively and trustlessly transfer 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.

The relationship between RGB++ and CKB is loosely coupled. In addition to supporting assets from the Bitcoin L1 layer (not limited to native assets of the RGB++ protocol, including assets issued by protocols such as Runes, Atomicals, Taproot Asset, etc.) leaping to CKB, the RGB++ protocol also supports leaping to other UTXO-based Turing-complete chains such as Cardano. Additionally, RGB++ supports assets from Bitcoin L2 leaping to the Bitcoin mainnet.

Extension Features and Application Examples of RGB++

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

The xUDT standard is used for fungible tokens, and the Spore standard is used for NFTs.

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

The Spore standard in the NFT category stores all metadata on-chain, ensuring 100% data availability security. Assets issued by the Spore protocol, called 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 script computation capabilities of Bitcoin, introducing assets outside of BTC into the Lightning Network in a trustless manner is very difficult. However, the RGB++ protocol can use CKB's Turing-complete script system to implement state channels and the Lightning Network based on RGB++ assets 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 programmable protocols, but also support complex applications such as asset trading, asset lending, CDP stablecoins, and more. For example, the isomorphic binding logic of RGB++ combined with Bitcoin mainnet's native PSBT script can achieve a DEX in the form of an order book grid.

Bitcoin L2 RaaS Service Provider: UTXO Stack

UTXO Isomorphic Bitcoin L2 Vs EVM-Compatible Bitcoin Rollup L2

In the market competition for Turing-complete Bitcoin programmability solutions, solutions such as DriveChain and the restoration of the OPCAT opcode have a high degree of uncertainty and unpredictability due to the need for changes at the Bitcoin protocol layer. Realistically, UTXO isomorphic Bitcoin L2 and EVM-compatible Bitcoin Rollup L2, represented by CKB, are more recognized by developers and capital. EVM-compatible Bitcoin Rollup L2, represented by MerlinChain and BOB.

In reality, the Bitcoin L1 asset issuance protocol is just beginning to form partial consensus in the Bitcoin community, and the community consensus for Bitcoin L2 is even earlier. However, in this frontier, "Bitcoin Magazine" and Pantera have attempted to define the scope of Bitcoin L2 by drawing inspiration from the concept 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 the settlement mechanism to enforce transactions. Users of Bitcoin L2 must be able to enforce their control over Layer 1 assets (trusted or untrusted).
Demonstrate dependence on Bitcoin's functionality. If the Bitcoin mainnet fails but the Bitcoin L2 system can still operate, then the 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 mechanism, and BTC as the Gas token for Bitcoin L2. In their subconscious, it seems that they are using 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 L2 belongs to a completely off-chain expansion solution that relies entirely on social trust assumptions, despite their whitepapers stating future integration of BitVM for data availability verification and enhanced security through joint mining with the Bitcoin mainnet.

Of course, this does not mean that these EVM-compatible Rollup L2 solutions are not true Bitcoin L2, but rather that they have not achieved a good balance between security, trustlessness, and scalability. Additionally, introducing Ethereum's Turing-complete solutions into the Bitcoin ecosystem is seen by Bitcoin Maximalists as appeasement to the expansionist route.

Therefore, UTXO isomorphic Bitcoin L2 is naturally superior to EVM-compatible Rollup L2 in terms of orthodoxy and community consensus in the Bitcoin community.

Characteristics of UTXO Stack: Fractal Bitcoin Mainnet

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

The UTXO Stack in the CKB ecosystem allows developers to easily launch UTXO Bitcoin L2 and natively integrate the capabilities of the RGB++ protocol. This enables seamless interoperability between the Bitcoin mainnet and UTXO isomorphic Bitcoin L2 developed using UTXO Stack through the Leap mechanism. UTXO Stack supports pledging BTC, CKB, and BTC L1 assets to ensure the security of UTXO isomorphic Bitcoin L2.

UTXO Stack architecture (Image source: Medium)

UTXO Stack currently supports the free circulation and interoperability of RGB++ assets between the Bitcoin Lightning Network, CKB Lightning Network, and parallel L2s of UTXO Stack. In addition, UTXO Stack also supports the free circulation and interoperability of assets based on UTXO Bitcoin L1 programmable protocol such as Runes, Atomicals, Taproot Asset, Stamps, among UTXO Stack parallel L2s, CKB Lightning Network, and the Bitcoin Lightning Network.

UTXO Stack introduces a modular paradigm into the construction of Bitcoin L2, cleverly bypassing the problem of state computation and data availability verification on the Bitcoin mainnet. In this modular stack, Bitcoin plays the role of the consensus layer and settlement layer, CKB plays the role of the data availability layer, and the parallel L2s of UTXO Stack play the role of the execution layer.

Growth Curve of Bitcoin Programmability and the Future of CKB

In fact, there is an inherent tension between the narrative of Bitcoin as digital gold and the narrative of Bitcoin as programmable. Some OGs in the Bitcoin community view the rise of Bitcoin L1 programmable protocols over the past 23 years as a new wave of dust attacks on the Bitcoin mainnet. To some extent, the verbal battle between Bitcoin core developer Luke and BRC20 fans is the third world war between Bitcoin Maximalists and expansionists, following the debates over Turing completeness and block size.

However, there is another perspective that views Bitcoin as an AppChain for digital gold. In this view, it is the underlying decentralized ledger of digital gold that has shaped the UTXO set form and programmable protocol features of the Bitcoin mainnet today. But if I'm not mistaken, Satoshi Nakamoto's vision was to make Bitcoin a peer-to-peer electronic cash system. The need for programmability in digital gold is for safes and vaults, while the need for programmability in currency is for the central bank-commercial bank circulation network. Therefore, the enhancement of Bitcoin's programmability is not a departure from the original vision of Satoshi Nakamoto, but a return to it.

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

By borrowing the research method of the Gartner Hype Cycle, we can divide Bitcoin programmability solutions into 5 stages:

Technology Trigger: DriveChain, UTXO Stack, BitVM, etc.
Peak of Inflated Expectations: Runes, RGB++, EVM Rollup Bitcoin L2, etc.
Trough of Disillusionment: BRC20, Atomicals, etc.
Slope of Enlightenment: RGB, Lightning Network, Bitcoin sidechains, etc.
Plateau of Productivity: Bitcoin script, Taproot script, hash time lock, etc.

The Future of CKB: OP Stack+Eigenlayer for 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 layer 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 show a certain degree of consistency with the Ethereum ecosystem in some aspects. However, this consistency will not simply replicate the technical stack of Ethereum into the Bitcoin ecosystem, but will use the native technology stack of Bitcoin (UTXO-based programmability) to achieve a similar ecosystem structure.

The positioning of CKB's UTXO Stack is very similar to Optimism's OP Stack. 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. At the same time, both UTXO Stack and OP Stack have a parallel structure.

Current state 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 verification sets to further reduce the cost and difficulty for developers to launch UTXO isomorphic Bitcoin L2. Currently, there are a large number of decentralized stablecoin protocols, AMM DEX, lending protocols, and autonomous world projects planning 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 a PoW consensus mechanism consistent with the Bitcoin mainnet, maintained by machine computing power to ensure the consistency of the consensus ledger. However, there are some differences in CKB's token economics compared to Bitcoin. To maintain consistency in block space production and consumption incentives, Bitcoin chooses to introduce a weight and vByte mechanism to calculate state space usage fees, while CKB chooses to privatize state space.

CKB's token economics consist of basic issuance and secondary issuance. All CKB from basic issuance is fully rewarded to miners, and the purpose of secondary issuance of CKB is to collect state rent. The specific allocation ratio of secondary issuance depends on the current usage of circulating CKB in the network.

For example, if 50% of all circulating CKB is used for storing state, 30% is locked in NervosDAO, and 20% is held for liquidity, then 50% of the secondary issuance (i.e., state storage rent) will be allocated to miners, 30% will be allocated to NervosDAO holders, 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 other L1 solutions in the market.

In addition, CKB allows a single Cell to occupy a maximum of 1000 bytes of state space, giving NFT assets on CKB some unique characteristics that other similar assets on other blockchains do not have, such as native gas fees and programmability of state space. These unique characteristics make UTXO Stack very suitable as the infrastructure for building digital physical reality in autonomous world projects.

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

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

Based on historical experience, one of these protocols will eventually develop into a monopolistic standard protocol.

The key factors determining the competitiveness of Bitcoin programmable protocols are: 1. Implementation of free circulation of BTC between L1 and L2 without relying on additional social trust assumptions; 2. Attracting a sufficient scale of developers, funds, and users to enter its L2 ecosystem.

CKB, as a Bitcoin programmable solution, has achieved free circulation of Bitcoin L1 assets between L1 and L2 without relying on additional social trust assumptions, using isomorphic binding and CKB network to replace client-side verification. Additionally, benefiting from the state space privatization feature of CKB Cells, RBG++ has not brought pressure of state explosion to the Bitcoin mainnet, unlike other Bitcoin programmable protocols.

Recently, the initial asset issuance through RGB++ has completed the ecological bootstrapping, bringing approximately 150,000 new users and a group of new developers to the CKB ecosystem. For example, the one-stop solution OpenStamp for the Stamps ecosystem, a Bitcoin L1 programmable protocol, has chosen to use UTXO Stack to build UTXO isomorphic Bitcoin L2 serving the Stamps ecosystem.

In the next phase, CKB will focus on ecosystem application development, achieving free circulation of BTC between L1 and L2, and integrating the Lightning Network, striving to become the future programmable layer for Bitcoin.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。