简析AVM白皮书：一种让BTC实现动态“状态机”的图灵完备虚拟机？

时间：2024-09-30 编辑： 浏览：(184)

作者：郝天

如何理解 @atomicalsxyz 最新发布的AVM虚拟机白皮书？简单而言：它是一种通过模拟比特币虚拟机，让原本“无状态”比特币主网实现搭载智能合约系统的能力，进而可以完成BTC资产之外更复杂资产的状态记录和处理能力，类似于图灵完备智能合约。接下来，分享下我的理解：

1）比特币原本设计为一套点对点的电子现金系统，有一定Script脚本数据存储能力，同时有一些基本的OP Codes操作码，也有一套基于UTXO时间锁和花费条件的验证资产逻辑。

因此，比特币网络在记录并传输BTC资产时能够实现“无状态”下的资产管理。由于UTXO极简模型和预定义状态转化规则的限定，这种无状态模型只能处理BTC单个资产的有限管理。

若尝试在比特币网络上新增资产，比如BRC20、ARC20、Runes等资产，就需要有一套更复杂的动态“状态机”模型来记录这些资产的存储、交易、状态变化等。如何实现呢？

一种方式时采用外部协议和layer2 二层解决方案在链下构建“状态机”模型来延展处理，像 @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同样也有优缺点，也得凭借落地后的生态构建情况来给自己扩大“正统性”吸引力，建议保持理性谨慎乐观态度。