Preface
During the fourth Bitcoin halving cycle, the explosive adoption of the #Ordinals protocol and similar protocols made the crypto industry realize 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 mainnet. This can be described as the "Uniswap moment" of the Bitcoin ecosystem.
The evolution and iteration of Bitcoin’s programmability is the result of the Bitcoin community’s opinion market governance, rather than being driven by teleology such as for BTC Holders or for block space Builders.
At present, enhancing the programmability of Bitcoin and thereby increasing the utilization rate of the Bitcoin mainnet block space has become a new design space for the 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 restricted, 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. Emerging Bitcoin programmability solutions since 2023 include Ordinals, BRC20, Runes, Atomicals, Stamps, etc.
After the second wave of inscriptions, a new generation of Bitcoin programmability solutions emerged, such as #CKB 's #UTXO #同构绑定 solution, EVM-compatible Bitcoin L2 solution, DriveChain solution, and so on.
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 the new influx of 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.
Namespaces for Bitcoin Programmability
Blockchain is a machine for creating trust, and the Bitcoin mainnet is machine 0. 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 debate on whether the Bitcoin mainnet supports Turing completeness to the debate on 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 self-affirmation while othering.
Due to the mysterious disappearance of Satoshi Nakamoto, Bitcoin community governance does not have the governance structure of "enlightened monarchy" like Ethereum, but a governance model in which miners, developers, communities and markets compete in an open game 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 alignment, solidification, consensus that should not be tampered with, conflict principle, and coordinated advancement. [1]
The current form of the Bitcoin mainnet can be seen as an 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 UTXOs.
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 in addition to the 1M main block to 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 consistency in the cost of spending a UTXO output and creating a UTXO output, preventing the abuse of UTXO change to increase the expansion rate of the UTXO set.
The Taproot soft fork in November 2021 introduced the Schnorr multi-signature scheme to save UTXO verification time and block space occupied by multi-signatures.
1 UTXO key-value pair (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 outputs. 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 mainnet has been successfully stabilized at a level consistent with Moore's Law for hardware, thereby ensuring the participation of all nodes on the Bitcoin mainnet 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's programmability does not adopt the on-chain virtual machine (VM) solution like Ethereum and Solana, but chooses to use scripts and operation codes (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 flow control (OP_IF, OP_ELIF). [2]
In the classic design space, Bitcoin's programmability is very limited, supporting only a few verification procedures, but not on-chain state storage and on-chain computing, which are precisely the core functional components for achieving Turing-complete programmability.
The Renaissance of Bitcoin Programmability
But the design space of Bitcoin programmability is not a fixed state. Instead, it is closer to a dynamic spectrum that changes over time.
Contrary to the outside world's stereotype that the development of the Bitcoin mainnet has stagnated, with various consensus vectors limiting the design space, the development, deployment, adoption, and promotion of new scripts and new opcodes for the Bitcoin mainnet are always in progress, and at some point have even triggered fork wars in the crypto community (such as the Segwit hard fork).
Taking the adoption rate of Bitcoin mainnet script types as an example, we can clearly perceive the changes. The scripts used by the output types of Bitcoin mainnet can be divided into three categories:
Original script: pubkey, pubkeyhash
Enhanced scripts: multisig, scripthash
Witness script: witness_v0_keyhash, witness_v0_scripthash, witness_v1_taproot
Bitcoin mainnet full history output types; Source: Dune
From the trend chart of the changes in the output types of the entire history of the Bitcoin main network, we observe a basic fact: the enhancement of the programmability of the Bitcoin main network is a long-term historical trend. The enhanced script is swallowing up the share of the original script, and the witness script is swallowing up 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 both a continuation of the historical trend of the programmability of the Bitcoin main network and a new stage of the programmability of the Bitcoin main network.
The Bitcoin mainnet opcodes also have an evolution process similar to that of the Bitcoin mainnet scripts.
For example, the Ordinals protocol implements its functional design by combining the Bitcoin mainnet script taproot script-path spend and opcodes (OP_FALSE, OP_IF, OP_PUSH, OP_ENDIF).
1 instance of engraving the Ordinals protocol
Before the Ordinals protocol was officially launched, classic solutions for Bitcoin programmability included 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. The off-chain indexer is then 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 the enthusiasm of the larger crypto community to use the Bitcoin mainnet block space to issue, mint and trade NFT collectibles and MeMe-type tokens (collectively referred to as inscriptions), 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 applicable to asset issuance scenarios. However, the support for DeFi application scenarios such as transactions and lending that require state calculation and state storage is relatively weak.
Ordinals protocol 3 types of TX numbers (Source: Dune)
Liquidity is the source of vitality of assets. Due to the natural characteristics of the Ordinals type Bitcoin programmability protocol, inscription assets are heavily issued but liquidity is lightly provided, which in turn affects the value generated by an inscription asset throughout its life cycle.
Moreover, Ordinals and BRC20 protocols are suspected of abusing witness data space, and objectively causing the Bitcoin mainnet status to explode.
Changes in Bitcoin block space size (Source: Dune)
As a reference, the main sources of Ethereum mainnet gas fees are DEX transaction gas fees, L2 data availability fees, and stablecoin transfer gas fees, etc. Compared with the Ethereum mainnet, the Bitcoin mainnet has a single income type, strong periodicity, and high volatility.
The programmability of the Bitcoin mainnet cannot yet meet the supply side demand of the Bitcoin mainnet block space. To achieve a stable and sustainable block space income state for the Ethereum mainnet, DEX, stablecoins and L2 native to the Bitcoin ecosystem are needed. 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 implement Bitcoin's Turing-complete programmability while limiting the negative impact on the state scale of the Bitcoin mainnet has become a current hot topic in the Bitcoin ecosystem.
CKB Solution for Bitcoin Programmability
The current solutions for achieving Bitcoin's native Turing-complete programmability include: BitVM, RGB, CKB, EVM-compatible Rollup L2, DriveChain, etc.
BitVM uses a set of Bitcoin OP Codes to construct NAND logic gates, and then uses NAND logic gates to construct other basic logic gates. Finally, these basic logic gate circuits construct a Bitcoin native VM. This principle is somewhat similar to the Qin Emperor's array diagram in the famous science fiction novel "The Three-Body Problem". A specific scene is presented 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 encounters problems such as off-chain data management costs, restrictions on the number of participants, the number of challenge-response interactions, and the complexity of hash functions. It is difficult to implement in the short term.
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 the smart contract on the output of the Bitcoin transaction, and to perform the maintenance of the smart contract code and data storage off-chain, with the Bitcoin mainnet as the commitment layer for the final state.
EVM is compatible with Rollup L2, and 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-signatures).
DriveChain is a sidechain expansion solution. The basic design idea is to use Bitcoin as the underlying layer of the blockchain and create a sidechain by locking Bitcoin, thereby achieving two-way interoperability between Bitcoin and the sidechain. The implementation of the DriveChain project requires protocol-level changes to Bitcoin, that is, deploying BIP300 and BIP301 proposed by the development team to the mainnet.
The above Bitcoin programmability solutions are either extremely difficult to implement in the short term due to engineering difficulties, 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 bindings
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. It uses RGB's "one-time seal" and client verification technology, and maps Bitcoin UTXO to the Cell of the CKB mainnet (extended version of UTXO) through isomorphic binding, and uses script constraints on CKB and the Bitcoin chain to verify the correctness of state calculations and the validity of ownership changes.
In other words, RGB++ uses cells on the CKB chain to express the ownership relationship of RGB assets. It moves the asset data originally stored in the local RGB client to the CKB chain and expresses it in the form of cells, establishes a mapping relationship with Bitcoin UTXO, and allows CKB to serve as a public database and off-chain pre-settlement layer for RGB assets, replacing the RGB client and achieving more reliable data custody and RGB contract interaction.
Isomorphic binding of RGB++ (Image 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 both scripts of Bitcoin Mainnet, such as multi-signature, hash lock, time lock, 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 Swap, and so on.
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 CKB Cell, 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 life cycle is as follows:
Off-chain calculation. When initiating an isomorphically bound Tx, first select a new UTXO btc_utx#2on 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.
Submit a Bitcoin transaction. RGB++ initiates a Tx on the Bitcoin mainnet, takes btc_utx#1which is isomorphically bound to the original Cell as input, and uses OP RETURN to take the commitment generated in the previous step as output.
Submit CKB transaction. CKB Tx generated by off-chain calculation before CKB mainnet execution.
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, which uses a P2P mechanism for state change verification, requiring the initiator and receiver of Tx to be online at the same time and only interactively verifying 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 ownerless contracts, and non-interactive transfers.
Blockchain-enhanced client-side verification. RGB++ allows users to choose to adopt PoW to maintain consensus security CKB verification state calculation and ownership changes of URXO-Cell.
Transaction folding. RGB++ supports mapping multiple cells to a single UTXO, thereby achieving flexible expansion of RGB++.
Unowned smart contracts and shared states. One of the major difficulties in implementing Turing-complete smart contracts with the UTXO state data structure is the unowned smart contracts and shared states. RGB++ can solve this problem by using CKB’s global state cells and intent cells.
Non-interactive transfers.RGB++ makes the client verification process of RGB 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 CKB mainnet Cell. In addition to paying the mining fee for using the Bitcoin mainnet block space, each TX of RGB++ also needs to pay the fee for leasing the Cell state space (this part of the fee is returned after the Cell is consumed). The privatization of the Cell state space is a defense mechanism invented by CKB to deal with the state explosion of the blockchain mainnet. The renter of the Cell state space needs to continue to pay during the use period (in the form of inflation of CKB circulating tokens to dilute the value). This makes the RGB++ protocol a responsible Bitcoin mainnet programmability extension protocol, which can limit the abuse of the 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 transactions in 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 map of UTXO instead of using transactions on the CKB chain as the basis for verification to independently verify 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 Bitcoin mainnet to CKB mainnet natively and trustlessly, or from CKB mainnet to 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 Assets, etc.) to CKB, the RGB++ protocol also supports the 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++ extended functions and application examples
The 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 of each issuance is less than or equal to the preset upper limit.
Spore, a NFT standard, stores all metadata on-chain, achieving 100% data availability and 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 assets other than BTC into the lightning network without trust due to the limitation 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, CDP stablecoins, etc. 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, OPCAT opcode recovery and other solutions require changes to the Bitcoin protocol layer, and the time and cost required are very uncertain and unpredictable. The UTXO isomorphic Bitcoin L2 and EVM compatible Bitcoin Rollup L2 in the realist route are more recognized by developers and capital. UTXO isomorphic Bitcoin L2 is represented by CKB. EVM is compatible with Bitcoin Rollup L2, represented by MerlinChain and BOB.
To be honest, the Bitcoin L1 asset issuance protocol has just begun to form a partial consensus in the Bitcoin community, and the community consensus of Bitcoin L2 is at an earlier stage. But in this cutting-edge field, Bitcoin Magazine and Pantera have tried to set a definition scope for 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.
Using Bitcoin as a settlement mechanism to enforce transactions. Users of Bitcoin L2 must be able to enforce the return of control of their assets on a layer (trusted or untrusted).
Demonstrates functional dependency on Bitcoin. If the Bitcoin mainnet fails but the Bitcoin L2 system remains operational, then the system is not Bitcoin L2. [4]
In other words, they believe that Bitcoin L2 should have data availability verification based on the Bitcoin mainnet, an escape hatch mechanism, BTC as the Bitcoin L2 Gas token, etc. 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 features 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 have written in the white paper that BitVM will be integrated in the future 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 L2s are fake Bitcoin L2s, 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 seen by Bitcoin Maxi as 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.
The UTXO Stack of the CKB ecosystem enables developers to start UTXO Bitcoin L2 with one click, and natively integrates RGB++ protocol capabilities. This enables seamless interoperability between the Bitcoin mainnet and the UTXO isomorphic Bitcoin L2 developed using UTXO Stack through the Leap mechanism. UTXO Stack supports staking BTC, CKB, and BTC L1 assets to ensure the security of UTXO isomorphic Bitcoin L2.
UTXO Stack architecture (Source: Medium)
UTXO Stack currently supports the free flow and interoperability of RGB++ assets between the Bitcoin Lightning Network, CKB Lightning Network, and UTXO Stack parallel L2s. In addition, UTXO Stack also supports the free flow and interoperability of Runes, Atomicals, Taproot Assets, Stamps and other UTXO-based Bitcoin L1 programmability protocol assets between UTXO Stack parallel L2s, CKB Lightning Network, and Bitcoin Lightning Network.
UTXO Stack introduces the modular paradigm into the construction of Bitcoin L2, and cleverly bypasses the Bitcoin mainnet state calculation and data availability verification issues 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 main network. 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 heretical act, but a return to Satoshi Nakamoto's vision.
Bitcoin is the first AppChain (Image source: @tokenterminal)
We borrow the research method of Gartner Hype Cycle and divide Bitcoin programmability solutions into 5 stages:
Technology embryonic stage: DriveChain, UTXO Stack, BitVM, etc.
Inflated expectations: Runes, RGB++, EVM Rollup Bitcoin L2, etc.
Bubble burst period: BRC20, Atomicals, etc.
Steady recovery period: RGB, Lightning Network, Bitcoin sidechain, etc.
Maturity Plateau: Bitcoin scripts, Taproot scripts, hash time locks, etc.
The future of CKB: OP Stack+EigenLayer for Bitcoin ecosystem
Whether it is EVM-compatible Bitcoin Rollup L2, UTXO-isomorphic Bitcoin L2, or new paradigms such as DriveChain, various implementations 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 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 to the Bitcoin ecosystem, but rather a use of Bitcoin's native technology stack (UTXO-based programmability) to achieve a similar ecological structure.
The positioning of CKB's UTXO Stack and Optimism's OP Stack is very similar. 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 and OP Stack have the same structure, both of which are parallel structures.
Current status of CKB ecosystem (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. Currently, there are a large number of decentralized stablecoin protocols, AMM DEX, lending protocols, autonomous worlds 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 the same PoW consensus mechanism as 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, Bitcoin chooses to introduce weights and vByte mechanisms to calculate state space usage fees, while CKB chooses to privatize the state space.
The token economics of CKB 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, assuming that of all circulating CKB, 50% is used to store state, 30% is locked in NervosDAO, and 20% is fully maintained as liquidity. Then, 50% of the secondary issuance (i.e., the rent for storage state) will be distributed to miners, 30% will be distributed to NervosDAO depositors, and the remaining 20% will be distributed to the treasury fund.
This token economic model is able to 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 similar assets on other blockchains do not have, such as natively carrying gas fees, programmability of state space, etc. These unique features make UTXO Stack very suitable as the infrastructure of autonomous world projects to build digital physical reality.
UTXO Stack allows Bitcoin L2 developers to participate in its network consensus using BTC, CKB, and other Bitcoin L1 assets for staking.
Summarize
It is inevitable that Bitcoin will develop to the stage of Turing-complete programmable solutions. However, Turing-complete programmability will not happen on the Bitcoin mainnet, but will happen 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 the Bitcoin programmable protocol: 1. Realizing the free flow of BTC between L1<>L2 without relying on additional social trust assumptions; 2. Attracting a sufficient scale of developers, funds, and users into 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. In addition, thanks to the private nature of the state space in CKB Cell, RBG++ does not bring state explosion pressure to the Bitcoin mainnet like other Bitcoin programmability protocols.
Recently, the ecosystem was initially launched through the issuance of the first batch of RGB++ assets, successfully onboarding about 150,000 new users and a group of new developers to the CKB ecosystem. For example, OpenStamp, a one-stop solution for the Bitcoin L1 programmability protocol Stamps ecosystem, has chosen to use UTXO Stack to build a UTXO-isomorphic Bitcoin L2 serving the Stamps ecosystem.
In the next stage, CKB will focus on building ecological applications, realizing the free flow of BTC between L1<>L2, integrating the lightning network, etc., striving to become the programmability layer of Bitcoin in the future.
Some 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/#1-Introduction
[3] https://medium.com/@ABCDE.com/cn-abcde-Why we invest in utxo-stack-91c9d62fa74e
[4] https://bitcoinmagazine.com/technical/layer-2-is-not-a-magic-incantation