原文作者: Haotian | CryptoInsight
原文来源: X
如何理解 @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笔交易,两个状态转化之间需要等待10分钟,这样的智能合约即使理论上完备,依然被束缚住了手脚,可落地的场景和想象空间很有限。而且依赖比特币Script脚本指令集来开发复杂的合约功能,要比以太坊Solidity等语言开发智能合约更复杂、难度更大。
因此,AVM的白皮书只是理清楚了一种Make Sense的内置虚拟机执行方式,其实际部署上线到应用环境如何运转、如何稳定运行等问题依然是未知数。
以上
整体来说,我倾向于把AVM的开发落地视为一种基于BTC主网Script脚本扩展的有益主动探索,确实能带动一些较简约的智能合约在BTC主网落地,同时可比特币主网能在二层生态构建以及BitVM等链上和链下组合生态中发挥更大的占比作用和价值。
但,和其他各类BTC扩展解决方案一样,AVM同样也有优缺点,也得凭借落地后的生态构建情况来给自己扩大“正统性”吸引力,建议保持理性谨慎乐观态度。
![](/uploads/allimg/20240530/u5r0idd15hc.jpg)
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。
郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。