Exploration of Bitcoin Ecosystem Programmability

Bitcoin, as the most liquid and secure blockchain currently, is attracting a large number of developers' attention to its Programmability and scalability issues. By introducing various solutions such as ZK, DA, sidechains, rollups, and restaking, the Bitcoin ecosystem is迎来新的繁荣高峰, becoming the main focus of this bull market.

However, many design solutions continue the scalability experience of smart contract platforms like Ethereum, and most rely on centralized cross-chain bridges, which become potential weaknesses of the system. Few solutions are designed based on the characteristics of Bitcoin itself, which is related to the development difficulty of Bitcoin. For several reasons, Bitcoin cannot run smart contracts directly like Ethereum:

1. The Bitcoin scripting language limits Turing completeness for security reasons, making it unable to execute complex smart contracts.
2. The Bitcoin blockchain storage is designed for simple transactions and has not been optimized for complex smart contracts.
3. Bitcoin lacks a virtual machine for running smart contracts.

The SegWit upgrade in 2017 increased the block size limit and implemented the (SegWit); the Taproot upgrade in 2021 realized batch signature verification, improving transaction processing efficiency. These upgrades created conditions for the Programmability of Bitcoin.

In 2022, developer Casey Rodarmor proposed "Ordinal Theory", outlining a numbering scheme for Satoshis that allows arbitrary data to be embedded in Bitcoin transactions, providing new ideas for applications such as smart contracts.

Currently, most projects that enhance the Programmability of Bitcoin rely on Layer 2 networks (L2), which requires users to trust cross-chain bridges, creating obstacles for L2 to acquire users and liquidity. Moreover, Bitcoin lacks a native virtual machine or Programmability, making it impossible to achieve communication between L2 and L1 without additional trust assumptions.

RGB, RGB++, and Arch Network attempt to enhance the programmability of Bitcoin by starting from its native properties through different methods:

1. RGB implements smart contracts through off-chain client validation, recording state changes in Bitcoin UTXOs. Although it has privacy advantages, it is cumbersome to use and lacks contract composability, leading to slow development.

2. RGB++ builds on RGB by utilizing a Turing-complete UTXO chain to process off-chain data and smart contracts, ensuring security through isomorphic binding with Bitcoin.

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

RGB

RGB is an early smart contract extension idea from the Bitcoin community, which encapsulates state data through UTXO, providing important ideas for subsequent native scalability.

RGB uses off-chain verification, moving the token transfer verification from the consensus layer to off-chain, validated by specific transaction-related clients. This reduces the broadcasting requirements across the network, enhancing privacy and efficiency, but also leads to third-party invisibility, increased complexity of operations, and greater development difficulty.

RGB introduces the concept of single-use seals, where each UTXO can only be spent once, locked at creation and unlocked when spent. The smart contract state is encapsulated by UTXO and managed by the seals, providing an effective state management mechanism.

RGB++

RGB++ builds on the RGB concept and develops based on UTXO binding. It utilizes a Turing-complete UTXO chain to handle off-chain data and smart contracts, enhancing Bitcoin's Programmability, and ensures security through isomorphic binding of BTC.

RGB++ uses a Turing-complete UTXO chain as a shadow chain to handle off-chain data and smart contracts. This chain can execute complex smart contracts and is bound to Bitcoin UTXO, enhancing system programmability and flexibility. The Bitcoin UTXO is isomorphically bound to the shadow chain UTXO, ensuring state and asset consistency between the two chains, thereby 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, and ensuring asset authenticity and consistency.

On-chain verification through shadow chains simplifies the client verification process for RGB++. Users only need to check the transactions related to the shadow chain to verify the correctness of the RGB++ state calculation. This method simplifies the verification process, optimizes user experience, and avoids the complex UTXO management of RGB.

Arch Network

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

Arch zkVM executes smart contracts using RISC Zero ZKVM and generates zero-knowledge proofs, validated by a decentralized network of validator nodes. The system operates on the UTXO model, encapsulating the state of smart contracts in State UTXOs, enhancing security and efficiency.

Asset UTXOs represent Bitcoin or other tokens, which can be managed through delegation. The verification network randomly selects leader nodes to validate the ZKVM content, using the FROST signature scheme to aggregate node signatures, and finally broadcasting the transaction to the Bitcoin network.

Arch zkVM provides a Turing-complete virtual machine for Bitcoin, 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, with state and assets encapsulated in UTXOs, facilitating 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 Epoch, the system randomly selects Leader nodes based on stakes, responsible for information dissemination. All proofs are verified by a decentralized verification node network, ensuring system security and censorship resistance, and generating signatures for Leader nodes. Once transactions receive the necessary node signatures, they can be broadcast on the Bitcoin network.

Conclusion

RGB, RGB++, and Arch Network each have their own characteristics in the design of Bitcoin Programmability, all of which continue the approach of binding UTXO. The one-time use authentication property of UTXO is more suitable for smart contract state recording.

However, these solutions also face issues such as poor user experience, long confirmation delays, and low performance. Arch and RGB mainly expand functionality without improving performance; RGB++ improves user experience by introducing a high-performance UTXO chain but adds extra security assumptions.

As more developers join the Bitcoin community, we will see more scaling solutions, such as the op-cat upgrade proposal, being actively discussed. Solutions that align with Bitcoin's native properties are worth focusing on, and the UTXO binding method is an effective way to expand programmability without upgrading the network. If user experience issues can be resolved, it will be a significant advancement for Bitcoin smart contracts.