introduce

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 reaching a new high, and it has become the main plot of this round of bull market.

However, many of these designs follow the scaling experience of smart contracts such as ETH and must rely on a centralized cross-chain bridge, which is a weak point of the system. Few solutions are designed based on the characteristics of BTC itself, which is related to the fact that BTC itself is not developer-friendly. There are a number of reasons why it cannot run smart contracts like Ethereum:

  • Bitcoin's scripting language limits Turing completeness for security reasons, which makes it impossible to execute smart contracts like Ethereum.

  • At the same time, the storage of the Bitcoin blockchain is designed for simple transactions and is not optimized for complex smart contracts.

  • The most important thing is that 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 enabled batch signature verification, making it easier and faster to process transactions (unlocking atomic swaps, multi-signature wallets, and conditional payments). This makes programmability possible on Bitcoin.

In 2022, developer Casey Rodarmor proposed his "Ordinal Theory", outlining a Satoshi numbering scheme that allows arbitrary data such as images to be placed into Bitcoin transactions, opening up new possibilities for embedding state information and metadata directly on the Bitcoin chain, which opens up a new way of thinking 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 achieve communication between L2 and L1 without additional trust assumptions.

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

  • RGB is a smart contract solution verified by off-chain clients. 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. Currently, its development is very slow.

  • RGB++ is another extension route of Nervos based on the idea of ​​RGB. 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.

  • 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.

Arch Network

Arch Network is mainly composed of Arch zkVM and Arch verification node network. It uses zero-knowledge proofs (zk-proofs) and decentralized verification networks 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 validator nodes. The system runs on the 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 through delegation. The Arch verification network verifies the ZKVM content through a randomly selected leader node, aggregates node signatures using the FROST signature scheme, and finally broadcasts the transaction to the Bitcoin network.

Arch zkVM provides a Turing-complete virtual machine for Bitcoin that can execute complex smart contracts. After each smart contract is executed, 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, where states 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, 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 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 a signature for the Leader node. Once a transaction is signed by the required number of nodes, it can be broadcast on the Bitcoin network.

RGB

RGB is an early smart contract expansion idea of ​​the BTC community. It records status 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 Bitcoin's consensus layer to off-chain, and verifying it by the client related to the specific transaction. This method reduces the need for full network broadcasting, enhances privacy and efficiency. However, this privacy enhancement method is also a double-edged sword. Although privacy protection is enhanced by only allowing nodes related to specific transactions to participate in the verification work, it also makes it invisible to third parties, 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 through UTXO and managed through the seal, 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++ leverages 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 a Turing-complete UTXO chain. By using a Turing-complete UTXO chain like CKB as a 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 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 status and assets between the two chains, thereby ensuring the security of transactions.

In addition, RGB++ not only extends to all Turing-complete UTXO chains, but is 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. Unlike traditional cross-chain bridges, this method avoids the "fake currency" problem and ensures the authenticity and consistency of assets.

By performing 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 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 chains, RGB++ avoids RGB's complex UTXO management and provides a more simplified and user-friendly experience.

in conclusion

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

But its disadvantages are also very obvious, namely poor user experience, confirmation delays and low performance consistent with BTC, that is, only the functions are expanded but the performance is not improved, 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 puts forward additional security assumptions.

As more developers join the BTC community, we will see more expansion plans, such as the op-cat upgrade proposal, which is also under active discussion. The plan that fits the native properties of BTC needs 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.