Understanding AVM: Turing-complete virtual machine that enables BTC to implement dynamic “state machine”

Source: Chain View

How to understand the latest AVM virtual machine white paper released by @atomicalsxyz? In simple terms: it is a way to simulate the Bitcoin virtual machine, so that the originally "stateless" Bitcoin main network can realize the ability to carry a smart contract system, and then complete the state recording and processing capabilities of more complex assets other than BTC assets, similar to Turing complete smart contracts. Next, share my understanding:

1) Bitcoin was originally designed as a peer-to-peer electronic cash system with a certain Script script data storage capacity, some basic OP Codes operation codes, and a set of asset verification logic based on UTXO time locks and spending conditions.

Therefore, the Bitcoin network can achieve "stateless" asset management when recording and transmitting BTC assets. Due to the limitations of the UTXO minimalist model and predefined state conversion rules, this stateless model can only handle limited management of a single BTC asset.

If you try to add new assets to the Bitcoin network, such as BRC20, ARC20, Runes and other assets, you need a more complex dynamic "state machine" model to record the storage, transactions, state changes, etc. of these assets. How to achieve it?

One ​​way is to use external protocols and layer2 second-layer solutions to build a "state machine" model off-chain to extend the processing. Current excellent second-layer extension solutions such as @NervosNetwork   @RoochNetwork  , and even Native solutions such as RGB and Lightning Network belong to this category;

Another way is to directly expand the function of the Script script to add new operations or storage space to handle the creation and transfer of complex assets. Solutions such as Covenant and OP_CAT that rely on BIP proposal standards to be passed belong to this category;

The above two methods are either too "active" and it is difficult to reach consensus in a short period of time, or too "passive" and there is great uncertainty. The AVM virtual machine provides a special processing solution that is between the two and directly builds a virtual machine execution environment on the Bitcoin mainnet.

2) How to do it? The main working principle of AVM includes three parts:

1. Bitcoin script simulation, which is actually the Bitcoin instruction set, realizes Turing complete properties through a dual-stack PDA (Pressable Storage Automaton);

2. Sandbox operating environment, the entire simulator is in a controlled isolation environment, so that the execution in the sandbox and the execution outside do not interfere with each other;

3. State hashing allows participants to verify whether the state of their indexer is correctly synchronized, preventing potential attacks due to inconsistent states.

Simple understanding: AVM directly uses the current limited storage space of BTC and the OP Codes processing framework, and introduces a special encoding and decoding method (sandbox environment) in each BTC mainnet transaction.

This sandbox comes with an indexer, sandbox parser (instruction set), global database, etc., which can independently complete the storage of a whole set of assets, transaction status records and other management, which is equivalent to a dynamic "state machine" built into the BTC main network, and then it can realize complex smart contract processing and state synchronization and verification.

3) With the AVM virtual machine, the Bitcoin main network can theoretically have basic smart contract operation functions, allowing Bitcoin to manage multiple complex assets and the possibility of landing complex state logic DApps, which is equivalent to giving the Bitcoin network a certain self-built ecological function.

This is certainly a great progress, at least the same level of BTC expansion capability innovation as RGB, Lightning Network and various excellent second-layer protocol processing solutions. It is even better than other solutions in Native.

However, AVM relies on Bitcoin Script scripts for encoding storage and OP Codes for transaction execution, so it is generally limited by the performance of BTC's main network, such as: block storage space size, fast speed, etc.

Imagine that a DeFi project built on AVM can only process 7 transactions per minute, and it takes ten minutes to wait between two state transitions. Even if such a smart contract is theoretically complete, it is still bound by its hands and feet. Moreover, relying on the Bitcoin Script script instruction set to develop complex contract functions is more complicated and difficult than developing smart contracts in languages ​​such as Ethereum Solidity.

Moreover, the AVM white paper only clarifies a built-in virtual machine execution method of Make Sense. How it will actually be deployed and launched to the application environment and how it will run stably are still unknowns.

Overall, I tend to regard the development and implementation of AVM as a beneficial and proactive exploration based on the extension of the BTC mainnet Script script, which can indeed drive some simpler smart contracts to land on the BTC mainnet, and at the same time, the Bitcoin mainnet can play a greater role and value in the construction of the second-layer ecosystem and the on-chain and off-chain combined ecosystems such as BitVM.

However, like other types of BTC expansion solutions, AVM also has advantages and disadvantages, and it also depends on the ecological construction after landing to expand its "orthodoxy" appeal. It is recommended to maintain a rational, cautious and optimistic attitude.