Preface

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

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

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

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

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 scheme is a native, secure solution in the modern design space of Bitcoin programmability, without introducing any social trust assumptions at the Bitcoin protocol level. 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 of the Bitcoin ecosystem will usher in a wave of Cambrian explosion. The UTXO Stack of CKB's 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.

Bitcoin Programmability Namespace

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 big block scaling solutions, Bitcoin has been continuously forking. This process not only gives birth to new crypto projects and consensus within the crypto community, but also strengthens and consolidates the community consensus of Bitcoin itself, completing a process of self-confirmation while being otherized.

Due to Satoshi Nakamoto's mysterious disappearance, the governance of the Bitcoin community does not have a "enlightened monarch dictatorship" governance structure like Ethereum. Instead, it is an open game of balance among miners, developers, the community, and the market. This endows the Bitcoin community consensus 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 the Bitcoin community consensus. The design space of Bitcoin's programmability is also defined by the characteristics of the Bitcoin community consensus.

Classic Design Space of Bitcoin Programmability

While other public chains are exploring the design space of blockchain's impossible triangle through modularization, parallelization, and other solutions, 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 (witness), 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 abuse of UTXO change and increasing the rate of UTXO set inflation.

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.

Key-value pair of 1 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 simpler 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 ease of verification of the Bitcoin UTXO set, the rate of state inflation on the Bitcoin mainnet has been successfully stabilized at a level consistent with Moore's Law of hardware, 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 the 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) solution like Ethereum or Solana, but instead chooses to use scripts and opcodes (OP Code) to program UTXO, transaction input fields, output fields, and witness data.

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 not supporting on-chain state storage and 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. Instead, 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, even at times leading to fork wars within the crypto community (such as the SegWit hard fork).

Taking the transition 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 categories: primitive scripts (pubkey, pubkeyhash), enhanced scripts (multisig, scripthash), and witness scripts (witnessv0keyhash, witnessv0scripthash, witnessv1taproot).

Bitcoin Mainnet Full History Output Types Source: Dune

From the trend chart of the full history output types of the Bitcoin mainnet, we observe a fundamental 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 wave of Bitcoin L1 asset issuance initiated by the Ordinals protocol, based on the 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.

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

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

One instance of the engraving of the Ordinals protocol

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 within the crypto community to use 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, suitable only for asset issuance scenarios. Support for transactions and lending in DeFi applications that require 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 natural characteristics of the inscriptions' programmability protocol, inscription assets have heavy re-issuance and light liquidity provision, which in turn affects the value generated throughout the entire lifecycle of an inscription asset.

Furthermore, 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, the Bitcoin ecosystem needs native DEX, stablecoins, and L2. 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 logical gates from 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" and is depicted in specific scenes in the Netflix adaptation of the same name. 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 frequency, hash function complexity, and more, 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 solution for quickly reusing 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 a social trust assumption (multisig).

DriveChain is a sidechain extension solution, with the basic design idea being to use Bitcoin as the underlying blockchain, creating sidechains by locking Bitcoin, thereby achieving bidirectional interoperability between Bitcoin and sidechains. The engineering implementation of DriveChain requires protocol-level changes to Bitcoin, namely deploying the proposed BIP300 and BIP301 to the mainnet 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 the technical primitives of CKB and RGB. 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 UTXO) on the CKB mainnet. It uses CKB and Bitcoin's on-chain scripts 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 in the RGB client locally to the CKB chain in the form of Cells, establishes a mapping relationship with Bitcoin UTXO, and allows CKB to act as a public database for RGB assets and an off-chain pre-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 (e.g., 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 off-chain transaction's state root 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, saving the state information in the Cell's type and data, 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 image, a complete RGB++ transaction lifecycle is as follows:

1. Off-chain computation: When initiating a binding Tx, a new Bitcoin UTXO btcutxo#2 is first selected as a one-time sealing container, and then a commitment is generated through off-chain hashing of the original Cell's isomorphic binding UTXO btcutxo#1, the new Cell's isomorphic binding btc_utxo#2, and a CKB TX with the original Cell as input and the new Cell as output.
2. Submit Bitcoin transaction: RGB++ initiates a Bitcoin mainnet Tx, using the OPRETURN to output the commitment generated in the previous step, with the original Cell's isomorphic binding btcutxo#1 as input.
3. Submit CKB transaction: Execute the off-chain computed CKB Tx on the CKB mainnet.
4. 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 maintain consensus security through PoW on CKB to validate state computation and UTXO-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 address this issue.
• Non-interactive transfers: RGB++ makes the client validation process optional, no longer requiring interactive transfers. If users choose to validate state computation and ownership changes on 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 (in the form of dilution of value by circulating tokens issued by CKB). This makes the RGB++ protocol a responsible extension protocol for Bitcoin mainnet programmability, to some extent limiting the abuse of Bitcoin mainnet block space.

