On-chain and off-chain expansion: The future of Bitcoin programmability

Author: jolestar, founder of Rooch Network Source: X, @jolestar

Bitcoin’s programmability expansion solutions can be divided into two major directions: on-chain expansion and off-chain expansion.

Bitcoin on-chain extensions

This direction has always been limited by the programming nature of Bitcoin scripts.Solutions like Bitvm try to simulate circuits through the Taproot tree to achieve Turing complete computing.But the bigger limitation of Bitcoin L1 is that Bitcoin scripts are stateless.No matter how complex the calculation is, ownership of the state can only be expressed as a time lock, hash lock, or private key lock, and “state lock” cannot be expressed, which is the prerequisite for implementing complex applications.

Suppose that Bitcoin’s script is replaced with a Turing-complete virtual machine, and other conditions remain unchanged, please design a counter. Any user sends a transaction to add it to one, and you will understand this limitation.

What’s 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 where the inscription is scrapped.

Use a common metaphor to explain “state lock”: If a Bitcoin script is understood as a smart lock for UTXO, this smart lock can be unlocked with a password and unlocked with a fingerprint, but it cannot record the result after the script is executed internally, so it cannotImplement the function of unlocking after several times.

Therefore, if the on-chain expansion can design arbitration and challenge mechanisms in conjunction with one-time signatures, it will be very breakthrough.

Bitcoin Off-chain Extension

Since there are bottlenecks in on-chain expansion, you can only seek out-of-chain expansion.In order to avoid the ambiguity of on-chain/off-chain, it is collectively called off-chain expansion.

Off-chain extensions require a trade-off between several options:

1. What smart contracts and virtual machines are used?

2. How to read and write states (data and assets) on Bitcoin in a smart contract.

3. Where to write transactions and how to ensure usability.

For example, in the AVM solution:

1. Choose Bitcoin Script.

2. Implementation by adding a new OP code.

3. Transaction written back to Bitcoin L1.

The EVM sidechain solution is generally:

1. Use EVM.

2. Cross assets through bridges.

3. Ensure with an independent consensus network.

The article mentions RoochNetwork, and the detailed introduction of its plan is as follows:

• Smart contracts and virtual machines: Use Move and MoveVM.

• How to read and write status on Bitcoin in smart contracts: Execute all transactions of Bitcoin L1 in L2, and express the status of Bitcoin (UTXO/Inscription, etc.) as a Move Object.

There are several benefits to this:

1. All Bitcoin states (UTXO/Inscription, etc.) can be read in smart contracts, including transactions and block headers.

2. 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.Let me give you a few typical scenarios: the state of L1 expresses the plot, the house is built on L2; the state of L1 expresses the domain name, and the analysis is recorded in L2.

3. By generating Bitcoin Script and Bitcoin transactions in L2’s smart contracts, it provides programmability for transactions.

How to ensure availability

RoochNetwork’s transaction availability relies on third-party DAs.Because in Rooch’s solution, L2 will contain all L1 transactions, so you cannot write back to L1. You only need to write back to 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.

Summarize

Bitcoin ecosystem has been looking forward to programmable expansion solutions for a long time, and has tried various routes and solutions.Bitcoin L1 has limited programmability, but its advantage is that all states are global and there is no separation between contracts.So no matter any extension solution, as long as the solution writes data on Bitcoin, it can be combined with other solutions, complementary advantages, and a different ecosystem will eventually emerge.