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

Author: Trustless Labs; Original link: https://www.chaincatcher.com/article/2137941

Bitcoin is currently the most liquid and secure blockchain. After the outbreak of the inscription, the BTC ecosystem attracted a large number of developers, who quickly paid attention to the programmability and expansion issues of BTC. By introducing different ideas, such as ZK, DA, side chains, rollup, restaking and other solutions, the prosperity of the BTC ecosystem is ushering in a new high, and it has become the main plot of this round of bull market.

However, in these designs,many of them continue the expansion experience of smart contracts such as ETH, and must rely on a centralized cross-chain bridge, which is the weak point 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. There are a few reasons why it can't run smart contracts like Ethereum:

1. Bitcoin's scripting language limits Turing completeness for security, which makes 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 makes batch signature verification possible, making it easier and faster to process transactions (unlocking atomic swaps, multi-signature wallets, and conditional payments). All of this makes programmability on Bitcoin possible.

In 2022, developer Casey Rodarmor proposed his "Ordinal Theory", outlining a numbering scheme for Satoshis that could put arbitrary data, such as images, into Bitcoin transactions, opening up new possibilities for embedding state information and metadata directly on the Bitcoin chain, which opens up a new path for applications such as smart contracts that require accessible and verifiable state data.

Currently, most projects that extend Bitcoin's programmability rely on Bitcoin's second-layer network (L2), which requires users to trust cross-chain bridges, becoming a major challenge for L2 to acquire users and liquidity. In addition, Bitcoin currently lacks a native virtual machine or programmability, and cannot enable L2 to communicate with L1 without additional trust assumptions.

RGB, RGB++ and Arch Network all try to enhance the programmability of Bitcoin based on the native properties of BTC, and provide smart contracts and complex transaction capabilities through different methods:

1. RGB is a smart contract solution verified by off-chain clients, and the state changes of smart contracts are recorded in Bitcoin's UTXO. Although it has certain privacy advantages, it is cumbersome to use and lacks the composability of contracts. It is currently developing very slowly.

2. RGB++ is another extension route under the RGB idea. It is still based on UTXO binding, but by using the chain itself as a client validator with consensus, it provides a cross-chain solution for metadata assets and allows it to support the transfer of any UTXO structure chain.

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

RGB

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

RGB adopts off-chain verification, moving the verification of token transfer from the consensus layer of Bitcoin to off-chain, and verifying it by the client related to the specific transaction. This method reduces the need for full network broadcasting and enhances privacy and efficiency. However, this privacy enhancement method is also a double-edged sword. By only allowing nodes related to specific transactions to participate in the verification work, although privacy protection is enhanced, it also makes third parties invisible, making the actual operation process complicated and difficult to develop, and the user experience is poor.

In addition, RGB introduces the concept of a single-use seal. Each UTXO can only be spent once, which is equivalent to locking it when creating the UTXO and unlocking it when spending it. The state of the smart contract is encapsulated by the UTXO and managed by the seal, thus providing an effective state management mechanism.

RGB++

RGB++ is another extension route under the RGB idea, 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 improving the programmability of Bitcoin, and ensuring security through isomorphic binding to BTC.

RGB++ uses Turing-complete UTXO chains. By using a Turing-complete UTXO chain like CKB as a shadow chain, RGB++ is able to handle off-chain data and smart contracts. This chain can not only execute complex smart contracts, but can also bind with Bitcoin's UTXO, which increases the programmability and flexibility of the system. In addition, the isomorphic binding of Bitcoin's UTXO and the shadow chain's UTXO ensures the consistency of states and assets between the two chains, thereby ensuring the security of transactions.

In addition, RGB++ can be extended to all Turing-complete UTXO chains, no longer limited to CKB, thereby improving cross-chain interoperability and asset liquidity. This multi-chain support allows RGB++ to be combined with any Turing-complete UTXO chain, enhancing the flexibility of the system. At the same time, RGB++ achieves bridgeless cross-chain through UTXO isomorphic binding, which, unlike traditional cross-chain bridges, avoids the "fake currency" problem and ensures the authenticity and consistency of assets.

RGB++ simplifies the client verification process through shadow chain verification. Users only need to check the relevant transactions on the shadow chain to verify whether the state calculation of RGB++ is correct. This on-chain verification method not only simplifies the verification process, but also optimizes the user experience. Due to the use of Turing-complete shadow chain, RGB++ avoids RGB's complex UTXO management and provides a more simplified and user-friendly experience.

Recommended reading: RGB++ Layer: Opening a new era for the Bitcoin ecosystem 

Arch Network

Arch Network is mainly composed of Arch zkVM and Arch verification node network. It uses zero-knowledge proof (zk-proofs) and decentralized verification network to ensure the security and privacy of smart contracts. It is easier to use than RGB and does not require another UTXO chain for binding like RGB++.

Arch zkVM uses RISC Zero ZKVM to execute smart contracts and generate zero-knowledge proofs, which are verified by a decentralized network of validating nodes. The system runs on a UTXO model, encapsulating smart contract states in State UTXOs to improve security and efficiency.

Asset UTXOs are used to represent Bitcoin or other tokens and can be managed by delegation. The Arch validation network verifies ZKVM content through randomly selected leader nodes, aggregates node signatures using the FROST signature scheme, and finally broadcasts transactions to the Bitcoin network.

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

Arch also uses Bitcoin's UTXO model, where state and assets are encapsulated in UTXO, and state transitions are performed through the concept of single use. The state data of the smart contract is recorded as state UTXO, and the original data assets are recorded as asset UTXO. Arch ensures that each UTXO can only be spent once, thereby providing secure state management.

Although Arch does not innovate the blockchain structure, it also requires a network of validator nodes. During each Arch Epoch, the system randomly selects a Leader node based on the stake, and the Leader node is responsible for propagating the received information to all other validator nodes within the network. All zk-proofs are verified by a decentralized network of validator nodes to ensure the security and censorship resistance of the system, and generate 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 have their own characteristics, but all continue the idea of ​​binding UTXO. The one-time authentication property of UTXO is more suitable for smart contracts to record status.

However, its disadvantages are also very obvious, namely poor user experience, confirmation delays and low performance consistent with BTC, that is, only expanding functions but not improving performance, which is more obvious in Arch and RGB; and although the design of RGB++ provides a better user experience by introducing a higher-performance UTXO chain, it also proposes additional security assumptions.

As more developers join the BTC community, we will see more expansion plans, such as op_cat's upgrade proposal, which is also under active discussion. Solutions that fit the native properties of BTC need to be focused on. The UTXO binding method is the most effective way to expand BTC programming without upgrading the BTC network. As long as the user experience problem can be solved, it will be a huge improvement for BTC smart contracts.