New Developments in the Programmability of the Bitcoin Ecosystem

Bitcoin, as the most liquid and secure blockchain in the market, has recently attracted the attention of a large number of developers. With the rise of inscriptions, the Programmability and scalability issues of the BTC ecosystem have become the focus of developers. Various innovative solutions such as zero-knowledge proofs, data availability, sidechains, rollups, and restaking have been introduced, driving the BTC ecosystem towards a new prosperity and becoming the main focus of the current market.

However, many solutions still rely on the scaling experience of smart contract platforms like Ethereum, often depending on centralized cross-chain bridges, which has become a potential weakness of the system. There are relatively few solutions designed based on the characteristics of BTC, which is related to the development difficulty of BTC itself. Bitcoin cannot run smart contracts directly like Ethereum for the following reasons:

1. The Bitcoin scripting language limits Turing completeness to ensure security.
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 virtual machine for executing smart contracts.

In recent years, the Bitcoin network has undergone some significant upgrades. The SegWit upgrade in 2017 expanded the block size limit; the Taproot upgrade in 2021 enabled batch signature verification, improving transaction processing efficiency. These upgrades laid the foundation for the programmability of Bitcoin.

In 2022, developer Casey Rodarmor proposed the "Ordinal Theory," which opened up new avenues for embedding metadata on the Bitcoin blockchain, providing new possibilities for applications that require accessible and verifiable state data.

Currently, most projects that enhance Bitcoin's Programmability rely on layer two networks (L2), which requires users to trust cross-chain bridges, becoming a major obstacle for L2 to acquire users and liquidity. Additionally, Bitcoin lacks a native virtual machine or Programmability, making it difficult to achieve direct communication between L2 and L1 without additional trust assumptions.

RGB, RGB++, and Arch Network are three schemes that attempt to enhance Bitcoin's Programmability by leveraging its native attributes. They provide smart contract and complex transaction capabilities through different means:

1. RGB adopts an off-chain client-validated smart contract solution, recording contract state changes in Bitcoin's UTXO. Although it has privacy advantages, it is complex to operate, lacks contract programmability, and develops relatively slowly.

2. RGB++ builds on the RGB concept by using the chain itself as a consensus client validator, providing a cross-chain solution for metadata assets, supporting asset transfers on any UTXO structured chain.

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

Detailed Explanation of RGB Scheme

RGB is an early smart contract extension idea from the BTC community, which encapsulates state data through UTXO, providing important insights for the subsequent native scaling of BTC.

RGB adopts an off-chain verification method, transferring token transfer verification from the Bitcoin consensus layer 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 enhancement also brings about complexities in operation and difficulties in development, which affect the user experience.

RGB introduces the concept of single-use seals. Each UTXO can only be spent once, equivalent to being locked at creation and unlocked at spending. The smart contract state is encapsulated through UTXO and managed by seals, providing an effective state management mechanism.

RGB++ Solution Analysis

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

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

RGB++ uses a Turing-complete UTXO chain as a shadow chain, which not only executes complex smart contracts but also binds with Bitcoin UTXO, enhancing the system's programmability. The isomorphic binding of Bitcoin UTXO and shadow chain UTXO ensures consistency of state and assets between the two chains, guaranteeing transaction security.

RGB++ extension supports all Turing-complete UTXO chains, enhancing cross-chain interoperability and asset liquidity. It achieves bridge-less cross-chain through UTXO isomorphic binding, avoiding the "fake coin" problem of traditional cross-chain bridges, ensuring asset authenticity and consistency.

RGB++ simplifies the client verification process through on-chain verification using shadow chains. Users only need to check the relevant transactions on the shadow chain to verify the correctness of the RGB++ state calculations, optimizing the user experience.

Arch Network Solution Analysis

The Arch Network mainly consists of the Arch zkVM and the Arch verification node network, utilizing zero-knowledge proofs and a decentralized verification 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, verified by a decentralized network of validator nodes. The system operates on the UTXO model, encapsulating smart contract states 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, using the FROST signature scheme to aggregate node signatures, and finally broadcasting the transaction to the Bitcoin network.

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

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

Arch requires a verification node network. During each Arch Epoch, the system randomly selects Leader nodes based on equity to be responsible for information dissemination. All zk-proofs are verified by a decentralized verification node network, ensuring system security and censorship resistance, and generating signatures for the Leader nodes. Once a transaction receives enough node signatures, it can be broadcast on the Bitcoin network.

Summary and Outlook

RGB, RGB++, and Arch Network each have their own characteristics in the design of BTC Programmability, continuing the approach of binding UTXO. The one-time use characteristic of UTXO is more suitable for recording the state of smart contracts.

However, these solutions also have obvious disadvantages, mainly reflected in poor user experience, long confirmation delays, and low performance. Arch and RGB mainly expanded functionality but did not improve performance; RGB++ improved user experience by introducing a high-performance UTXO chain but also brought additional security assumptions.

As more developers join the BTC community, we will see more innovative scaling solutions, such as the op-cat upgrade proposal, which is under active discussion. Solutions that align with BTC's native properties are worthy of special attention. The UTXO binding method is an effective way to expand BTC's Programmability without upgrading the BTC network. As long as user experience issues can be effectively addressed, this will bring significant breakthroughs to the development of BTC smart contracts.