Author: jolestar, founder of Rooch Network Source: X, @jolestar
Bitcoin's programmable expansion scheme can be divided into two major directions: on-chain expansion and off-chain expansion.
Bitcoin on-chain expansion
This direction has always been limited by the programmability of Bitcoin scripts. Solutions such as Bitvm attempt to simulate circuits through Taproot trees to achieve Turing-complete calculations. But the greater limitation of Bitcoin L1 is that Bitcoin scripts are stateless. No matter how complex the calculation is, the ownership of the state can only be expressed as a time lock, hash lock, or private key lock, and it is impossible to express a "state lock", which is the premise for implementing complex applications.
Suppose that the Bitcoin script is replaced with a Turing-complete virtual machine, and other conditions remain unchanged. Please design a counter that can be incremented by one by any user sending a transaction, and then you will understand this limitation.
What is the use of this counter scenario? In a typical inscription scenario, a counter is needed to calculate the total amount of assets. If the counter can be expressed on the chain, there will be no situation of invalid inscriptions.
Use a popular metaphor to explain "state lock": If the Bitcoin script is understood as a smart lock for UTXO, this smart lock can be unlocked by password or fingerprint, but it cannot record the result after the script is executed, so it cannot achieve the function of not being able to unlock again after unlocking several times.
Therefore, if the on-chain extension can be combined with the one-time signature to design an arbitration and challenge mechanism, it will be very groundbreaking.
Bitcoin off-chain extension
Since there is a bottleneck in on-chain extension, we can only seek off-chain extension. In order to avoid the ambiguity of L2/side chain, on-chain/off-chain, they are collectively referred to as off-chain extensions.
Off-chain expansion requires a choice between several options:
Which smart contract and virtual machine to use.
How to read and write the state (data and assets) on Bitcoin in the smart contract.
Where to write the transaction, how to ensure availability.
For example, in the AVM solution:
Choose Bitcoin Script.
Achieve it by adding a new OP code.
The transaction is written back to Bitcoin L1.
The EVM sidechain solution is generally:
Use EVM.
Span assets through bridges.
Guaranteed by an independent consensus network.
The article mentions RoochNetwork, and introduces its solution in detail as follows:
Smart contracts and virtual machines: Use Move and MoveVM.
How to read and write the state on Bitcoin in a smart contract: Execute all transactions of Bitcoin L1 in L2, and express the state of Bitcoin (UTXO/Inscription, etc.) as Move Object.
This has several advantages:
The smart contract can read all the states on Bitcoin (UTXO/Inscription, etc.), including transactions and block headers.
The state of L2 can be bound to the state of Bitcoin through the dynamic field of Object (atomic binding), and the ownership belongs to the owner of the Bitcoin asset. Here are some typical scenarios: the state of L1 expresses the plot of land, and the house is built on L2; the state of L1 expresses the domain name, and the resolution record is in L2.
By generating Bitcoin Script and Bitcoin transactions in the smart contract of L2, programmability is provided for transactions.
How to ensure availability
RoochNetwork's transaction availability depends on a third-party DA. Because in Rooch's solution, L2 will contain all L1 transactions, so it can no longer be written back to L1. It only needs to write the root of the L2 state tree back to Bitcoin regularly. This also ensures that the transaction cost of L2 is low enough to provide infrastructure for more complex applications.
Summary
The Bitcoin ecosystem has been looking forward to programmable expansion solutions for a long time, and various routes and solutions have been tried. Bitcoin L1 has limited programmability, but its advantage is that all states are global and there is no separation between contracts. Therefore, no matter what expansion plan, as long as the plan writes data on Bitcoin, it can be combined with other plans, complementing each other's advantages, and eventually a different ecosystem will emerge.
Huang Bo
Edmund
JinseFinance
Alex
Bitcoinist
Cointelegraph