Author: Trustless Labs; Original article link: https://www.chaincatcher.com/article/2137941
Bitcoin is currently the most liquid and secure blockchain. After the explosion of Ethereum, a large number of developers flocked to the BTC ecosystem, quickly focusing on the programmability and scalability issues of BTC. By introducing different approaches such as ZK, DA, sidechains, rollups, and restaking, the prosperity of the BTC ecosystem is reaching new heights, making it the main storyline of this bull market.
However, in these designs, many of them continue the scalability experience of smart contracts like ETH and 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 unfriendly developer experience of BTC itself. Due to some reasons, it cannot run smart contracts like Ethereum:
- Bitcoin's scripting language limits Turing completeness for security reasons, making it unable 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.
- Most importantly, Bitcoin does not have a virtual machine to run smart contracts.
The introduction of SegWit in 2017 increased the block size limit of Bitcoin; the Taproot upgrade in 2021 made batch signature verification possible, making it easier and faster to process transactions (unlock 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 allows arbitrary data such as images to be placed in Bitcoin transactions, opening up new possibilities for embedding state information and metadata directly on the Bitcoin chain. This opens up a new approach 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 layer 2 networks (L2), which require users to trust cross-chain bridges, posing a major challenge for L2 adoption and liquidity. In addition, Bitcoin currently lacks a native virtual machine or programmability, making it difficult to achieve communication between L2 and L1 without additional trust assumptions.
RGB, RGB++, and Arch Network all attempt to enhance Bitcoin's programmability based on its native properties, providing capabilities for smart contracts and complex transactions through different methods:
- RGB is an off-chain client-validated smart contract solution, where the state changes of smart contracts are recorded in Bitcoin's UTXOs. Although it has certain privacy advantages, it is cumbersome to use and lacks contract composability, resulting in slow development progress.
- RGB++ is another extension route based on the RGB approach, still based on UTXO binding, but by treating the chain itself as a consensus client validator, it provides a solution for cross-chain metadata assets and allows support for the transfer of UTXO structures on any chain.
- Arch Network provides a native smart contract solution for BTC, creating a ZK virtual machine and a corresponding network of validator nodes, recording state changes and asset phases in BTC transactions through aggregated transactions.
RGB#
RGB is an early smart contract extension approach in the BTC community, which provides important ideas for subsequent native BTC scalability.
RGB adopts off-chain validation, moving the validation of token transfers from the Bitcoin consensus layer to off-chain, where it is validated by specific transaction-related clients. This reduces the need for network-wide broadcasting, enhancing privacy and efficiency. However, this privacy enhancement is a double-edged sword. By only allowing nodes related to specific transactions to participate in the validation work, it enhances privacy protection but also makes it difficult for third parties to see, resulting in a complex and challenging development process and poor user experience.
Additionally, RGB introduces the concept of single-use seals. Each UTXO can only be spent once, acting as a lock when creating the UTXO and unlocking when spending it. The state of the smart contract is encapsulated through UTXO and managed through seals, providing an effective mechanism for state management.
RGB++#
RGB++ is another extension route based on the RGB approach, still based on UTXO binding.
RGB++ utilizes a Turing-complete UTXO chain (such as CKB or other chains) to handle off-chain data and smart contracts, further enhancing Bitcoin's programmability, and ensures security through isomorphic binding with BTC.
RGB++ adopts a Turing-complete UTXO chain. 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 also bind with Bitcoin's UTXOs, increasing the programmability and flexibility of the system. Additionally, Bitcoin's UTXOs and the shadow chain's UTXOs are isomorphically bound, ensuring consistency of state and assets between the two chains, thus ensuring transaction security.
Furthermore, RGB++ can be extended to any Turing-complete UTXO chain, not limited to CKB, improving cross-chain interoperability and asset liquidity. This multi-chain support allows RGB++ to combine with any Turing-complete UTXO chain, enhancing system flexibility. Moreover, RGB++ achieves bridgeless cross-chain communication through UTXO isomorphic binding, which is different from traditional cross-chain bridges and avoids the "fake coin" problem, ensuring 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 relevant transactions on the shadow chain to verify the correctness of RGB++ state computation. This on-chain validation method not only simplifies the verification process but also optimizes the user experience. With 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 Bitcoin Ecosystem
Arch Network#
Arch Network consists of Arch zkVM and the Arch validation node network, utilizing zero-knowledge proofs (zk-proofs) and a decentralized validation network 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++.
Arch zkVM executes smart contracts using the RISC Zero ZKVM and generates zero-knowledge proofs, which are then validated by a decentralized network of validator nodes. The system operates based on the UTXO model, encapsulating the state of smart contracts 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 validation network verifies the content of the ZKVM by randomly selecting a leader node and aggregates node signatures using the FROST signature scheme, broadcasting the transaction to the Bitcoin network once the required number of signatures is obtained.
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 the Bitcoin UTXO model, where the state and assets are encapsulated in UTXOs and state transitions are performed through the concept of single-use seals. The state data of smart contracts is recorded as state UTXOs, while the original asset data is 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, a leader node is randomly selected based on stake, and the leader node is responsible for propagating the received information to all other validator nodes in the network. All zk-proofs are validated by a decentralized network of validator nodes, ensuring system security and censorship resistance, and generating signatures for the leader node. Once the transaction is signed by the required number of nodes, it can be broadcasted on the Bitcoin network.
Conclusion#
In terms of BTC programmability design, RGB, RGB++, and Arch Network each have their own characteristics, but they all continue the UTXO binding approach, which is more suitable for smart contracts to record state with the UTXO's one-time use authorization property.
However, their disadvantages are also evident, including poor user experience, consistent confirmation latency and low performance with BTC, i.e., they only extend functionality without improving performance, which is more evident in Arch and RGB. Although RGB++ design provides a better user experience by introducing a higher-performance UTXO chain, it also introduces additional security assumptions.
As more developers join the BTC community, we will see more scalability solutions, and upgrade proposals such as op_cat are actively being discussed. Solutions that cater to BTC's native properties need to be given special attention, and the UTXO binding method is the most effective way to extend BTC's programming capabilities without upgrading the BTC network. As long as the user experience issues can be resolved, it will be a significant advancement for BTC smart contracts.