Explaining BTC Smart Contract Solutions RGB, RGB++ and Arch Network

Author: Trustless Labs; Original link:

BTC is currently the blockchain with the best Liquidity and the highest security. After the inscription outbreak, the BTC ecosystem has attracted a large number of developers to join, and they quickly followed the programmability issues and scaling problem of BTC. By introducing different ideas, such as ZK, DA, sidechain, rollup, restaking, and other solutions, 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 scalability experience of Smart Contracts like ETH, and they must rely on a centralized cross-chain bridges, which is a weakness of the system. There are few solutions 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:

1. BTC's scripting language limits Turing completeness for security reasons, which means it cannot execute Smart Contracts like Ethereum.
2. At the same time, the storage of the BTC blockchain is designed for simple transactions and is not optimized for complex Smart Contracts.
3. The most important thing is BTC does not have a Virtual Machine to run Smart Contract.

The introduction of SegWit (Segregated Witness) 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 (unlocking atomic swaps, multi-signature wallet, and conditional payments). All of this makes programmability on BTC possible.

In 2022, developer Casey Rodarmor proposed his "Ordinal Theory," outlining Satoshi's numbering scheme, which could put arbitrary data such as images into BTC transactions, opening up new possibilities for embedding state information and metadata on-chain, and creating a new path for applications like Smart Contracts that require accessible and verifiable state data.

Currently, most projects that extend BTC programming rely on BTC's layer 2 network (L2), which makes it a major challenge for users to trust cross-chain bridges and become L2 to obtain users and Liquidity. In addition, BTC 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 are all attempting to enhance the programmability of BTC from its native attributes, and provide the ability for Smart Contracts and complex transactions through different methods:

1. RGB is a Smart Contract scheme verified 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 the composability of contracts, so its development is currently very slow.
2. RGB++ is another extension route based on the RGB approach. It still relies on UTXO binding, but by using the chain itself as a client validator with Consensus, it provides a solution for Metadata asset Cross-Chain Interaction, allowing the transfer of any UTXO-based chain.
3. Arch Network provides a native Smart Contract solution for BTC, creating a ZK Virtual Machine and corresponding validators Node network, and recording state changes and asset stages in BTC transactions through aggregated transactions.

RGB

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

RGB adopts the off-chain verification method, which moves the validation of Token transfer from the BTC consensus layer to off-chain, and is verified by specific transaction-related clients. This method reduces the need for network-wide broadcasting, enhances privacy, and efficiency. However, this privacy enhancement method is also a double-edged sword. By only allowing Node 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 complex and difficult to develop, resulting in a poor user experience.

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

RGB++

RGB++ is another extension route based on the RGB concept, 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 an off-chain shadow chain, RGB++ can handle off-chain data and smart contracts. This chain can not only execute complex smart contracts, but also bind with BTC's UTXO, thereby increasing the programmability and flexibility of the system. In addition, the UTXOs of BTC and the shadow chain are isomorphically bound, ensuring consistency of state and assets between the two chains, thus ensuring the security of transactions.

In addition, RGB++ can be extended to all Turing Complete UTXO chains, not just limited to CKB, thus improving Cross-Chain Interaction interoperability and asset Liquidity. This multi-chain support allows RGB++ to combine with any Turing Complete UTXO chain, enhancing the flexibility of the system. At the same time, RGB++ achieves bridgeless Cross-Chain Interaction through UTXO isomorphic binding. Unlike traditional Cross-Chain Interaction bridges, this method avoids the problem of 'false coins' and ensures the authenticity and consistency of assets.

By performing on-chain validation through the shadow chain, RGB++ simplifies the client validation process. Users only need to check the relevant transactions on the shadow on-chain to verify whether the state calculation of RGB++ is correct. This on-chain validation 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.

Recommended reading: RGB++ Layer: Opening a New Era for the BTC Ecosystem

Arch Network

The Arch Network is mainly composed of the Arch zkVM and Arch Verification Node network. It utilizes Zero-Knowledge Proofs (zk-proofs) and Decentralization to ensure the security and privacy of Smart Contracts. It is more user-friendly than RGB and does not require binding with another UTXO chain like RGB++ does.

Arch zkVM uses RISC Zero ZKVM to execute Smart Contracts and generate Zero-Knowledge Proofs, which are verified by a decentralized network of validation Nodes. The system operates on a UTXO model, encapsulating the Smart Contract state in a State UTXO to improve security and efficiency.

Asset UTXO is used to represent BTC or other Tokens, and can be managed through delegation. The Arch verification network verifies the ZKVM content through a randomly selected leader Node, and aggregates Node signatures using the FROST signature scheme, finally broadcasting the Transaction to the BTC network.

ARCH zkVM provides a Turing Complete Virtual Machine for BTC, capable of executing complex Smart Contracts. After each Smart Contract execution, Arch zkVM will generate Zero-Knowledge Proofs, which are used to verify the correctness and state changes of the contracts.

Arch also uses BTC's UTXO model, where the state and assets are encapsulated in UTXOs and state transitions are performed through the concept of single-use. The state data of smart contracts is recorded as state UTXOs, and the original data assets are recorded as Asset UTXOs. Arch ensures that each UTXO can only be spent once, 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 equity, and the Leader Node is responsible for propagating the received information to all other validators Nodes in the network. All zk-proofs are verified by the validators 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 broadcasted on the BTC network.

Conclusion

In terms of BTC programmability design, RGB, RGB++, and Arch Network each have their own characteristics, but they all continue the approach of binding UTXO, and the singularity of UTXO is more suitable for Smart Contract to record state.

But its disadvantages are also very obvious, that is, a bad user experience, consistent confirmation latency and low performance with BTC, that is, only the function is extended, but the performance is not improved, 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.

As more developers join the BTC community, we will see more scaling solutions, such as the upgrade proposal for op_cat, which is actively being discussed. It is important to follow solutions that are in line with the native properties of BTC. The UTXO binding method is the most effective way to expand BTC programming without upgrading the BTC network. As long as it can solve the user experience problem, it will be a huge progress for BTC Smart Contracts.