Exploring the Programmability of the Bitcoin Ecosystem

Bitcoin, as the most liquid and secure blockchain currently, has recently attracted a large number of developers' attention. With the rise of inscription technology, developers are beginning to delve into the programmability and scalability issues of Bitcoin. By introducing innovative solutions such as zero-knowledge proofs, data availability, sidechains, rollups, and re-staking, the Bitcoin ecosystem is ushering in a new period of prosperity, becoming the core focus of this bull market.

However, many existing design solutions have adopted the scalability experiences of smart contract platforms like Ethereum, often relying on centralized cross-chain bridges, which has become a potential weakness of the system. There are few solutions designed based on the characteristics of Bitcoin itself, which is related to the unfriendliness of the Bitcoin development environment. Bitcoin has some limitations that make it difficult to execute smart contracts like Ethereum:

1. The scripting language of Bitcoin limits Turing completeness to ensure security, making it unable to execute complex smart contracts like Ethereum.
2. The storage structure of the Bitcoin blockchain is optimized for simple transactions and is not suitable for complex smart contracts.
3. Bitcoin lacks a dedicated virtual machine for running smart contracts.

In recent years, the Bitcoin network has undergone some important upgrades. The Segregated Witness (SegWit) in 2017 increased the block size limit; the Taproot upgrade in 2021 made batch signature verification possible, simplifying operations such as atomic swaps, multi-signature wallets, and conditional payments. These upgrades have laid the foundation for the programmability of Bitcoin.

In 2022, developer Casey Rodarmor proposed "Ordinal Theory", introducing a numbering scheme for Satoshis, making it possible to embed arbitrary data such as images in Bitcoin transactions. This has opened new avenues for directly storing state information and metadata on the Bitcoin chain, providing new ideas for smart contract applications that require accessible and verifiable state data.

Currently, most projects that extend Bitcoin's Programmability rely on Layer 2 networks (L2), which requires users to trust cross-chain bridges, posing a significant barrier for L2 to acquire users and liquidity. Additionally, Bitcoin lacks a native virtual machine or Programmability, making it difficult to achieve communication between L2 and L1 without additional trust assumptions.

Projects like RGB, RGB++, and Arch Network attempt to enhance Bitcoin's Programmability by starting from its native attributes, providing the capability for smart contracts and complex transactions through different methods:

1. RGB is a smart contract solution validated by off-chain clients, recording contract state changes in Bitcoin's UTXO. Although it has certain privacy advantages, it is complex to use, lacks contract programmability, and develops relatively slowly.

2. RGB++ is another extension scheme based on the RGB concept, still based on UTXO binding, but it provides a cross-chain solution for metadata assets by treating the chain itself as a consensus client validator, supporting asset transfers of any UTXO structured chain.

3. Arch Network provides a native smart contract solution for Bitcoin, creating a ZK virtual machine and corresponding validator node network, which records state changes and asset transfers in Bitcoin transactions through aggregated transactions.

RGB

RGB is an early smart contract extension idea in the Bitcoin community, which records state data through the UTXO encapsulation method, providing important insights for subsequent Bitcoin native scaling.

RGB adopts an off-chain verification method, moving the verification of token transfers from the consensus layer of Bitcoin to off-chain, where it is verified by specific transaction-related clients. This approach reduces the need for broadcasting across the entire network, enhancing privacy and efficiency. However, this privacy-enhancing method is also a double-edged sword. While it improves privacy protection, it also makes third parties invisible, complicating the actual operational process and making development difficult, resulting in a poor user experience.

RGB introduces the concept of single-use seals. Each UTXO can only be spent once, which is equivalent to locking it when the UTXO is created and unlocking it when it is spent. The state of the smart contract is encapsulated through UTXO and managed via seals, providing an effective state management mechanism.

RGB++

RGB++ is another extension scheme based on the RGB concept, still built on UTXO binding.

