Author: DaPangDun @DaPangDunCrypto
Please note: This article is written based on personal cognition and logical reasoning, and is not necessarily correct. It is for reference only.
To understand AVM, the key is the following three pictures, let's analyze them one by one:
Figure 1: What AVM does
Developers can customize the "creation rules" and "transfer rules" of assets. These rules (or contracts) are stored and reflected in the form of data contained on the chain.
The created assets contain "states", which will be updated according to the operations. Introducing "states" is very important for expansion.
From this perspective, AVM can actually be understood as a superset of the "layer-one asset protocol" (called Overlayer Protocol in the white paper), which can provide developers with a sufficiently customized way to create assets and related systems on the BTC mainnet.
Figure 2: How to do AVM
Let's look from top to bottom, from left to right:
On the left is the BTC main network, which contains our contract data, status data, etc.
The middle part is the programming part based on Indexer. We can call the smart contract code (left). The code can be compiled by high-level language (top). After executing the contract (right), the relevant data (including token data and status data) is stored locally (bottom).
There are two types of functions that are executed: one is the original op-code of Btc, such as op_add, op_mul, etc., and there is also op_cat that has not been approved yet. The other is the op-code that developers can customize, such as op_ft_balance (FT asset balance). In theory, there will be an official library, and developers can inherit and develop new functions based on the official library.
The footnotes provide an explanation of the op-code. As for the custom op-code, I don’t quite understand why the proposed Two Stack PDA is Turing complete. If anyone knows, please give me some advice in the comments section.
Figure 3: How AVM [forms consensus]
Since each client runs off-chain, how can consensus be reached? The answer given in the white paper is to put the state hash on-chain, so that everyone can check whether the state is correct and synchronized.
After understanding the above points, we can sort out our understanding of AVM:
AVM provides a platform for developers to flexibly formulate asset rules;
Through native and customized op-codes, it can realize many functions, but it should be noted that these functions are different from the smart contracts of the EVM system that we understand, and relatively speaking, scalability requires time to develop;
AVM is based on indexer programming. In principle, it may be compatible with asset protocols with indexers in the future, and can realize native access to such assets. It may provide such assets with another cross-chain form besides multi-signature/isomorphic binding. However, it seems difficult to deeply bind different asset protocols from an ecological perspective.
The impact of AVM should not be overestimated for the time being, because it is based on the BTC mainnet, and what it can do based on the mainnet is limited (constrained by the performance of the mainnet); but it should not be underestimated either, because it can theoretically realize the contract capabilities of the mainnet, which is of great positive significance to the BTC ecosystem. Whether it can be combined with the Lightning Network in the future is also a direction that can be explored.
