CKB: A new chapter in Bitcoin programmability

Author: NingNing Source: mirror

Foreword

During the fourth 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 the Bitcoin L1 layer to the consensus security and ecological development of the Bitcoin main network. It can be said to be 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 teleology for BTC Holders, for block space builders, etc.

At present, enhancing Bitcoin's programmability and thus increasing the utilization rate of Bitcoin's main network block space has become a new design space for Bitcoin community consensus.

Unlike Ethereum and other high-performance public chains, in order to ensure the simplicity and lightness of the UTXO set, the design space of Bitcoin programmability is highly limited, and the basic constraint is how to use scripts and OP Codes to operate UTXO.

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

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

Compared with the EVM-compatible Bitcoin L2 solution, CKB (Common Knowledge Base)'s Bitcoin programmability solution is a native, secure, and non-social trust-assumption solution in the modern design space of Bitcoin programmability. Compared with the DriveChain solution, it does not require any changes at the Bitcoin protocol level.

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

Bitcoin Programmable Namespace

Blockchain is a machine that creates trust, and the Bitcoin mainnet is the No. 0 machine. 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 outgrowth of Bitcoin.

In the process of co-evolution between Bitcoin Maxi and expansionists, Bitcoin is constantly forking, from the dispute over whether the Bitcoin mainnet supports Turing completeness to the dispute over the segregated witness solution and the large block expansion solution. This is not only creating new crypto projects and crypto community consensus, but also strengthening and consolidating Bitcoin's own community consensus. This is a process of completing self-affirmation while othering.

Due to the mysterious disappearance of Satoshi Nakamoto, Bitcoin community governance does not have a governance structure like Ethereum's "enlightened monarchy", but a governance model in which miners, developers, communities and markets engage in open games to achieve equilibrium. This gives Bitcoin's community consensus an extremely stable characteristic once it is formed.

The current characteristics of Bitcoin community consensus include: consensus is not command and control, trust minimization, decentralization, censorship resistance, pseudo-anonymity, open source, open collaboration, permissionless, legal neutrality, homogeneity, forward compatibility, resource minimization, verification > calculation, convergence, transaction immutability, resistance to DoS attacks, avoidance of competition for entry, robustness, incentive consistency, solidification, consensus that should not be tampered with, conflict principle, and coordinated advancement. [1]

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

The classic design space of Bitcoin programmability

While other public chains are trying modularization, parallelization, and other solutions to explore the design space of blockchain impossible triangle solutions, the design space of the Bitcoin protocol has always focused on scripts, OP Codes, 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 a 3M block outside the 1M main block to specifically store signatures (witnesses), and set the weight of the signature data to 1/4 of the main block data when calculating the miner fee to maintain the consistency of the cost of spending a UTXO output and creating a UTXO output, to prevent the abuse of UTXO change to increase the expansion rate of the UTXO set.

The Taproot soft fork in November 2021 saves UTXO verification time and block space occupied by multiple signatures by introducing the Schnorr multi-signature scheme.

Key-value group of 1 UTXO (Source: learnmeabitcoin.com)

UTXO (unspent transaction output) is the basic data structure of the Bitcoin mainnet. It has the characteristics of atomicity, non-homogeneity, and chain coupling. Every transaction on the Bitcoin mainnet consumes 1 UTXO as input and creates an integer n new UTXO output. In layman's terms, UTXO can be regarded as paper money such as US dollars and euros running on the chain. It can be spent, changed, split, combined, etc., but its smallest atomic unit is 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 keeping the Bitcoin UTXO set simple, lightweight and easy to verify, the state expansion rate of the Bitcoin main network has been successfully stabilized at a level that is compatible with Moore's Law of hardware, thereby ensuring the participation of all nodes in the Bitcoin main network and the robustness of transaction verification.

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

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

The main toolbox of Bitcoin programmability includes: multi-signature, time lock, hash lock, and process control (OP_IF, OP_ELIF). [2]

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

The Renaissance of Bitcoin Programmability

However, the design space of Bitcoin programmability is not a fixed state. Instead, it is closer to a dynamic spectrum that changes over time.