Trustless L1>L2 Interoperability: Leap

The isomorphic binding of RGB++ is a synchronous atomic implementation logic, either happening simultaneously or being reversed simultaneously, without storing intermediate states. 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 UTXO, without relying on transactions on the CKB chain for verification (some functions such as transaction folding still rely on the block header hash of CKB for double-spending prevention).

Therefore, the cross-chain assets between RGB++ and CKB mainnet do not rely on introducing additional social trust assumptions, such as relay layers of cross-chain bridges, centralized multisig treasuries for EVM-compatible Rollup, and so on. 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.

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.) to Leap to CKB, the RGB++ protocol also supports Leap to other UTXO Turing-complete chains such as Cardano. Additionally, RGB++ supports assets from Bitcoin L2 to Leap to the Bitcoin mainnet.

Extended 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 token supply can also be chosen between unlimited and preset limits. For tokens with preset limits, 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. However, due to the script computation capabilities of Bitcoin, introducing assets outside of BTC into the Lightning Network in a trustless manner is very difficult. But the RGB++ protocol can use CKB's Turing-complete script system to implement state channels and the Lightning Network based on CKB's RGB++ assets.

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 application scenarios 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, is also favored.

In reality, the Bitcoin L1 asset issuance protocol is just beginning to form partial consensus in the Bitcoin community, while the community consensus for Bitcoin L2 is at an earlier stage. However, in this frontier field, "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) using Bitcoin as the settlement mechanism.
• Demonstrate dependency 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, they consider 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 extension solution that relies on social trust assumptions, despite the white paper's mention of future integration with 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 of the scaling route.

Therefore, UTXO isomorphic Bitcoin L2 naturally has a higher degree of orthodoxy and community consensus than EVM-compatible Rollup L2.

Characteristics of UTXO Stack: Fractal Bitcoin Mainnet

If Ethereum L2 is considered a fractal of Ethereum, then Bitcoin L2 should be 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 protocols such as Runes, Atomicals, Taproot Asset, Stamps, etc., between parallel L2s of UTXO Stack, 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.

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 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 that of 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. Additionally, both UTXO Stack and OP Stack have a parallel structure.

In fact, the inherent tension between Bitcoin's digital gold narrative and its programmable narrative has led some OGs in the Bitcoin community to 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 battles between Bitcoin core developer Luke and BRC20 fans are the third world war between Bitcoin Maximalists and scaling proponents, following the debates over Turing completeness and block size.

However, there is another perspective that sees 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. 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 protocols 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 adopting the research method of the Gartner Hype Cycle, we can categorize Bitcoin programmability solutions into five 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.

Conclusion

In conclusion, whether it is EVM-compatible Bitcoin Rollup L2, UTXO isomorphic Bitcoin L2, or new paradigms like DriveChain, the various implementations of Turing-complete programmability ultimately point to the Bitcoin mainnet as the consensus layer and settlement layer. The development trend of Turing-complete programmability in the Bitcoin ecosystem is expected to show a certain degree of consistency with the Ethereum ecosystem, but it will not simply replicate the technical stack of Ethereum into the Bitcoin ecosystem. Instead, it will use the native technology stack of Bitcoin to achieve a similar ecosystem structure.

CKB's UTXO Stack and Optimism's OP Stack have a similar positioning, with OP Stack maintaining 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. 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 RaaS services such as shared sequencers, shared security, shared liquidity, and shared validation sets to further reduce the cost and difficulty for developers to launch UTXO isomorphic Bitcoin L2. Currently, a large number of decentralized stablecoin protocols, AMM DEX, 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 a PoW consensus mechanism consistent with the Bitcoin mainnet, maintained by machine computing power to ensure the consistency of the consensus ledger. However, CKB's token economics have some differences from Bitcoin. To maintain consistency in incentivizing block space production and consumption behavior, Bitcoin introduces 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 the situation of other L1 protocols 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 blockchain assets 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.

Conclusion

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 programmability 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 programmability solution, has achieved the free circulation of Bitcoin L1 assets between L1 and L2 without relying on additional social trust assumptions, using isomorphic binding + CKB network to replace client verification. Additionally, benefiting from the privatization of state space in CKB Cells, RBG++ has not brought the pressure of state explosion to the Bitcoin mainnet, unlike other Bitcoin programmability protocols.

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

In the next stage, CKB will focus on ecological application construction, achieving free circulation of BTC between L1 and L2, and integrating the Lightning Network, striving to become the future programmability layer of Bitcoin.

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