Author: Trustless Labs; Original article 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 focused 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 and has become 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 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.
- 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 the numbering scheme for Satoshis, which 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 network (L2), which requires 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 asset 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 scalability of BTC through UTXO encapsulation.
RGB adopts off-chain validation, moving the validation of token transfers from Bitcoin's 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 a poor user experience.
In addition, 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. In addition, the UTXOs of Bitcoin and the shadow chain are isomorphically bound, ensuring consistency of state and assets between the two chains, thus ensuring the security of transactions.
Furthermore, RGB++ can be extended to any Turing-complete UTXO chain, not limited to CKB, thereby enhancing cross-chain 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 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 the relevant transactions on the shadow chain to verify the correctness of RGB++'s state calculation. This on-chain validation method not only simplifies the validation process but also optimizes the user experience. By using a Turing-complete shadow chain, RGB++ avoids the complex UTXO management of RGB and provides a simplified and user-friendly experience.
Recommended reading: RGB++ Layer: Opening a New Era for the Bitcoin Ecosystem
Arch Network#
Arch Network consists mainly of Arch zkVM and the Arch validation node network, which ensures the security and privacy of smart contracts through zero-knowledge proofs (zk-proofs) and a decentralized validation network. It is more user-friendly than RGB and does not require binding to another UTXO chain like RGB++.
Arch zkVM uses the RISC Zero ZKVM to execute smart contracts and generate zero-knowledge proofs, which are then validated by a decentralized network of validator nodes. The system operates based on the UTXO model, with the smart contract state encapsulated 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 the node signatures using the FROST signature scheme, broadcasting the transaction to the Bitcoin network.
Arch zkVM provides a Turing-complete virtual machine for Bitcoin, capable of executing complex smart contracts. After each smart contract execution, Arch zkVM generates zero-knowledge proofs to verify the correctness and state changes of the contract.
Arch also uses the UTXO model of Bitcoin, with the state and assets encapsulated in UTXOs and state transitions performed through the concept of single-use. The state data of the smart contract 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 the security and censorship resistance of the system 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 using the UTXO's one-time use authorization attribute.
However, their disadvantages are also very obvious, namely 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. While RGB++'s 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 proposals such as op_cat are also actively being discussed. Solutions that are in line with 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 solved, it will be a huge advancement for BTC smart contracts.