Different from the stereotype that the development of Bitcoin mainnet is stagnant, under the condition that various consensus vectors limit the design space, the development, deployment, adoption and promotion of new scripts and new opcodes of Bitcoin mainnet are always in progress, and even triggered fork wars in the crypto community at some time (such as Segwit hard fork).

Taking the change of Bitcoin mainnet script type adoption as an example, we can clearly perceive the changes. The scripts used by the output type of Bitcoin mainnet can be divided into three categories: original script pubkey, pubkeyhash, enhanced script multisig, scripthash, witness script witness_v0_keyhash, witness_v0_scripthash, witness_v1_taproot.

Bitcoin Mainnet Full History Output Type Source: Dune

From the trend chart of the change of the full history output type of the Bitcoin Mainnet, we observe a basic fact: the enhancement of the programmability of the Bitcoin Mainnet is a long-term historical trend. The enhanced script is devouring the share of the original script, and the witness script is devouring the share of the enhanced script. The wave of Bitcoin L1 asset issuance opened by the Ordinals protocol based on the Segweit enhanced script and the Taproot witness script is not only a continuation of the historical trend of Bitcoin Mainnet programmability, but also a new stage of Bitcoin Mainnet programmability.

The Bitcoin Mainnet opcode also has a similar evolution process to the Bitcoin Mainnet script.

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

One-time engraving example of the Ordinals protocol

Before the official birth of the Ordinals protocol, the classic solutions for Bitcoin programmability mainly include state channels (Lightning Network), client verification (RGB), side chains (Liquid Network, Stacks, RootSock, etc.), CounterParty, Omni Layer, DLC, etc.

The Ordinals protocol serializes Satoshi, the smallest atomic unit of UTXO, and then inscribes the data content in the Witness field of UTXO, and associates it with a specific Satoshi after serialization. Then the off-chain indexer is responsible for indexing and executing programmable operations on these data states. This new Bitcoin programmability paradigm is figuratively likened to "carving on gold".

The new paradigm of the Ordinals protocol has inspired a wider range of crypto communities to issue, mint and trade NFT collections and MeMe type tokens (collectively referred to as inscriptions) using the Bitcoin mainnet block space, many of whom have their own Bitcoin addresses for the first time in their lives.

However, the programmability of the Ordinals protocol inherits the limited programmability of Bitcoin and only supports three functional methods: Deploy, Mint and Transfer. This makes the Ordinals protocol and its followers, such as BRC20, Runes, Atomicals, Stamps, etc., only suitable for asset issuance application scenarios. However, the support for DeFi application scenarios such as transactions and lending that require state calculation and state storage is relatively weak.

The number of TXs of three types of Ordinals protocol (Source: Dune)

Liquidity is the source of vitality of assets. Due to the natural characteristics of the Ordinals type Bitcoin programmability protocol, the inscription assets are heavily issued and the liquidity is light, which in turn affects the value generated by an inscription asset throughout its life cycle.

In addition, the Ordinals and BRC20 protocols are suspected of abusing the witness data space, and objectively cause the state explosion of the Bitcoin main network.

Changes in Bitcoin Block Space Size (Source: Dune)

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

The programmability capabilities of the Bitcoin mainnet cannot yet meet the needs of the Bitcoin mainnet block space supply side. To achieve a stable and sustainable block space income state for the Ethereum mainnet, DEX, stablecoins, and L2 native to the Bitcoin ecosystem are required. The prerequisite for realizing these protocols and applications is that the Bitcoin programmable protocol needs to provide Turing-complete programming capabilities.

Therefore, how to natively realize Bitcoin's Turing-complete programmability while limiting the negative impact on the state scale of the Bitcoin main network has become a current hot topic in the Bitcoin ecosystem.

The CKB solution for Bitcoin programmability

The current solutions for realizing Bitcoin's native Turing-complete programmability include: BitVM, RGB, CKB, EVM compatible Rollup L2, DriveChain, etc.

