原文作者：Haotian
如何理解 @atomicalsxyz 最新发布的 AVM 虚拟机白皮书？ 简单而言：它是一种通过模拟比特币虚拟机，让原本“无状态”比特币主网实现搭载智能合约系统的能力，进而可以完成 BTC 资产之外更复杂资产的状态记录和处理能力，类似于图灵完备智能合约。接下来，分享下我的理解：
1）比特币原本设计为一套点对点的电子现金系统，有一定 Script 脚本数据存储能力，同时有一些基本的 OP Codes 操作码，也有一套基于 UTXO 时间锁和花费条件的验证资产逻辑。
因此，比特币网络在记录并传输 BTC 资产时能够实现“无状态”下的资产管理。由于 UTXO 极简模型和预定义状态转化规则的限定，这种无状态模型只能处理 BTC 单个资产的有限管理。
若尝试在比特币网络上新增资产，比如 BRC 20、ARC 20、Runes 等资产，就需要有一套更复杂的动态“状态机”模型来记录这些资产的存储、交易、状态变化等。如何实现呢？
一种方式时采用外部协议和 layer 2 二层解决方案在链下构建“状态机”模型来延展处理，像 @NervosNetwork @RoochNetwork 等目前优秀的二层扩展方案，甚至 RGB、闪电网络等 Native 解决方案都属于此类；
另一种方式是直接扩展 Script 脚本的功能，以增加新的操作吗或存储空间来处理复杂资产的创建和转移，像 Covenant 和 OP_CAT 等依赖 BIP 提案标准被通过的方案都属于这种；
以上两种方式要么过于“主动”，短时间内难达成共识统一，要么过于“被动”，存在极大的不确定性。AVM 虚拟机给出的是一种介于两者之间，直接在比特币主网上构建虚拟机执行环境的特殊处理方案。
2）如何做呢？AVM 主要工作原理包含三部分：
1、比特币脚本模拟，其实就是比特币指令集，通过双堆栈 PDA（可压入存储自动机）实现了图灵完备属性；
2、沙盒运行环境，整个模拟机处于一个受控的隔离环境中，使得沙盒中的执行和之外的执行互不干扰；
3、状态哈希，可以让参与者验证其索引器的状态是否正确同步，防止了状态不一致潜在的攻击性。
简单理解：AVM 直接利用当前 BTC 有限的存储空间和 OP Codes 处理框架，通过在每笔 BTC 主网交易中引入一种特殊的编码和解码方式（沙盒环境）。
这个沙盒自带索引器、沙盒解析器（指令集），全球 Database（数据库）等等，可以独立完成一整套资产的存储、交易状态记录等管理，等同于在 BTC 主网内置了一个动态的“状态机”，继而就可以实现复杂的智能合约处理以及状态同步和验证。
3）有了 AVM 虚拟机理论上可以让比特币主网具备基础智能合约操作功能，让比特币具备管理多重复杂资产以及复杂状态逻辑 DApp 落地的可能性，相当于让比特币网络具备了一定的自构建生态功能。
这当然算是一次伟大的进步，至少和 RGB、闪电网络以及各类优秀二层协议处理方案算同级别的 BTC 扩展能力创新。甚至在 Native 方面还要优于其他方案。
不过，AVM 要依赖比特币 Script 脚本做编码存储、同时依赖 OP Codes 做交易执行，因此它整体受限于 BTC 的主网性能，比如：区块存储空间大小、出快速度等。
试想，一个基于 AVM 构建的 DeFi 项目，每分钟只能处理 7 笔交易，两个状态转化之间需要等待十分钟，这样的智能合约即使理论上完备，依然被束缚住了手脚。而且依赖比特币 Script 脚本指令集来开发复杂的合约功能，要比以太坊 Solidity 等语言开发智能合约更复杂、难度更大。
况且，AVM 的白皮书只是理清楚了一种 Make Sense 的内置虚拟机执行方式，其实际部署上线到应用环境如何运转、如何稳定运行等问题依然是未知数。
以上
整体来说，我倾向于把 AVM 的开发落地视为一种基于 BTC 主网 Script 脚本扩展的有益主动探索，确实能带动一些较简约的智能合约在 BTC 主网落地，同时可比特币主网能在二层生态构建以及 BitVM 等链上和链下组合生态中发挥更大的占比作用和价值。
但，和其他各类 BTC 扩展解决方案一样，AVM 同样也有优缺点，也得凭借落地后的生态构建情况来给自己扩大“正统性”吸引力，建议保持理性谨慎乐观态度。
