Bitcoin’s programmability expansion solutions can be divided into two main directions: on-chain expansion and off-chain expansion.
On-Chain Expansion:
This direction has always been limited by the programmability of Bitcoin scripts. Solutions like Bitvm attempt to simulate circuits using Taproot trees to achieve Turing-complete computation. However, the major limitation of Bitcoin L1 is that Bitcoin scripts are stateless. Regardless of how complex the computation is, ownership of the state can only be expressed through time locks, hash locks, and private key locks. It cannot express a “state lock,” which is a prerequisite for implementing complex applications.
To understand this limitation, let’s suppose that we replace Bitcoin’s scripts with a Turing-complete virtual machine while keeping other conditions unchanged. Now, design a counter that can be incremented by any user sending a transaction. This scenario demonstrates the significance of having a counter. In typical tokenization scenarios, a counter is needed to calculate the total amount of assets. If the counter can be expressed on-chain, the problem of wasted tokenization will be eliminated.
To explain the concept of a “state lock” in simple terms: if we consider Bitcoin scripts as intelligent locks for UTXOs, these locks can be unlocked with a password or fingerprint. However, they cannot record the results of the script execution internally, so they cannot implement a feature where the lock cannot be unlocked again after a certain number of unlocks.
Therefore, if on-chain expansion can be combined with one-time signatures to design arbitration and challenge mechanisms, it would already be a significant breakthrough.
Off-Chain Expansion:
Since on-chain expansion has limitations, we must seek off-chain expansion. To avoid the ambiguity of L2/sidechain, on-chain/off-chain, we refer to it as off-chain expansion.
Off-chain expansion requires making choices among several options:
1. What smart contract and virtual machine to use.
2. How to read and write the state (data and assets) on Bitcoin within the smart contract.
3. Where to write the transactions and how to ensure availability.
For example, in the AVM solution:
– Bitcoin Script is chosen.
– New OP codes are added to achieve the desired functionality.
– Transactions are written back to Bitcoin L1.
On the other hand, EVM sidechain solutions generally involve:
– Using EVM.
– Bridging assets across.
– Ensuring with an independent consensus network.
The article mentions Rooch Network, and its solution is described as follows:
– Smart contract and virtual machine: Move and MoveVM.
– How to read and write the state on Bitcoin within the smart contract: Execute all Bitcoin L1 transactions on L2 and express Bitcoin’s state (UTXO/Inscription, etc.) as Move Objects.
This approach offers several advantages:
– Smart contracts can read all states (UTXO/Inscription, etc.) on Bitcoin, including transactions and block headers.
– L2 states can be bound to Bitcoin’s states through dynamic fields of objects (atomic binding), with ownership belonging to the owners of Bitcoin assets. Examples of typical scenarios include expressing land on L1 and building houses on L2, or expressing domain names on L1 and storing resolution records on L2.
– By generating Bitcoin scripts and transactions in L2 smart contracts, programmability is provided to transactions.
Ensuring Availability:
Rooch Network’s transaction availability relies on third-party DAs (Data Availability). In Rooch’s solution, L2 contains all L1 transactions, so there is no need to write back to L1. Only the root of the L2 state tree needs to be periodically written back to Bitcoin. This also ensures that the transaction costs in L2 are low enough to provide infrastructure for more complex applications.
In conclusion, the Bitcoin ecosystem has long awaited programmability expansion solutions, and there have been various attempts and routes. While Bitcoin L1 has limited programmability, its advantage is that all states are global, and there is no fragmentation between contracts. Therefore, any expansion solution that writes data on Bitcoin can be combined with other solutions, complementing each other and eventually creating a unique ecosystem.