UTXO Binding: A Detailed Explanation of BTC Smart Contract Solutions RGB, RGB++, and Arch Network

Introduction

Bitcoin is currently the most liquid and secure blockchain. After the outbreak of inscriptions, the BTC ecosystem attracted a large number of developers who quickly focused on the issues of BTC's programmability and scalability. By introducing different ideas such as ZK, DA, sidechains, rollups, and restaking, the prosperity of the BTC ecosystem is reaching a new peak, seemingly becoming the main storyline of this bull market.
However, many of these designs continue the scalability experiences of smart contracts like ETH and must rely on a centralized cross-chain bridge, which is a weakness of the system. Few solutions are designed based on the characteristics of BTC itself, which is related to the unfriendly developer experience of BTC. Due to some reasons, it cannot run smart contracts like Ethereum:

1. Bitcoin's scripting language limits Turing completeness for security, making it impossible to execute smart contracts like Ethereum.
2. At the same time, the storage of the Bitcoin blockchain is designed for simple transactions and is not optimized for complex smart contracts.
3. Most importantly, Bitcoin does not have a virtual machine to run smart contracts.

The introduction of Segregated Witness (SegWit) in 2017 increased Bitcoin's block size limit; the Taproot upgrade in 2021 made batch signature verification possible, allowing for easier and faster transaction processing (unlocking atomic swaps, multi-signature wallets, and conditional payments). This has made programmability on Bitcoin possible.
In 2022, developer Casey Rodarmor proposed his "Ordinal Theory," outlining a numbering scheme for Satoshis that allows arbitrary data such as images to be embedded in Bitcoin transactions, opening up new possibilities for directly embedding state information and metadata on the Bitcoin chain. This provides a new avenue for applications like smart contracts that require accessible and verifiable state data.
Currently, most projects expanding Bitcoin's programmability rely on Bitcoin's Layer 2 (L2) network, which forces users to trust cross-chain bridges, becoming a significant challenge for L2 to acquire users and liquidity. Additionally, Bitcoin currently 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 all attempt to enhance Bitcoin's programmability based on BTC's 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, where the state changes of the smart contracts are recorded in Bitcoin's UTXO. While it has certain privacy advantages, it is cumbersome to use and lacks contract composability, currently developing very slowly.
2. RGB++ is another expansion route under Nervos based on RGB's ideas, still bound to UTXO, but by treating the chain itself as a consensus client validator, it provides a cross-chain solution for metadata assets and allows support for the transfer of any UTXO-structured chain.
3. Arch Network provides a native smart contract solution for BTC, creating a ZK virtual machine and corresponding validator node network, recording state changes and asset phases in BTC transactions through aggregated transactions.

RGB

RGB is an early smart contract expansion idea in the BTC community, which records state data through UTXO encapsulation, providing important ideas for subsequent native expansion of BTC.

RGB adopts an off-chain validation method, moving the verification of token transfers from Bitcoin's consensus layer to off-chain, validated by specific transaction-related clients. This approach reduces the need for full network broadcasting, enhancing privacy and efficiency. However, this privacy enhancement is also a double-edged sword. By allowing only nodes related to specific transactions to participate in the validation work, it enhances privacy protection but also leads to third-party invisibility, making the actual operation process complex and difficult to develop, resulting in a poor user experience.
Additionally, RGB introduces the concept of single-use seals. Each UTXO can only be spent once, effectively locking it when creating the UTXO and unlocking it when spending it. The state of the smart contract is encapsulated by UTXO and managed through seals, providing an effective state management mechanism.

RGB++

RGB++ is another expansion route under Nervos based on RGB's ideas, still bound to UTXO.
RGB++ utilizes Turing-complete UTXO chains (such as CKB or other chains) to handle off-chain data and smart contracts, further enhancing Bitcoin's programmability and ensuring security by homogeneously binding BTC.

RGB++ adopts Turing-complete UTXO chains. By using a Turing-complete UTXO chain like CKB as a shadow chain, RGB++ can handle off-chain data and smart contracts. This chain can not only execute complex smart contracts but also bind with Bitcoin's UTXO, thereby increasing the system's programmability and flexibility. Furthermore, the homogenous binding of Bitcoin's UTXO and the shadow chain's UTXO ensures consistency of state and assets between the two chains, thus guaranteeing the security of transactions.
In addition, RGB++ expands to all Turing-complete UTXO chains, no longer limited to CKB, thereby enhancing cross-chain interoperability and asset liquidity. This multi-chain support allows RGB++ to combine with any Turing-complete UTXO chain, enhancing the system's flexibility. At the same time, RGB++ achieves bridge-less cross-chain through UTXO homogenous binding, avoiding the "fake coin" problem and ensuring the authenticity and consistency of assets.
By conducting on-chain validation through the shadow chain, RGB++ simplifies the client validation process. 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 validation 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

Arch Network mainly consists of the Arch zkVM and the Arch validator node network, utilizing zero-knowledge proofs (zk-proofs) and a decentralized validation network to ensure the security and privacy of smart contracts, making it more user-friendly than RGB and not requiring another UTXO chain for binding like RGB++.
The Arch zkVM executes smart contracts and generates zero-knowledge proofs using RISC Zero ZKVM, which are validated by a decentralized network of validator nodes. The system operates based 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 validation network verifies the ZKVM content through randomly selected leader nodes and aggregates node signatures using the FROST signature scheme, ultimately broadcasting the transaction to the Bitcoin network.

The Arch zkVM provides Bitcoin with a Turing-complete virtual machine capable of executing complex smart contracts. After each execution of a smart contract, the Arch zkVM generates zero-knowledge proofs, which are used to verify the correctness of the contract and state changes.
Arch also utilizes Bitcoin's UTXO model, with state and assets encapsulated in UTXOs, using the concept of single-use for state transitions. 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, thus providing secure state management.
Although Arch does not innovate the blockchain structure, it still requires a validation node network. During each Arch Epoch, the system randomly selects a Leader node based on stake, responsible for disseminating received information to all other validator nodes in the network. All zk-proofs are verified by a decentralized network of validator nodes, ensuring the system's security and resistance to censorship, 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 BTC programmability design, RGB, RGB++, and Arch Network each have their characteristics, but all continue the idea of binding UTXO, with the single-use authentication property of UTXO being more suitable for smart contracts to record state.
However, its disadvantages are also very obvious, namely poor user experience, confirmation delays consistent with BTC, and low performance, meaning it only expands functionality without improving performance, which is more evident in Arch and RGB; while RGB++'s design, although providing a better user experience by introducing a higher-performance UTXO chain, also raises additional security assumptions.
As more developers join the BTC community, we will see more expansion solutions, such as the op-cat upgrade proposal, which is also under active discussion. Solutions that align with BTC's native attributes need to be a focus, as the UTXO binding method is the most effective way to expand BTC's programming capabilities without upgrading the BTC network. As long as the user experience issue can be well addressed, it will be a significant advancement for BTC smart contracts.