How to understand the latest AVM virtual machine whitepaper released by @atomicalsxyz? Simply put, it is a way to simulate a Bitcoin virtual machine, allowing the originally “stateless” Bitcoin mainnet to have the ability to support smart contract systems, thereby enabling the recording and processing of more complex assets beyond BTC, similar to a Turing-complete smart contract. Let me share my understanding:
1) Bitcoin was originally designed as a peer-to-peer electronic cash system with some Script script data storage capabilities, basic OP Codes operation codes, and a set of asset validation logic based on UTXO time locks and spending conditions. Therefore, the Bitcoin network can manage assets in a “stateless” manner when recording and transferring BTC assets. Due to the minimalist UTXO model and predefined state transition rules, this stateless model can only handle limited management of BTC single assets. If we want to add assets to the Bitcoin network, such as BRC20, ARC20, Runes, etc., we need a more complex dynamic “state machine” model to record the storage, transactions, and state changes of these assets. How can we achieve this?
One way is to use external protocols and layer 2 solutions to build an “state machine” model off-chain, like excellent layer 2 extension solutions such as @NervosNetwork and @RoochNetwork, or even Native solutions like RGB and Lightning Network. Another way is to directly extend the functionality of the Script script by adding new operation codes or storage space to handle the creation and transfer of complex assets, such as the Covenant and OP_CAT proposals that rely on BIP standards. Either of these two ways is either too “active” and difficult to achieve consensus in a short period of time, or too “passive” and uncertain. The AVM virtual machine provides a special solution that falls between the two, directly building a virtual machine execution environment on the Bitcoin mainnet.
2) How does it work? The main principles of AVM include three parts:
1) Bitcoin script simulation, which is essentially the Bitcoin instruction set, achieves Turing completeness through a dual-stack PDA (pushdown automaton).
2) Sandbox runtime environment, where the entire simulation machine operates in a controlled isolation environment, ensuring that the execution inside the sandbox does not interfere with the outside execution.
3) State hash, which allows participants to verify whether the state of their indexer is correctly synchronized, preventing potential attacks caused by inconsistent states.
In simple terms, AVM directly utilizes the limited storage space and OP Codes processing framework of current BTC, by introducing a special encoding and decoding method (sandbox environment) in every BTC mainnet transaction. This sandbox comes with an indexer, sandbox parser (instruction set), global database, etc., and can independently handle the storage, transaction, and state recording of a complete set of assets. It is equivalent to embedding a dynamic “state machine” in the BTC mainnet, thus enabling complex smart contract processing, as well as state synchronization and verification.
3) With AVM, the Bitcoin mainnet theoretically gains basic smart contract capabilities, enabling it to manage multiple complex assets and complex state logic, and making it possible for DApps to be built on the Bitcoin network. This can be considered a great progress, at least on par with BTC extension capabilities of the same level as RGB, Lightning Network, and various excellent layer 2 protocol solutions. It may even surpass other solutions in terms of Native capabilities.
However, AVM relies on Bitcoin Script for encoding and storage, and depends on OP Codes for transaction execution. Therefore, it is limited by the performance of the BTC mainnet as a whole, such as block storage space size and transaction speed. Imagine a DeFi project built on AVM that can only process 7 transactions per minute, with a ten-minute wait between two state transitions. Even if the smart contract is theoretically complete, it is still restricted. Moreover, developing complex contract functionality using Bitcoin Script instruction set is more complex and challenging than developing smart contracts using languages like Ethereum Solidity.
Furthermore, the AVM whitepaper only clarifies one way of implementing a Make Sense built-in virtual machine execution method. The actual deployment and stable operation in the application environment are still unknown.
In conclusion, I tend to view the development and implementation of AVM as a beneficial exploration based on the extension of BTC mainnet Script. It can indeed drive the landing of some simplified smart contracts on the BTC mainnet, and also allow the Bitcoin mainnet to play a larger role and value in the second-layer ecosystem construction and the combination of on-chain and off-chain ecosystems such as BitVM. However, like other BTC extension solutions, AVM also has its advantages and disadvantages, and it needs to rely on the ecological construction after deployment to enhance its “orthodoxy” and attractiveness. It is recommended to maintain a rational, cautious, and optimistic attitude.
