UTXO binding: Detailed explanation of BTC smart contract solutions RGB, RGB++ and Arch Network

Introduction

BTC is currently the blockchain with the best Liquidity and the highest security. After the inscription outbreak, a large number of developers flocked into the BTC ecosystem, and they quickly followed the programmability issues and scaling problems of BTC. By introducing different approaches such as ZK, DA, Sidechain, rollup, restaking, etc., the prosperity of the BTC ecosystem is reaching a new high, and it has become the main storyline of this round of the Bull Market.

However, in these designs, many of them continue the scaling experience of ETH and other Smart Contracts, and they must rely on a centralized cross-chain bridges, 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 itself. Due to some reasons, it cannot run Smart Contracts like Ethereum:

• The scripting language of BTC restricts Turing completeness for security reasons, which means that it cannot execute Smart Contracts like ETH.
• At the same time, the storage of the BTC blockchain is designed for simple transactions and is not optimized for complex Smart Contracts.
• The most important thing is that BTC does not have a Virtual Machine to run Smart Contracts.

The introduction of SegWit in 2017 increased the Block size limit of BTC; the Taproot upgrade in 2021 made batch signature verification possible, making it easier and faster to process transactions (unlock atomic swaps, Multi-signature Wallet, and conditional payments). All of this makes programmability possible on BTC.

In 2022, developer Casey Rodarmor proposed his “Ordinal Theory”, which outlines Satoshi’s numbering scheme that allows for the inclusion of arbitrary data such as images in BTC transactions, opening up new possibilities for embedding status information and metadata on-chain, providing a new approach for applications like Smart Contracts that require accessible and verifiable state data.

Currently, most BTC programming extension projects rely on BTC’s Layer 2 network (L2), which makes it a major challenge for users to trust cross-chain bridges to access users and liquidity in L2. In addition, BTC currently lacks a native Virtual Machine or programmability, which makes it impossible to achieve communication between L2 and L1 without additional trust assumptions.

Arch Network, RGB, and RGB++ all attempt to enhance the programmability of BTC from its native attributes, and provide the ability for Smart Contracts and complex transactions through different methods:

• RGB is a Smart Contract solution that is validated by off-chain clients, and the state changes of Smart Contracts are recorded in the UTXO of BTC. Although it has certain privacy advantages, it is cumbersome to use and lacks contract composability, and its development is currently very slow.
• RGB++ is another extension route of Nervos based on the idea of RGB. It still relies on UTXO binding, but by using the chain itself as a client validator with Consensus, this provides a solution for Metadata asset Cross-Chain Interaction and allows it to support the transfer of any UTXO-based chain.
• The Arch Network provides a native Smart Contract solution for BTC, creating a ZK Virtual Machine and a corresponding validators Node network to record state changes and asset phases in BTC transactions through aggregated transactions.

Arch Network

Arch Network is primarily composed of Arch zkVM and Arch verification Node network, using Zero-Knowledge Proof (zk-proofs) and Decentralization verification network to ensure the security and privacy of Smart Contracts, which is more user-friendly 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 Proof, which is verified by the Decentralization’s verification Node network. The system operates based on the UTXO model, encapsulating Smart Contract states in State UTXOs to enhance security and efficiency.

Asset UTXOs are used to represent BTC or other Tokens and can be managed through delegation. The Arch validation network validates the ZKVM content through randomly selected leader Nodes and aggregates Node signatures using the FROST signature scheme, and finally broadcasts the Transaction to the BTC network.

Arch zkVM provides a Turing Complete Virtual Machine for BTC, which can execute complex Smart Contracts. After each Smart Contract execution, Arch zkVM generates Zero-Knowledge Proofs, which are used to verify the correctness and state changes of the contract.

Arch The UTXO model of BTC is also used, and the state and assets are encapsulated in UTXOs, and state transitions are made through the concept of single-use. The state data of the Smart Contract is recorded as state. UTXOs, while the original data asset is recorded as Asset UTXOs. ARCH ensures that each UTXO can only be spent once, thus providing secure state management.