RGB++ utilizes Turing-complete UTXO chains (such as CKB or other chains) to handle off-chain data and smart contracts, further enhancing the Programmability of Bitcoin and ensuring security through isomorphic binding of BTC.

RGB++ uses a Turing-complete UTXO chain as a shadow chain, capable of executing complex smart contracts and binding with Bitcoin's UTXOs, which enhances the system's Programmability and flexibility. The isomorphic binding between Bitcoin's UTXOs and the shadow chain's UTXOs ensures consistency of state and assets between the two chains, guaranteeing transaction security.

RGB++ extends to all Turing-complete UTXO chains, no longer limited to CKB, enhancing cross-chain interoperability and asset liquidity. This multi-chain support allows RGB++ to integrate with any Turing-complete UTXO chain, increasing system flexibility. At the same time, RGB++ achieves bridge-less cross-chain through UTXO isomorphic binding, avoiding the "fake coin" problem and ensuring the authenticity and consistency of assets.

On-chain verification through shadow chains simplifies the client verification process for RGB++. Users only need to check the relevant transactions on the shadow chain to verify whether the state calculations of RGB++ are correct. This on-chain verification method not only simplifies the verification process but also optimizes the user experience. By using a Turing-complete shadow chain, RGB++ avoids the complex UTXO management of RGB, providing a more streamlined and user-friendly experience.

Arch Network

The Arch Network mainly consists of the Arch zkVM and the Arch validation node network, utilizing zero-knowledge proofs and a decentralized validation network to ensure the security and privacy of smart contracts. It is easier to use than RGB and does not require binding to another UTXO chain like RGB++.

Arch zkVM uses RISC Zero ZKVM to execute smart contracts and generate zero-knowledge proofs, which are validated by a decentralized network of verification nodes. The system operates on the UTXO model, encapsulating the state of smart contracts in State UTXOs to enhance security and efficiency.

Asset UTXOs are used to represent Bitcoin or other tokens and can be managed through delegation. The Arch verification network validates ZKVM content through randomly selected leader nodes and uses the FROST signature scheme to aggregate node signatures, ultimately broadcasting the transaction to the Bitcoin network.

Arch zkVM provides a Turing-complete virtual machine for Bitcoin, capable of executing complex smart contracts. After each execution of a smart contract, Arch zkVM generates zero-knowledge proofs to verify the correctness and state changes of the contract.

Arch also uses the Bitcoin UTXO model, where state and assets are encapsulated in UTXOs, enabling state transitions through the concept of single-use. The state data of smart contracts is recorded as state UTXOs, while the original data assets are recorded as Asset UTXOs. Arch ensures that each UTXO can only be spent once, providing secure state management.

Although Arch does not innovate the blockchain structure, it also requires a network of validating nodes. During each Arch Epoch, the system randomly selects a Leader node based on stake, responsible for disseminating received information to all other validating nodes in the network. All zero-knowledge proofs are verified by a decentralized network of validating nodes, ensuring the security and censorship-resistance of the system, and generating signatures for the Leader node. Once a transaction is signed by the required number of nodes, it can be broadcast on the Bitcoin network.

Conclusion

In terms of Bitcoin Programmability design, RGB, RGB++, and Arch Network each have their own characteristics, but all continue the idea of binding UTXO. The one-time use authentication property of UTXO is more suitable for smart contracts used to record states.

However, these solutions also have obvious disadvantages, mainly reflected in user experience. Their confirmation delays and low performance consistent with Bitcoin mean that they only expanded functionality without improving performance, which is particularly evident in Arch and RGB. Although the design of RGB++ provides a better user experience by introducing a higher performance UTXO chain, it also introduces additional security assumptions.

As more and more developers join the Bitcoin community, we will see more scaling solutions, such as the op-cat upgrade proposal, being actively discussed. It is worth paying special attention to those solutions that align with Bitcoin's native properties. The UTXO binding method is the most effective way to expand Bitcoin's Programmability without upgrading the Bitcoin network. As long as the user experience issues can be properly addressed, this will be a significant advancement for Bitcoin smart contracts.