Nervos CKB Research Report

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

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

Introduction#

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

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

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

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

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

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

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

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

The Namespace of Bitcoin Programmability#

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

In the co-evolution process between Bitcoin Maxis and scalability advocates, from the debate over whether the Bitcoin mainnet supports Turing completeness to the dispute between Segregated Witness solutions and large block scalability solutions, Bitcoin is continuously forking. This not only creates new crypto projects and community consensus but also strengthens and consolidates the consensus of the Bitcoin community itself, a process of self-confirmation while othering.

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

Currently, the characteristics of Bitcoin community consensus include: consensus is not command and control, trust minimization, decentralization, censorship resistance, pseudonymity, open source, open collaboration, permissionless, legally neutral, homogeneity, forward compatibility, minimal resource usage, verification > computation, convergence, transaction immutability, resistance to DoS attacks, avoidance of race conditions, robustness, incentive alignment, solidification, consensus that should not be tampered with, conflict principles, collaborative advancement, and so on.[1]

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

Classic Design Space of Bitcoin Programmability#

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

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

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

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

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

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

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

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

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

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

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

The Renaissance of Bitcoin Programmability#

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

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

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

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

Historical output types of the Bitcoin mainnet; Source: Dune

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

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

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

An inscription instance of the Ordinals protocol

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

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

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

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

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

Liquidity is the source of an asset's vitality. Due to the inherent characteristics of Ordinals-type Bitcoin programmability protocols, the reissuance of inscription assets is light on liquidity provision, which in turn affects the value generated throughout the lifecycle of an inscription asset.

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

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

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

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

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

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

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

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

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

The above Bitcoin programmability solutions either face significant engineering challenges that make short-term implementation difficult, introduce excessive social trust assumptions, or require protocol-level changes to Bitcoin.

Bitcoin L1 Asset Protocol: RGB++#

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

The native primitive of UXTO: Isomorphic Binding

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

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

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

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

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

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

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

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

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

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

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

Trustless L1<>L2 Interoperability: Leap

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

Therefore, the asset cross-chain between RGB++ and the CKB mainnet does not rely on introducing additional social trust assumptions, such as relay layers for cross-chain bridges, centralized multi-signature vaults for EVM-compatible Rollups, etc. 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 like Runes, Atomicals, Taproot Assets, etc.) to Leap to CKB, the RGB++ protocol also supports Leap to other UTXO Turing-complete chains like Cardano. At the same time, RGB++ also supports Bitcoin L2 assets to Leap to the Bitcoin mainnet.

Expansion Features and Application Examples of RGB++

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

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

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

The Spore standard for NFTs stores all metadata on-chain, achieving 100% data availability security. Assets issued by the Spore protocol, known as DOB (Digital Object), are similar to Ordinals NFTs but come with richer features and gameplay.

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

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

Bitcoin L2 RaaS Service Provider: UTXO Stack#

UTXO Isomorphic Bitcoin L2 vs EVM-Compatible Bitcoin Rollup L2

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

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

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

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

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

However, the weak state computation and verification capabilities of the Bitcoin mainnet cannot achieve characteristics 1 and 2 in the short term. In this case, EVM-compatible L2 belongs to a completely off-chain expansion solution that relies on social trust assumptions, even though they claim in their white papers that they will integrate BitVM in the future for data availability verification and enhance security through joint mining with the Bitcoin mainnet.

Of course, this does not mean that these EVM-compatible Rollup L2s are not genuine Bitcoin L2s; rather, they have not achieved a good balance between security, trustlessness, and scalability. Moreover, the introduction of Ethereum's Turing-complete solutions into the Bitcoin ecosystem is easily perceived by Bitcoin Maxis as appeasement towards scalability advocates.

Therefore, UTXO isomorphic Bitcoin L2 naturally holds an advantage in orthodoxy and consensus within the Bitcoin community over EVM-compatible Rollup L2.

Characteristics of UTXO Stack: Fractal Bitcoin Mainnet

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

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

UTXO Stack architecture (Image source: Medium)

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

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

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

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

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

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

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

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

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

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

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

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

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 validation sets, further reducing the cost and difficulty for developers to launch UTXO isomorphic Bitcoin L2. Currently, a large number of decentralized stablecoin protocols, AMM DEXs, lending protocols, and autonomous world projects plan to use UTXO Stack to build UTXO isomorphic Bitcoin L2 as their underlying consensus infrastructure.

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

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

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

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

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

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

Conclusion#

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

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

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

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

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

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

Links mentioned in the article:

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

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

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

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