BitVM uses a set of Bitcoin's OP Codes to build NAND logic gates, and then uses NAND logic gates to build other basic logic gates, and finally builds a Bitcoin native VM from these basic logic gate circuits. This principle is somewhat similar to the Qin Wang array diagram in the famous science fiction novel "The Three-Body Problem". There are specific scenes in the TV series of the same name adapted by Netflix. The paper on the BitVM solution has been completely open source and is highly anticipated by the crypto community. However, its engineering implementation is very difficult. It is difficult to implement in the short term due to problems such as off-chain data management costs, limited number of participants, number of challenge-response interactions, and complexity of hash functions.

The RGB protocol uses client verification and one-time sealing technology to achieve Turing-complete programmability. The core design idea is to store the state and logic of smart contracts on the output of Bitcoin transactions, and to execute the maintenance and data storage of smart contract codes off-chain, with the Bitcoin mainnet as the commitment layer for the final state.

EVM is compatible with Rollup L2, which is a solution for quickly reusing the mature Rollup L2 stack to build Bitcoin L2. However, given that the Bitcoin mainnet currently cannot support fraud proof/validity proof, Rollup L2 needs to introduce social trust assumptions (multi-signature).

DriveChain is a sidechain expansion solution. The basic design idea is to use Bitcoin as the bottom layer of the blockchain and create sidechains by locking Bitcoin, thereby achieving two-way interoperability between Bitcoin and sidechains. The implementation of the DriveChain project requires protocol-level changes to Bitcoin, that is, deploying the BIP300 and BIP301 proposed by the development team to the main network.

The above Bitcoin programmability solutions are either extremely difficult to implement in the short term, or introduce too many social trust assumptions, or require protocol-level changes to Bitcoin.

Bitcoin L1 Asset Protocol: RGB++

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

UXTO native primitives: isomorphic binding

RGB++ is a Bitcoin L1 asset issuance protocol developed based on the RGB design concept. The engineering implementation of RGB++ inherits the technical primitives of CKB and RBG at the same time. It uses RGB's "one-time seal" and client verification technology, and maps Bitcoin UTXO to the Cell (extended version of UTXO) of the CKB mainnet through isomorphic binding, and uses script constraints on CKB and Bitcoin chains to verify the correctness of state calculations and the validity of ownership changes.

In other words, RGB++ uses Cell on the CKB chain to express the ownership relationship of RGB assets. It moves the asset data originally stored locally on the RGB client to the CKB chain and expresses it in the form of Cell, establishes a mapping relationship with Bitcoin UTXO, and allows CKB to act as a public database and off-chain pre-settlement layer for RGB assets, replacing the RGB client to achieve more reliable data custody and RGB contract interaction.

RGB++'s isomorphic binding (Source: RGB++ Protocol Light Paper)

Cell is the basic data storage unit of CKB, which can contain various data types such as CKBytes, tokens, TypeScript code, or serialized data (such as JSON strings). Each Cell contains a small program called Lock Script, which defines the owner of the Cell. Lock Script supports scripts for the Bitcoin mainnet, such as multi-signatures, hash locks, time locks, etc., and also allows the inclusion of a Type Script to enforce specific rules to control its use. This enables developers to customize smart contracts for different use cases, such as issuing NFTs, airdropping tokens, AMM Swaps, and more.

The RGB protocol uses the OP RETURN opcode to attach the state root of off-chain transactions to the output of a UTXO, using the UTXO as a container for state information. Then, RGB++ maps this state information container built by RGB to the Cell of CKB, saves the state information in the type and data of the Cell, and uses this container UTXO as the Cell state owner.

RGB++ Transaction Lifecycle (Source: RGB++ Protocol Light Paper)

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

1. Off-chain calculations When initiating an isomorphic binding Tx, first select a new UTXO btc_utxo#2 of the Bitcoin mainnet as a one-time sealed container, and then perform hash calculations on the original Cell isomorphically bound UTXO btc_utxo#1, the new Cell isomorphically bound btc_utxo#2, and the CKB TX with the original Cell as input and the new Cel as output to generate a commitment.

2. Submit Bitcoin transaction. RGB++ initiates a Bitcoin mainnet Tx, takes btc_utxo#1 isomorphically bound to the original Cell as input, and uses OP RETURN to take the commitment generated in the previous step as output.

3. Submit CKB transaction. CKB Tx generated by off-chain calculation before CKB mainnet execution.

