A Brief Analysis of AVM White Paper: A Turing Complete Virtual Machine Enabling BTC to Achieve Dynamic "State Machine"?

How to understand the latest AVM Virtual Machine White Paper released by @atomicalsxyz? Simply put, it is a way to simulate the Bitcoin Virtual Machine, enabling the originally “stateless” Bitcoin Mainnet to have the ability to support a smart contract system, thus allowing for the recording and processing of more complex assets beyond BTC assets, similar to Turing Complete smart contracts. Next, I will share my understanding:

Bitcoin was originally designed as a peer-to-peer electronic cash system with some script data storage capabilities, as well as some basic OP 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 transferring BTC assets. Due to the limited UTXO model and predefined state transition rules, this stateless model can only handle limited management of individual BTC assets.

If you try to add assets on the Bitcoin network, such as BRC20, ARC20, Runes, etc., you need a more complex dynamic “state machine” model to record the storage, transactions, state changes, etc., of these assets. How to achieve this?

One way is to use external protocols and layer2 solutions to build an “off-chain” state machine model for scalability, such as the excellent layer2 scaling solutions like @NervosNetwork @RoochNetwork, and even native solutions like RGB, Lighting Network, etc.

Another way is to directly extend the functionality of the script to add new operations or storage space to handle the creation and transfer of complex assets, like Covenant and OP_CAT, which depend on BIP proposal standards being adopted;

The above two methods are either too “active” and difficult to reach consensus in a short period of time, or too “passive” and have a great deal of uncertainty. AVM virtual machine provides a special solution that is between the two, directly building 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 is actually the instruction set of Bitcoin, which achieves the property of being Turing Complete through a dual-stack PDA (Pushdown Automaton).

2. Sandbox runtime environment, the entire simulator is in a controlled and isolated environment, so that the execution inside the sandbox and outside are not interfered with each other;

3. State hash allows participants to verify whether their indexer’s state is correctly synchronized, preventing potential attacks from inconsistent states.

Understand simply: AVM directly utilizes the limited storage space of current BTC and the OP Codes processing framework. It introduces a special encoding and decoding method (sandbox environment) in each BTC mainnet transaction.

This sandbox comes with an indexer, a sandbox parser (instruction set), a global database, etc., which can independently complete a set of asset storage, transaction status recording, and other management. It is equivalent to embedding a dynamic “state machine” in the BTC mainnet, enabling complex smart contract processing, state synchronization, and verification.

3. With the AVM virtual machine, theoretically, the Bitcoin mainnet can have basic smart contract operation capabilities, enabling Bitcoin to manage complex assets and complex state logic DApp landing, which is equivalent to giving the Bitcoin network a certain self-constructing ecological function.

This is certainly a great step forward, at least on par with RGB, Lighting Network, and various excellent second-layer protocol processing solutions in terms of BTC expansion innovation. It even outperforms other solutions in the aspect of Native.

However, AVM relies on BTC script for encoding and storage, as well as OP Codes for transaction execution, so it is overall limited by the performance of BTC’s mainnet, such as block storage space and block speed.

Imagine a DeFi project built on AVM, which can only process 7 transactions per minute and requires a ten-minute wait between two state transitions. Even if the smart contract is theoretically complete, it is still constrained. Furthermore, developing complex contract functionalities relying on the Bitcoin script instruction set is more complex and challenging than developing smart contracts in languages like Ethereum Solidity.

Moreover, the White Paper of AVM only clarified a built-in virtual machine execution method that makes sense. The actual deployment and operation in the application environment are still unknown.

Above

Overall, I tend to see the development of AVM as a beneficial proactive exploration based on BTC Mainnet script extension. It can indeed drive the landing of some simplified smart contracts on the BTC Mainnet, while also enabling Bitcoin Mainnet to play a greater role and value in the construction of second-layer ecosystem and the combined on-chain and off-chain ecosystem such as BitVM.

However, like other BTC extension solutions, AVM also has its advantages and disadvantages. Its legitimacy and attractiveness need to be expanded based on the ecological construction after landing. It is recommended to maintain a rational, cautious, and optimistic attitude.