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 safest blockchain. After the inscription exploded, the BTC ecosystem attracted a large number of developers to influx, and they quickly paid attention to the programmability and expansion of BTC. By introducing different ideas, such as ZK, DA, side chain, rollup, restacing and other solutions, the prosperity of the BTC ecosystem is ushering in a new high, which has become the main plot of this bull market.

However, many of these designs continue to expand the capacity of smart contracts such as ETH and must rely on a centralized cross-chain bridge, which is the weak point of the system. There are few solutions designed based on the characteristics of BTC itself, which is related to the fact that the developer experience of BTC itself is not friendly. For some reasons it cannot 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 does not optimize complex smart contracts.

3. The most important thing is that Bitcoin does not have a virtual machine to run smart contracts.

The introduction of SegWit in 2017 has added block size limits for Bitcoin; the 2021 Taproot upgrade makes batch signature verification possible, making transactions easier and faster (unlocking atomic exchanges, multi-signature wallets and conditional payments). This makes programmability on Bitcoin possible.

In 2022, developer Casey Rodarmor proposed his "Ordinal Theory", which outlined Sora's numbering scheme, which can put any data such as images into Bitcoin transactions, opening up new possibilities for directly embedding state information and metadata on the Bitcoin chain, which opens up a new idea for applications such as smart contracts that require accessible and verifiable state data.

Currently, most projects that expand Bitcoin programming rely on Bitcoin’s Layer 2 network (L2), which makes users have to trust cross-chain bridges, which is a major challenge for L2 to acquire users and liquidity. Furthermore, Bitcoin currently lacks native virtual machines or programmability and cannot communicate between L2 and L1 without the need for additional trust assumptions.

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

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

2. RGB++ is another expansion route under the RGB idea, which is still based on UTXO binding, but by using the chain itself as a consensus client verifier, this provides a cross-chain solution for metadata assets and allows it to support the transfer of arbitrary UTXO structural chains.

3. Arch Network provides BTC with a native smart contract solution, creating a ZK virtual machine and corresponding validator node network, and records state changes and asset phases in BTC transactions through aggregation transactions.

RGB

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

RGB uses off-chain verification method to move the verification of token transfer from Bitcoin’s consensus layer to off-chain, and is verified by clients related to specific transactions. This method reduces the demand for broadcasting across the network 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.

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

RGB++

RGB++ is another expansion route under the RGB idea, and is still based on UTXO binding.

RGB++ uses Turing 's complete UTXO chain (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 of BTC.

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

In addition, RGB++ can also 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 system flexibility. At the same time, RGB++ realizes bridgeless cross-chain through UTXO isomorphic binding. Unlike traditional cross-chain bridges, this method avoids the problem of "counterfeit currency" and ensures the authenticity and consistency of assets.

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

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

Arch Network

Arch Network is mainly composed of Arch zkVM and Arch verification node networks. It uses zero-knowledge proofs (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 verification nodes. The system runs based on the UTXO model and encapsulates the smart contract state in State UTXO for improved security and efficiency.

Asset UTXO is used to represent Bitcoin or other tokens and can be managed through delegated means. The Arch verification network verifies the ZKVM content through the randomly selected leader node and aggregates the node signature using the FROST signature scheme, and ultimately broadcasts the transaction to the Bitcoin network.

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

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

Although Arch does not have an innovative blockchain structure, it also requires a network of verification 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 in the network. All zk-proofs are verified by a decentralized network of verification nodes to ensure the security and censorship resistance of the system, and generate signatures to the Leader nodes. Once the transaction is signed by the required number of nodes, it can be broadcast on the Bitcoin network.

in conclusion

In terms of BTC programmability design, RGB, RGB++ and Arch Network each have their own characteristics, but they all continue the idea of ​​binding UTXO. The only one-use authentication attribute of UTXO is more suitable for smart contracts to record states.

But its disadvantages are also very obvious, namely, poor user experience, confirmation latency and low performance consistent with BTC, that is, only functions are extended but no performance is improved, which is more obvious in Arch and RGB; while RGB++'s design provides a better user experience by introducing higher performance UTXO chains, it also proposes additional security assumptions.

As more developers join the BTC community, we will see more expansion solutions, such as the upgrade proposal of op_cat, which is also under active discussion. Solutions that fit the native BTC attributes need to be paid attention to. 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 problem can be solved well, it will be a huge improvement in BTC smart contracts.