4. On-chain verification. The CKB mainnet runs a Bitcoin mainnet light client to verify the state changes of the entire system. This is very different from RGB. RGB's state change verification adopts a P2P mechanism, which requires the initiator and receiver of Tx to be online at the same time and only interactively verify the relevant TX graph.

RGB++, which is implemented based on the above isomorphic binding logic, has gained some new features while giving up some privacy compared to the RGB protocol: blockchain-enhanced client verification, transaction folding, shared state of masterless contracts, and non-interactive transfers.

• Blockchain-enhanced client verification. RGB++ allows users to choose to use PoW to maintain consensus security CKB verification state calculation and URXO-Cell ownership changes.

• Transaction folding. RGB++ supports mapping multiple Cells to a single UTXO, thereby realizing the elastic expansion of RGB++.

• Masterless smart contracts and shared states. One of the major difficulties in implementing Turing-complete smart contracts with the UTXO state data structure is the ownerless smart contract and shared state. RGB++ can use CKB's global state Cell and intent Cell to solve this problem.

• Non-interactive transfer. RGB++ makes RGB's client verification process optional and no longer requires interactive transfers. If users choose CKB to verify state calculations and ownership changes, the transaction interaction experience is consistent with the Bitcoin mainnet.

In addition, RGB++ also inherits the state space privatization feature of the CKB mainnet Cell. In addition to paying the miner fee for using the Bitcoin mainnet block space, RGB++ also needs to pay an additional fee for leasing the Cell state space for each TX (this part of the fee is returned by the original route after the Cell is consumed). The state space privatization of Cell is a defense mechanism invented by CKB to deal with the state explosion of the blockchain mainnet. The lessee of the Cell state space needs to pay continuously during use (in the form of CKB circulating token inflation to dilute the value). This makes the RGB++ protocol a responsible Bitcoin mainnet programmability extension protocol, which can limit the abuse of Bitcoin mainnet block space to a certain extent.

Trustless L1<>L2 interoperability: Leap

RGB++'s isomorphic binding is a synchronous atomic implementation logic that either occurs at the same time or flips at the same time, with no intermediate state. All RGB++ transactions will appear in a transaction on the BTC and CKB chains simultaneously. The former is compatible with the transactions of the RGB protocol, while the latter replaces the client verification process. Users only need to check the relevant transactions on CKB to verify whether the state calculation of this RGB++ transaction is correct. However, users can also use the local relevant Tx graph of UTXO instead of using the transactions on the CKB chain as the basis for verification to independently verify the RGB++ transactions. (Some functions such as transaction folding still need to rely on CKB's block header hash for double-spending verification)

Therefore, the cross-chain asset transfer between RGB++ and CKB mainnet does not rely on the introduction of additional social trust assumptions, such as the relay layer of the cross-chain bridge, the centralized multi-signature vault compatible with EVM Rollup, etc. RGB++ assets can be transferred from the Bitcoin mainnet to the CKB mainnet natively and trustlessly, or from the CKB mainnet to the Bitcoin mainnet. CKB calls this cross-chain workflow Leap.

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

RGB++'s extended functions and application examples

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

RGB++'s homogeneous token standard is xUDT, and the NFT standard is Spore, etc.

The xUDT standard supports a variety of homogeneous token issuance methods, including but not limited to centralized distribution, airdrops, subscriptions, etc. The total amount of tokens can also be selected between no upper limit and a preset upper limit. For tokens with a preset upper limit, a state sharing scheme can be used to verify whether the total amount issued each time is less than or equal to the preset upper limit.

Spore in the NFT standard stores all metadata on the chain, achieving 100% data availability security. The asset DOB (Digital Object) issued by the Spore protocol is similar to Ordinals NFT, but has richer features and gameplay.

As a client verification protocol, the RGB protocol naturally supports state channels and lightning networks, but it is very difficult to introduce trustless assets other than BTC into the lightning network due to the limitations of Bitcoin's script computing power. However, the RGB++ protocol can use CKB's Turing-complete script system to implement state channels and lightning networks for RGB++ assets based on CKB.

