How to Understand the Latest AVM Virtual Machine Whitepaper by @atomicalsxyz? In simple terms, it is a way to enable the Bitcoin mainnet, which is originally “stateless,” to support smart contract systems by simulating a Bitcoin virtual machine. This allows for 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 a certain script data storage capability. It also has some basic OP Codes for asset validation 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. However, due to the minimalistic UTXO model and predefined state transition rules, this stateless model can only handle limited management of individual BTC assets. To add new assets, such as BRC 20, ARC 20, Runes, etc., on the Bitcoin network, a more complex dynamic “state machine” model is needed to record the storage, transactions, and state changes of these assets. How can this be achieved?
One way is to use external protocols and layer 2 solutions to build an “off-chain” state machine model for scalability and processing, similar to the excellent layer 2 scaling solutions provided by @NervosNetwork, @RoochNetwork, etc., or even native solutions like RGB and Lightning Network.
Another way is to directly extend the functionality of the Script script by adding new OP Codes or storage space to handle the creation and transfer of complex assets, such as the solutions based on BIP proposals like Covenant and OP_CAT.
Both of these approaches are either too “active” and may be difficult to achieve consensus in a short period of time, or too “passive” and have significant uncertainties. The AVM virtual machine offers a unique solution that falls between these two approaches by directly building a virtual machine execution environment on the Bitcoin mainnet.
2) How does it work? The AVM’s main working principles consist of three parts:
1. Bitcoin script simulation, which is essentially the Bitcoin instruction set, implemented through a double stack PDA (pushdown automaton) to achieve Turing completeness.
2. Sandbox runtime environment, where the entire simulation machine operates in a controlled isolated environment, ensuring that the execution within the sandbox does not interfere with the outside execution.
3. State hash, which allows participants to verify the correctness and synchronization of their indexer’s state, preventing potential attacks resulting from inconsistent states.
In simple terms, the AVM directly utilizes the limited storage space and OP Codes processing framework of BTC by introducing 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., enabling the independent management of a complete set of asset storage, transaction state recording, and other operations. It is equivalent to embedding a dynamic “state machine” within the BTC mainnet, enabling the processing of complex smart contracts, state synchronization, and verification.
3) With the AVM virtual machine, the Bitcoin mainnet can theoretically have basic smart contract capabilities, enabling the management of multiple complex assets and the realization of complex state logic for DApps, essentially giving the Bitcoin network a self-building ecological functionality. This is undoubtedly a great progress, at least on par with BTC extension capabilities like RGB, Lightning Network, and various excellent layer 2 protocol solutions. It may even be superior in terms of native solutions.
However, the AVM relies on Bitcoin script for encoding and storage, as well as OP Codes for transaction execution, so it is overall limited by the performance of the BTC mainnet, 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 constrained. Moreover, developing complex contract functions using Bitcoin script instruction sets is more complex and difficult than using languages like Ethereum’s Solidity.
Furthermore, the AVM whitepaper only clarifies one type of internally built virtual machine execution method that makes sense. The actual deployment and stable operation of AVM in application environments are still unknown.
In conclusion, I consider the development and implementation of AVM as a beneficial proactive exploration based on the Script script extension of the Bitcoin mainnet. It can indeed drive the landing of some simplified smart contracts on the Bitcoin mainnet. At the same time, Bitcoin’s mainnet can play a greater role and value in the second-layer ecosystem construction and the combination of on-chain and off-chain ecosystems like BitVM. However, like other BTC extension solutions, AVM also has its pros and cons, and it will need to rely on the ecosystem construction after deployment to enhance its “legitimacy.” I recommend maintaining a rational, cautious, and optimistic attitude.
