</Define Programmble Bitcoin>
Following Bitcoin’s fourth halving, the growth of Ordinals and the Runes protocol has opened up possibilities for issuing and trading new assets on Bitcoin’s Layer 1. Given Bitcoin’s higher market cap and recognition compared to Ethereum, the ability to program Bitcoin into a new “issuance market” is seen as a significant opportunity for blockchain participants.
Bitcoin’s programmability has evolved from the community and governance that have maintained its ecosystem, rather than from holders or miners. Currently, this community is exploring ways to increase the usage of Bitcoin’s mainnet block space.
Unlike public blockchains like Ethereum, Bitcoin prioritizes the simplicity and lightweight nature of UTXOs. Thus, enabling programmability similar to Ethereum is challenging due to block space limitations and focuses on using scripts and OP codes with UTXOs.
To program on Bitcoin, the community uses two main solutions: (1) EVM-compatible Layer 2 solutions, and (2) native UTXO binding solutions. EVM-compatible solutions resemble existing Ethereum scaling solutions but conflict with “Bitcoin community consensus” due to centralized asset verification. Native UTXO binding solutions align with Bitcoin’s UTXO mechanism and community consensus but lack diverse use cases.
The “Bitcoin community consensus” refers to minimal trust, decentralization, censorship resistance, anonymity, open-source collaboration, permissionlessness, legal neutrality, minimal resource usage, on-chain verification, off-chain computation, transaction immutability, DOS attack resistance, robustness, incentive alignment, and immutable consensus.
Design Space for Bitcoin Programming
Public blockchains like Ethereum address the blockchain trilemma through modularity, parallelization, and Layer 2 solutions, distributing transactions across block space. Bitcoin, however, focuses on optimizing block space through scripts, OP codes, and UTXOs.
UTXO (Unspent Transaction Output) is Bitcoin’s core data structure where each transaction consumes one UTXO and generates new UTXOs, akin to currency notes. They can be split or combined like change, with the smallest unit being a satoshi (sats).
The Segwit hard fork in August 2017 added 3MB of block space for storing signatures, in addition to the 1MB main block space, reducing UTXO output costs and slowing UTXO set expansion. The Taproot soft fork in November 2021 introduced Schnorr multi-signatures, saving block space and verification time for UTXOs.
There have been previous attempts within the community to program Bitcoin. A notable example is Satoshi Nakamoto’s decision in August 2010 to remove the OP-CAT operation code. Although OP-CAT would have enabled programming on Bitcoin, it was removed due to concerns about overloading the block space. Instead, Bitcoin adopted the use of scripts and OP codes to program UTXOs, transaction input fields, output fields, and witness data, allowing for functionalities like multisignatures, timelocks, hashlocks, and process control (OP_IF, OP_ELIF).
Historically, the Bitcoin community has maintained the simplicity, lightweight nature, and ease of verification of UTXOs to stabilize the state expansion of the Bitcoin mainnet in line with Moore’s Law. This evolution has ensured the participation of full nodes in the Bitcoin mainnet and the robustness of transaction verification.
History of Bitcoin Programming
Changes in Bitcoin network output types indicate a historical trend towards Bitcoin programming. Newly designed scripts have increasingly replaced original scripts, as seen with the issuance of assets on Bitcoin using SegWit and Taproot scripts through Ordinals. This shift has accelerated Bitcoin programming.
Ordinals implemented functionality by combining the Bitcoin script, Taproot script-path spend, and operators (OP_FALSE, OP_IF, OP_PUSH, OP_ENDIF).
Before Ordinals, programmable Bitcoin solutions included state channels (Lightning Network), client verification (RGB), sidechains (Liquid Network, Stacks, RootStock), CounterParty, Omni Layer, and DLCs.
Ordinals serialized the smallest atomic unit of UTXO, the satoshi, and inscribed data in the UTXO’s Witness field, linking serialized numbers to specific satoshis. Data indexers then indexed and executed programmable tasks on this data state. This new programming paradigm for Bitcoin is likened to “engraving on gold.”
The new paradigm of Ordinals has enabled a broader segment of the crypto community to use Bitcoin’s mainnet block space for issuing and minting NFT collections and meme coins. However, due to inherent limitations inherited from Bitcoin’s original design, Ordinals only supports three functions: issuance, minting, and transfer. As a result, it is only applicable to BRC20, Runes, Atomicals, Stamps, etc., and is not suitable for DeFi applications requiring state operations and storage.
The potential abuse of block space by Ordinals and BRC20 has raised concerns within the community about Bitcoin’s state explosion. Unlike Ethereum, Bitcoin controls UTXO set data without cumulative state over time. However, if Bitcoin adopts various scaling solutions similar to Ethereum, it may face issues of Layer 1 block dilution caused by Layer 2, which could significantly impact Bitcoin’s security.
The Real Issue: Block Space Dilution
Ethereum follows a development roadmap that prioritizes user experience through Layer 2 solutions. The modular narrative proposed by Ethereum has become an industry standard. Recently, additional Blob block space has been introduced to support Layer 2, improving data availability, reducing fees, and enhancing UX. Structurally, Ethereum’s modular approach seems sound.
However, viewing Ethereum as a Store of Value (SoV) presents challenges. Layer 1 blocks are diluted by Layer 2 solutions, reducing the utility of ETH tokens. Previously, Ethereum processed 300 transactions per block, limited to 30 million Gas, with ETH consumed as fees. Now, over 50 Layer 2 solutions handle hundreds of TPS each, and by storing Layer 2 data in Blobs, the average block size has reverted to pre-2021 NFT levels.
The introduction of Blob storage has exacerbated the dilution of Ethereum’s block space. While Layer 2 solutions previously stored data in Ethereum’s block space, they can now use the more cost-effective Blob storage. This shift has reduced the number of ETH tokens burned, with 28,000 fewer ETH burned since March compared to traditional block space storage. Consequently, Ethereum blocks are no longer scarce, and the modularity of Layer 2 and Layer 3 solutions further contributes to block dilution, undermining Ethereum’s economic scale.
As a result, Layer 2/Layer 3 and Blob storage have led to the dilution of Ethereum’s block space, disrupting its original tokenomics. While Ethereum’s inflation rate is lower than Bitcoin’s, alleviating supply pressure, many ETH holders believe that network expansion will make ETH increasingly scarce. However, ongoing inflation undermines trust in the ETH token. Block space dilution threatens the token’s reliability and confidence.
The Path for Bitcoin
Ethereum can maintain security through ETH staking demand even in the face of inflation. However, Bitcoin’s PoW-based system faces reduced security if inflation and transaction fees decline, leading to miner attrition. Bitcoin’s value as an internet store of value relies on the scarcity of its block space.
Bitcoin cannot adopt the same modular approach as Ethereum due to concerns that Layer 2/Layer 3 solutions might dilute Bitcoin’s value. Instead, Bitcoin needs to develop a new, non-dilutive programmable modular theory for Layer 1. Various native programming solutions are currently proposed for this purpose, including BitVM, RGB, DriveChain, and UTXO homomorphic binding CKB (RGB++).
- BitVM is a native Bitcoin programming solution that enables contract logic to be verified atomically off-chain. Its advantage is that it can be implemented without modifications to the Bitcoin network. However, challenges such as off-chain data management costs, data verification mechanisms, and validator limitations make its adoption complex and time-consuming.
- RGB is a native Bitcoin programming solution enabling smart contracts between parties, similar to the Lightning Network. It allows for the tokenization of assets like stocks and bonds and facilitates rapid transactions. RGB operates by executing smart contracts and managing data off-chain, while storing state and logic on Bitcoin UTXOs. However, RGB’s key challenge is its reliance on both parties running RGB node clients to verify transaction data, which can lead to data availability issues if off-chain data is altered or deleted. While RGB is recognized in the Bitcoin community for its programming capabilities, its practical use is limited by user experience and data availability concerns.
- DriveChain is a sidechain that operates with Bitcoin as the main chain, utilizing its native security through a novel merged mining model. Unlike other Layer 2 solutions with centralized multisig models, DriveChain’s multisig is comprised of Bitcoin miners, ensuring security through delegated hash power. Implementing this model requires support for BIP 300 (hash rate delegation) and BIP 301 (blind merged mining) on Bitcoin.
The solutions mentioned above require significant time for development and community consensus before they can be implemented. Additionally, they either involve excessive reliance on intermediaries or require Bitcoin soft forks, which could undermine Bitcoin’s integrity.
The most rapidly deployable solution is UTXO homomorphic binding. Unlike the aforementioned solutions, it preserves Bitcoin’s integrity and can be implemented without a Bitcoin soft fork. Currently, the leading project in this area is CKB’s RGB++ solution.
RGB++: A UTXO-Homomorphic Binding Model
RGB++ is a Bitcoin Layer 1 asset issuance protocol designed to address existing issues. By integrating Nervos CKB with RGB technology, it maps Bitcoin UTXOs to CKB mainnet’s Cell and uses scripts from both CKB and Bitcoin chains to verify state calculations and ownership changes. For instance, updates to UTXOs on the Bitcoin network are synchronized with the CKB chain, and vice versa. Nervos CKB, a UTXO-based PoW Layer 1 blockchain, facilitates this synchronization by allowing the issuance of assets on both Bitcoin and CKB.
RGB++ addresses data availability issues by moving asset data to cells on the CKB chain, thereby enhancing data management and RGB contract interactions. While RGB initially faced challenges with off-chain data storage, CKB improves data availability by enabling on-chain data storage.
In Nervos CKB, a ‘cell’ is the basic unit of data storage and can contain CKBytes, tokens, TypeScript code, or serialized data (e.g., JSON strings). Each cell includes a Lock Script, a small program that defines ownership. Lock Scripts support Bitcoin mainnet scripts and use TypeScript to enforce specific rules and control usage. This allows developers to customize smart contracts for various use cases, such as NFT issuance, token airdrops, and AMM swaps.
The transaction process for RGB++ is as follows:
- Off-Chain Computation: Perform homomorphic binding using a new Bitcoin UTXO, btc_utxo#2, and an existing CKB cell, btc_utxo#1. Calculate the CKB transaction hash for the new cell based on this binding to generate a commitment.
- Bitcoin Transaction Submission: Create a Bitcoin transaction using btc_utxo#1 as input and submit the commitment via OP_RETURN.
- CKB Transaction Submission: Before creating the CKB transaction, generate it based on the off-chain computation.
- On-Chain Verification: The CKB mainnet uses a Bitcoin light client to verify system-wide state changes, which differs from RGB’s method where transaction data is validated only between the sender and receiver while online.
This process enables RGB++ to synchronize states between the Bitcoin and CKB mainnets, address data availability issues, and facilitate reliable data management and RGB contract interactions.
RGB++ enhances the advantages of existing RGB by offering improved client verification and privacy, along with new features:
- Enhanced Blockchain Client Verification: RGB++ allows users to leverage CKB’s PoW consensus to verify state calculations and UTXO-Cell ownership changes, strengthening client verification and ensuring privacy.
- Transaction Aggregation: RGB++ synchronizes multiple CKB transactions into a single RGB++ transaction on Bitcoin, providing scalability and binding effects despite Bitcoin’s lower TPS.
- Smart Contracts and Shared State: While UTXO-based structures struggle with Turing-complete smart contracts, RGB++ uses CKB cells to address Bitcoin’s programming limitations and support complex smart contracts.
- Improved UX: Unlike RGB, which requires UTXO-based receipts, RGB++ enables transactions within the same CKB environment, simplifying and streamlining the user experience.
RGB++ leverages the state space privatization feature of CKB mainnet cells, requiring not only Bitcoin mining fees for block space but also additional rental costs for cell state space. Cells are designed to prevent state explosion and require continuous payments for their use, thereby preventing the abuse and dilution of Bitcoin’s block space while enabling programmability on Bitcoin’s mainnet.
Previous solutions have gained temporary attention within the community due to technical and use case limitations but quickly faded. In contrast, RGB++ is actively implementing use cases among Bitcoin’s programmable solutions and is increasingly recognized by the Bitcoin community for enhancing Bitcoin’s scalability and integrity.
xUDT and Spore: Bitcoin Assets with Ethereum-Like Functionality
RGB++ is designed to support tokenization standards from Ethereum on Bitcoin. In RGB++, ERC-20 is implemented as xUDT, allowing various models such as airdrops, subscriptions, and supply limits to be used on Bitcoin, including rebase tokens. NFTs are issued under the Spore standard as Digital Objects (DOBs), which store metadata entirely on-chain to resolve data availability issues and support a participatory model.
While the original RGB protocol, based on state channels and the Lightning Network, faced limitations due to Bitcoin’s scripting capabilities, RGB++ utilizes CKB’s Turing-complete scripting system to implement state channels and Lightning Network solutions for RGB++ assets.
With these standards and features, RGB++ enables not just asset issuance but also complex applications like asset trading, lending, and CDP stablecoins. For instance, combining RGB++ homomorphic binding logic with Bitcoin’s PSBT scripts can facilitate the creation of order book-based DEXs.
Leap: Trustless Bitcoin Bridge
RGB++’s homomorphic binding ensures that Bitcoin and CKB states remain synchronized without intermediate states. Each RGB++ transaction is mirrored on both the BTC and CKB chains simultaneously. On the Bitcoin side, RGB transactions are compatible with the RGB protocol, while on the CKB side, client verification confirms the correctness of the RGB++ transaction state by checking related CKB transactions.
Asset cross-chain transfers between RGB++ and the CKB mainnet are achieved without introducing third-party trust, relayers, or centralized multi-sig setups. RGB++ assets can seamlessly transfer in their native form between the Bitcoin mainnet and the CKB mainnet through CKB’s Leap cross-chain solution.
RGB++ supports asset transfers from Bitcoin Layer 1, including CKB-bound RGB++ assets, to CKB via Leap, as well as to other UTXO-based Turing-complete chains like Cardano, Fuel, and Sui. It also facilitates the movement of Bitcoin Layer 2 assets back to the Bitcoin mainnet. These capabilities enable trustless cross-chain asset transfers across Bitcoin and various blockchain networks, enhancing scalability and flexibility.
UTXO Stack: Enabling Interoperability with Bitcoin Layer 2
The UTXO Stack within the CKB ecosystem allows developers to easily deploy UTXO-based Bitcoin Layer 2 solutions. It offers a “Rollup as a Service” based on RGB++, facilitating the seamless distribution of rollups. By enabling homomorphic binding between Bitcoin mainnet and UTXO Stack-developed UTXOs, UTXO Stack ensures interoperability between Bitcoin Layer 2 solutions without asset wrapping through the Leap mechanism. Additionally, it secures Bitcoin Layer 2 by staking BTC, CKB, and BTC Layer 1 assets.
The UTXO Stack enables seamless interoperability of RGB++ assets between Bitcoin’s Lightning Network, CKB’s Lightning Network, and UTXO Stack Layer 2 solutions. Additionally, it supports the free movement and interaction of assets issued on Bitcoin’s UTXO-based networks, including Runes, Atomicals, Taproot Assets, and Stamps, across UTXO Stack Layer 2, CKB’s Lightning Network, and Bitcoin’s Lightning Network.
By integrating a native modular structure on Bitcoin, UTXO Stack bypasses state computation and data availability issues on the Bitcoin mainnet through homomorphic binding. In this modular framework, Bitcoin serves as the consensus and settlement layer, CKB as the data availability layer, and UTXO Stack provides the execution layer for Layer 2 solutions.
This approach allows UTXO Stack to achieve trustless cross-chain asset movement between Bitcoin and various blockchain networks, enhancing scalability and flexibility.
Nostr Binding Protocol: Revitalizing Bitcoin-Native Social Fi
Nostr, a Bitcoin-native social protocol supported by Twitter founder Jack Dorsey, aims to address issues like censorship, advertising, and addiction prevalent on platforms like Twitter. It seeks to create a social media infrastructure where users retain control over their speech and data. Nostr shares a vision with Ethereum’s Farcaster, featuring similar core functionalities. While Farcaster’s Frame feature significantly enhanced the Social Fi narrative, Nostr lacks such capabilities due to Bitcoin’s programming limitations, resulting in fewer utilities compared to platforms like Twitter, Farcaster, and Lens.
The Nostr Binding Protocol leverages RGB++ to add tokenization and application utilities missing in Nostr. By binding token and application states to CKB’s Cells using homomorphic encryption, it enhances data security and availability on the Bitcoin UTXO and CKB networks. This integration enables Nostr to issue Bitcoin-based meme coins, delivering network effects and introducing new liquidity to the Bitcoin ecosystem.
Conclusion
Current Bitcoin programming solutions, such as EVM rollups, UTXO homomorphic binding, and DriveChain, are positioning Bitcoin primarily as a consensus and settlement layer.
Just as convergent evolution occurs naturally, Bitcoin programming advancements are likely to align with Ethereum’s ecosystem to some extent. However, due to issues like block space dilution and Bitcoin’s tradition, Bitcoin’s evolution will leverage its unique technology stack (UTXO-based model) rather than directly adopting Ethereum’s tech stack.
CKB enables interoperability between assets issued on Bitcoin and those on Layer 1 and Layer 2 without relying on additional social trust. RGB++, by utilizing CKB’s cell state space privatization, minimizes the impact of block space dilution and state explosion, unlike other solutions. Additionally, UTXO Stack introduces shared sequencers, restaking, and RaaS models based on Bitcoin UTXO, significantly reducing the capital and resources needed for UTXO homomorphic binding L2 development. Together, CKB and UTXO Stack provide comprehensive native Bitcoin programming solutions.
The debate between Bitcoin’s digital gold narrative and its programming narrative is ongoing. Some Bitcoin OGs view the rise of programmable Layer 1 protocols after 2023 as a new threat to Bitcoin, seeing it as part of a broader contention over Bitcoin’s scalability and block size, following earlier debates among Bitcoin maximalists and scalability advocates.
However, another perspective considers Bitcoin as a digital gold APP chain. From this viewpoint, Bitcoin’s role as a decentralized ledger has shaped its UTXO model and programming protocols. Yet, Satoshi Nakamoto’s original vision was to create a form of peer-to-peer electronic cash. While digital gold requires secure storage, electronic cash necessitates a payment network akin to central and commercial banks. Thus, Bitcoin programming is not a deviation but a return to Nakamoto’s vision.