With the above standards and functions, the use cases of the RGB++ protocol are not limited to simple asset issuance scenarios like other Bitcoin mainnet programmable protocols, but support complex application scenarios such as asset trading, asset lending, and CDP stablecoins. For example, the RGB++ isomorphic binding logic combined with the native PSBT script of the Bitcoin mainnet can realize 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 of Turing-complete Bitcoin programmability implementation solutions, DriveChain, recovery of OPCAT opcodes and other solutions require changes to the Bitcoin protocol layer, and the time and cost required are very uncertain and unpredictable. UTXO Isomorphic Bitcoin L2 and EVM Compatible Bitcoin Rollup L2 in the realistic route are more recognized by developers and capital. UTXO Isomorphic Bitcoin L2 is represented by CKB. EVM Compatible Bitcoin Rollup L2 is represented by MerlinChain and BOB.

To be honest, the Bitcoin L1 asset issuance protocol has just begun to form a local consensus in the Bitcoin community, and the community consensus of Bitcoin L2 is at an earlier stage. But in this frontier, Bitcoin Magazine and Pantera have tried to define the scope of Bitcoin L2 by borrowing the conceptual structure of Ethereum L2.

In their eyes, Bitcoin L2 should have the following three features:

• 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 force the return of their control of assets in a layer (trusted or untrusted).

• Demonstrate functional dependence on Bitcoin. If the Bitcoin mainnet fails but the Bitcoin L2 system can still operate, then the system is not Bitcoin L2. [4]

In other words, the Bitcoin L2 they believe should have data availability verification based on the Bitcoin mainnet, an escape hatch mechanism, and BTC as the Bitcoin L2 Gas token. It seems that in their subconscious, the EVM compatible L2 paradigm is used as the standard template for Bitcoin L2.

However, the weak state calculation and verification capabilities of the Bitcoin mainnet cannot achieve characteristics 1 and 2 in the short term. In this case, EVM compatible L2 is an off-chain expansion solution that relies entirely on the social trust assumption, although they write in the white paper that they will integrate BitVM for data availability verification and joint mining with the Bitcoin mainnet to enhance security.

Of course, this does not mean that these EVM compatible Rollup L2 are fake Bitcoin L2, but that they do not strike a good balance between security, trustlessness and scalability. Moreover, the introduction of Ethereum's Turing complete solution into the Bitcoin ecosystem is easily regarded by Bitcoin Maxi as an appeasement of the expansionist route.

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

Features of UTXO Stack: Fractal Bitcoin Mainnet

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

UTXO Stack of CKB Ecosystem enables developers to start UTXO Bitcoin L2 with one click, and natively integrates RGB++ protocol capabilities. This enables seamless interoperability between Bitcoin Mainnet and UTXO Isomorphic Bitcoin L2 developed using UTXO Stack through the Leap mechanism. UTXO Stack supports staking of BTC, CKB and BTC L1 assets to ensure the security of UTXO Isomorphic Bitcoin L2.

UTXO Stack architecture (Source: Medium)

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

UTXO Stack introduces the modular paradigm into the construction of Bitcoin L2, and cleverly bypasses the problems of Bitcoin mainnet state calculation and data availability verification with isomorphic binding. In this modular stack, Bitcoin plays the role of consensus layer and settlement layer, CKB plays the role of data availability layer, and UTXO Stack parallel L2 plays the role of execution layer.

The growth curve of Bitcoin programmability and the future of CKB

The growth curve of Bitcoin programmability and the future of CKB

In fact, there is an inherent tension between Bitcoin's digital gold narrative and Bitcoin's programmable narrative. Some OGs in the Bitcoin community regard the Bitcoin L1 programmable protocol that has emerged in the past 23 years as a new wave of dust attacks on the Bitcoin mainnet. To some extent, the war of words between Bitcoin core developer Luke and BRC20 fans is the third world war between Bitcoin maxi and expansionists after the dispute over whether to support Turing completeness and the dispute over large and small blocks.