**Arch Although there is no innovative blockchain structure, a validating Node network is also needed. **In each Arch Epoch During this period, the system will randomly select a Leader Node based on the equity, and the Leader Node is responsible for spreading the received information to all other validators nodes in the network. All zk-proofs All verified by the verification node network of Decentralization to ensure the security and anti-censorship of the system, and generate signatures for the Leader Node. Once the transaction is signed by the required number of nodes, it can be broadcast on the BTC network.

RGB

RGB is an early Smart Contract extension idea in the BTC community. It records state data through UTXO encapsulation, providing important ideas for subsequent BTC native expansion.

RGB adopts off-chain verification method to transfer the validation of tokens from the consensus layer of BTC to off-chain, which is verified by specific transaction-related clients. This method reduces the need for broadcasting across the network, enhancing privacy and efficiency. However, this privacy-enhancing method is also a double-edged sword. By allowing only nodes related to specific transactions to participate in the verification process, it enhances privacy protection but also makes it difficult for third parties to see, resulting in complex and challenging development processes and poor user experience.

And, RGB introduces the concept of single-use seal. Each UTXO can only be spent once, which is equivalent to locking when creating UTXO and unlocking when spending it. The state of the Smart Contract is encapsulated through UTXO and managed through seals, thus providing an effective state management mechanism.

RGB++

RGB++ is another extension route of Nervos based on the idea of RGB, still based on UTXO binding.

RGB++ uses Turing Complete UTXO chains (such as CKB or other chains) to process off-chain data and smart contracts, further enhancing the programmability of BTC, and ensuring security through isomorphic binding of BTC.

RGB++ adopts a Turing Complete UTXO chain. By using a Turing Complete UTXO chain like CKB as the shadow chain, RGB++ is able to process off-chain data and smart contracts. This chain can not only execute complex smart contracts, but also bind with the UTXO of BTC, thereby increasing the programmability and flexibility of the system. In addition, the isomorphic binding of UTXO between BTC and the shadow chain ensures the consistency of state and assets between the two chains, thus ensuring the security of transactions.

In addition, RGB++ not only extends to all Turing Complete UTXO chains, no longer limited to CKB, thereby enhancing Cross-Chain Interaction interoperability and asset Liquidity. This multi-chain support allows RGB++ to combine with any Turing Complete UTXO chain, enhancing system flexibility. At the same time, RGB++ achieves bridgeless Cross-Chain Interaction through UTXO isomorphic binding, different from traditional Cross-Chain Interaction bridges, this approach avoids the ‘fake coin’ problem, ensuring the authenticity and consistency of assets.

By using the shadow chain for on-chain verification, RGB++ simplifies the client verification process. Users only need to check the relevant transactions on the shadow on-chain to verify the correctness of the state calculation of RGB++. This on-chain verification method not only simplifies the verification process but also optimizes the user experience. Due to the use of a Turing Complete shadow chain, RGB++ avoids the complex UTXO management of RGB and provides a more simplified and user-friendly experience.

Conclusion

In terms of BTC’s programmability design, RGB, RGB++, and Arch Network each have their own characteristics, but they all continue the approach of binding UTXO. The unique one-time authentication property of UTXO is more suitable for Smart Contract to record state.

However, its disadvantages are also very obvious, namely poor user experience, consistent confirmation latency and low performance with BTC, that is, it only extends functionality without improving performance, which is more obvious in Arch and RGB; while the design of RGB++ provides a better user experience by introducing a higher-performance UTXO chain, it also raises additional security assumptions.

With more developers joining the BTC community, we will see more scaling solutions, such as the upgrade proposal for op-cat, being actively discussed. Solutions that are in line with the native properties of BTC need to be followed closely. The UTXO binding method is the most effective way to expand the BTC programming method without upgrading the BTC network. As long as the user experience issues can be resolved, it will be a huge advancement for BTC Smart Contracts.