But there is actually another perspective, which regards Bitcoin as the APP Chain of digital gold. From this perspective, it is the positioning of the underlying decentralized ledger of digital gold that shapes the current UTXO set form and programmable protocol characteristics of the Bitcoin mainnet. But if I remember correctly, Satoshi Nakamoto's vision is to make Bitcoin a P2P electronic currency. Digital gold's demand for programmability is safes and vaults, and currency's demand for programmability is the circulation network of central banks and commercial banks. Therefore, Bitcoin's programmability enhancement protocol is not a heresy, but a return to Satoshi Nakamoto's vision.

Bitcoin is the first AppChain (Source: @tokenterminal)

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

• Technology embryonic stage: DriveChain, UTXO Stack, BitVM, etc.

• Expectation expansion period: Runes, RGB++, EVM Rollup Bitcoin L2, etc.

• Bubble burst period: BRC20, Atomicals, etc.

• Mature plateau period: Bitcoin script, Taproot script, hash time lock, etc.

The future of CKB: OP Stack+Eigenlayer of Bitcoin ecology

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

Just as convergent evolution happens repeatedly in nature, it can be expected that the development trend of Turing-complete programmability in the Bitcoin ecology will show a certain degree of consistency with the Ethereum ecology in some aspects. However, this consistency will not be a simple replication of Ethereum's technology stack to the Bitcoin ecology, but a similar ecological structure achieved by using Bitcoin's native technology stack (UTXO-based programmability).

CKB's UTXO Stack is very similar to Optimism's OP Stack in that 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, UTXO Stack is a parallel structure like OP Stack.

CKB Ecosystem Status (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 of developers launching UTXO isomorphic Bitcoin L2. At present, there are a large number of decentralized stablecoin protocols, AMM DEX, lending protocols, autonomous world and other projects that 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, and the consistency of the consensus ledger is maintained by machine computing power. However, CKB's token economics is somewhat different from Bitcoin. In order to maintain the consistency of incentives for block space production and consumption behaviors, Bitcoin chooses to introduce weights and vByte mechanisms to calculate state space usage fees, while CKB chooses to privatize the state space.

CKB's token economics consists of two parts: basic issuance and secondary issuance. All CKB issued in the basic issuance are fully rewarded to miners, and the purpose of secondary issuance of CKB is to collect state rent. The specific distribution ratio of secondary issuance depends on how the currently circulating CKB is used in the network.

For example, suppose that of all the circulating CKB, 50% is used to store state, 30% is locked in NervosDAO, and 20% is fully maintained liquidity. Then, 50% of the secondary issuance (i.e., the rent for storing state) will be allocated to miners, 30% will be allocated to NervosDAO depositors, and the remaining 20% ​​will be allocated to the treasury fund.

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

In addition, CKB allows a single Cell to occupy a maximum of 1000 bytes of state space, which gives NFT assets on CKB some unique features that other blockchain assets do not have, such as natively carrying gas fees, programmability of state space, and so on. These unique features make UTXO Stack very suitable as the infrastructure for autonomous world projects to build digital physical reality.

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

Summary

It is inevitable that Bitcoin will develop to the stage of Turing-complete programmable solutions. 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).

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

There are two key factors that determine the competitiveness of Bitcoin programmability protocols: 1. Realize the free flow of BTC between L1<>L2 without relying on additional social trust assumptions; 2. Attract developers, funds and users of sufficient scale to enter its L2 ecosystem.

As a Bitcoin programmability solution, CKB uses isomorphic binding + CKB network to replace client verification solutions, realizing the free flow of Bitcoin L1 assets between L1<>L2 without relying on additional social trust assumptions. And benefiting from the private nature of the state space in CKB Cell, RBG++ does not bring the pressure of state explosion to the Bitcoin mainnet like other Bitcoin programmability protocols.

Recently, the hot start of the ecosystem was initially completed through the issuance of the first batch of assets by RGB++, successfully onboarding ~150,000 new users and a group of new developers for the CKB ecosystem. For example, OpenStamp, a one-stop solution for the Bitcoin L1 programmable protocol Stamps ecosystem, has chosen to use UTXO Stack to build a UTXO isomorphic Bitcoin L2 that serves the Stamps ecosystem.

In the next stage, CKB will focus on ecological application construction, realizing the free flow of BTC between L1<>L2, integrating the lightning network, and strive to become the programmable layer of Bitcoin in the future.