从存储过去到计算未来：AO超并行计算机

前言

Web3如今分化出的两种主流区块链架构设计已经让人难免有些审美疲劳，不管是泛滥成灾的模块化公链还是总强调性能却体现不出性能优势的新型L1，其生态可以说都是对以太坊生态的复刻或者细微改进，同质化极高的体验早已让用户失去新鲜感。而Arweave最新提出的AO协议却令人眼前一亮，在存储公链上实现超高性能运算甚至达成准Web2的体验。这与我们目前所熟知的扩容方式和架构设计似乎有着巨大的差别，那么AO究竟是什么？支持其性能的逻辑又从何而来？

如何理解AO

AO的命名来自于并发运算模型Actor Model中一种编程范式Actor Oriented的缩写，其整体设计思路源于对Smart Weave的延伸，同时也遵循Actor Model以消息传递为核心的理念。简单来说，我们可以将AO理解为一台通过模块化架构运行在Arweave网络之上的“超并行计算机”。从实现方案上看，AO其实并非我们当下常见的模块化执行层，而是一个规范消息传递与数据处理的通信协议。该协议的核心目标旨在通过信息传递实现网络内不同“角色”的协作，从而实现一个性能可无限叠加的计算层，最终使得Arweave这块“巨型硬盘”能够在去中心化信任环境下拥有中心化云级别的速度、可伸缩的计算能力及具备可扩展性。

AO的架构

AO的理念看起来与Gavin Wood在去年Polkadot Decoded大会上提出的「Core Time」分割与再组合有些异曲同工之处，两者都是通过对计算资源的调度与协调，以实现所谓的“高性能世界计算机”。但两者在本质上其实有一些区别，异构调度（Exotic Scheduling）是对中继链区块空间资源的解构与重组，对于波卡的架构并没有太大改变，计算的性能虽然突破了插槽模型下单一平行链的限制，上限却依旧受限于波卡的最高闲置核心数。而AO理论上可以通过节点的水平扩展提供近乎无限的计算能力（在实际情况下应该取决于网络激励水平）和更高的自由度，从架构上来说，AO规范了数据处理方式和消息的表达，并通过三个网络单元（子网）完成信息的排序、调度与计算，其规范方式与不同单元的职能，据官方资料分析可概述为以下几点：

• 进程（Process）： 进程可被视为AO中执行指令的集合，进程在初始化时可定义它所需的计算环境，包括虚拟机、调度程序、内存需求和必要的扩展。这些进程保持一种“全息”状态（每个进程数据都可独立存储状态至Arweave的消息日志中，下文“可验证问题”部分中会对全息状态做出具体解释），全息状态意味着进程能够独立工作，且执行是动态的，可以由适当的计算单元来执行。除了从用户钱包接收消息之外，进程还可通过信使单元转发来自其它进程的消息；

• 消息：用户（或者其它进程）每次与进程的交互都由一条消息来表示，消息必须符合Arweave 原生的 ANS-104 数据项，从而保持本机结构一致，以便于Arweave对信息的保存。从更易理解的角度来说消息就有点类似传统区块链中的交易ID（TX ID），但两者并不完全相同；

• 信使单元 (MU)： MU通过一种称为'cranking'的过程中继消息，负责系统中通信的传递，以确保无缝交互。一旦消息被发出，MU 就会将其路由到网络内的适当目的地（SU），协调交互并递归地处理任何生成的发件箱消息。此过程将持续进行，直到处理完所有消息。除了消息中继之外，MU 还提供各种功能，包括管理进程订阅和处理定时 cron 交互；

• 调度程序单元 (SU)：当收到消息时，SU会启动一系列关键操作来维护进程的连续性和完整性。在接收到消息后，SU会分配一个唯一的增量nonce，以确保相对于同一进程中其他消息的顺序。这个分配过程通过加密签名进行形式化，保证真实性和序列完整性。为了进一步提高进程的可靠性，SU将签名分配和消息上传到Arweave数据层中。这样可以确保消息的可用性和不变性，并防止数据篡改或丢失；

• 计算单元 (CU)：CU通过在一个点对点的计算市场内相互竞争，以完成用户与SU解决计算进程状态的服务。一旦状态计算完成，CU便会返回一个带有特定消息结果的签名证明给调用者。此外，CU还能生成并发布其他节点可以加载的签名状态证明，当然这也需要支付一定比例的费用。

操作系统AOS

AOS可被视为AO协议中的操作系统或者说终端工具，可用于下载、运行和管理线程。它提供了一个环境，使开发者能够在其中开发、部署和运行应用程序。在AOS上，开发者可以利用AO协议进行应用程序的开发和部署，并与AO网络进行交互。

运行逻辑

Actor Model推崇着一种叫“一切皆是演员”的哲学观点。该模型内的所有组件和实体都可以被视为“演员”，每个演员都有自己的状态、行为和邮箱，它们通过异步通信进行消息传递与协作，从而使得整个系统能够以一种分布式和并发的方式来组织和运行。AO网络的运行逻辑也是如此，组件乃至用户都可被抽象为“演员”，并通过消息传递层相互通信，使得进程相互链接，一个可并行计算且非共享状态的分布式工作系统就在交织中被建立起来了。

以下是关于信息传递流程图步骤的简述：

1. 消息的发起：

• 用户或进程创建消息向其它进程发送请求。

• MU（信使单元）接收到该消息，并使用POST请求将其发送到其他服务。

• 消息的处理和转发：

• MU处理POST请求并将消息转发到SU（调度单元）。

• SU与Arweave存储或数据层进行交互，将消息存储起来。

• 根据消息ID检索结果：

• CU（计算）接收到GET请求，根据消息ID检索结果，并评估消息在进程上的情况。它能够根据单个消息标识符返回结果。

• 检索信息：

• SU接收到GET请求，根据给定的时间范围和进程ID检索消息信息。

• 推送发件箱消息：

• 最后一步是推送所有发件箱消息。

• 此步骤涉及检查结果对象中的消息和生成。

• 根据此检查的结果，可以对每个相关消息或生成重复执行步骤2、3和4。

AO改变了什么？「1」

与常见网络的区别：

1. 并行处理能力：与以太坊等网络不同，后者的基础层和每个 Rollup 实际上都作为单一进程运行，AO 支持任意数量的进程并行运行，同时确保计算的可验证性保持完整。此外，这些网络在全球同步状态下运行，而 AO 进程保持自己的独立状态。这种独立性使得 AO 进程能够处理更高数量的交互和计算的可扩展性，使其特别适合对高性能和可靠性有需求的应用程序；

2. 可验证的可复现性：虽然一些去中心化网络，如 Akash 和点对点系统 Urbit，确实提供了大规模的计算能力，但与 AO 不同，它们不提供交互的可验证复现性，或者依赖于非永久性存储解决方案来保存它们的交互日志。

AO的节点网络与传统计算环境的不同之处：

• 兼容性：AO 支持各种形式的线程，无论是基于 WASM 还是 EVM 的，都可以通过一定的技术手段架接到 AO 上。

• 内容共创类项目： AO 还支持内容共创类的项目，可以在 AO 上发布 atomic NFT，上传数据结合 UDL 在 AO 上构建 NFT。

• 数据组合性：AR 和 AO 上的 NFT 可以实现数据组合性，允许一篇文章或内容在多个平台上共享和显示，同时保持数据源的一致性和原始属性。当内容发生更新时，AO 网络能够将这些更新状态广播给所有相关平台，确保内容的同步和最新状态的传播。

• 价值回馈和所有权：内容创作者可以将他们的作品作为 NFT 出售，并通过 AO 网络传递所有权信息，实现内容的价值回馈。

对项目的支撑：

1. 基于Arweave构建：AO利用Arweave的特性，消除了与中心化提供商相关的脆弱性，如单点故障、数据泄露和审查制度。AO上的计算是透明的，可通过去中心化的信任最小化特性和存储在Arweave上的可复现消息日志来验证；

2. 去中心化基础：AO的去中心化基础有助于克服物理基础设施施加的可扩展性限制。任何人都可以从他们的终端轻松创建一个AO进程，无需专门的知识、工具或基础设施，确保了即使是个人和小规模实体也能拥有全球影响力和参与度。

AO的可验证问题

在我们理解了AO的框架与逻辑之后，通常会有一个普遍问题。AO似乎没有传统去中心化协议或者链的全局特征，仅通过上传一些数据到Arweave便可实现可验证性与去中心化？？其实这正是AO设计的奥妙之处。AO本身就是链下实现，也不解决可验证性问题，也不更改共识。AR团队的思路是将AO与Arweave的职能剥离，再模块化衔接，AO只进行通信与计算，Arweave只提供存储与验证。两者的关系更像是映射，AO只需确保交互日志存储在 Arweave上，其状态就可以投影到Arweave，从而创建全息图，这种全息状态投影保证了在计算状态时输出的一致性、可靠性、确定性。此外通过Arweave上的消息日志也可反向触发AO进程执行特定的操作（可以根据预设条件和时间表，自行唤醒，并执行相应的动态操作）。



依据Hill与Outprog的分享，如果把验证逻辑说的再简单一点，那么可以将AO想象为一个基于超并行索引器的铭文计算框架。我们都知道比特币铭文索引器验证铭文，需要从铭文中提取JSON信息，并将余额信息记录在链下数据库中，通过一套索引规则完成验证。虽然索引器是链下验证，但用户可以通过更换多个索引器或者自己运行索引来验证铭文，从而无需担心索引器作恶。我们在上文中提到了消息的排序以及进程的全息状态等数据都上传至Arweave，那么只需要基于SCP范式（存储共识范式，此处可以简单理解为SCP是索引规则在链上的索引器，另外值得注意的是SCP出现的时间远比索引器早），任何人都可以通过Arweave上的全息数据恢复AO或者AO上的任何一个线程。用户也不需要跑全节点去验证可信状态，同更换索引一样，用户只需通过SU向单个或多个CU节点提出查询请求即可。而Arweave 的存储能力高且费用低廉，所以在这套逻辑下，AO开发者可以实现远超比特币铭文功能的超级计算层。

AO与ICP

我们再用一些关键词总结一下AO的特性：巨型原生硬盘、无上限并行、无上限计算、模块化的整体架构以及全息状态的进程。这一切听起来都特别美好，但熟知区块链各种公链项目的朋友可能会发现AO与一个“天亡级”项目特别相似，也就是曾经风靡一时的“互联网计算机”ICP。

ICP曾被誉为区块链世界的最后一个天王级项目，深受顶级机构热捧，在21年的疯狂大牛中也达到过2000亿美金的FDV。但随着浪潮退去，ICP的代币价值也呈直线下降。直至23年熊市ICP代币价值相较于历史最高位，已经跌了将近260倍之多。但如果不考虑Token价格的表现，即便在当前这个时间节点重新审视一遍ICP，其技术特点依旧有很多独到之处。AO如今令人惊叹的许多优势特性，ICP当年同样具备，那么AO会如同ICP一样失败吗？我们先来了解一下两者为什么会如此相似，ICP与AO都是基于Actor Model设计，侧重于局部运行的区块链，所以两者特性才会存在很多共同之处。ICP子网区块链由一些独立拥有和控制的高性能硬件设备（节点机）形成，这些硬件设备运行互联网计算机协议（ICP）。互联网计算机协议由许多软件组件实现，这些组件作为一个捆绑包是一个副本，因为它们在子网区块链中的所有节点上复制状态和计算。

ICP的复制架构从上至下可分为四层：

点对点(P2P) 网络层：用于收集和通告来自用户、其子网区块链中的其他节点以及其他子网区块链的消息。对等层收到的消息将被复制到子网中的所有节点，以确保安全性、可靠性和弹性；

共识层：选择并排序从用户和不同子网收到的消息，以创建区块链区块，这些区块可以通过形成不断发展的区块链的拜占庭容错共识进行公证和最终确定。这些最终确定的块被传递到消息路由层；

消息路由层：用于在子网之间路由用户和系统生成的消息，管理 Dapp 的输入和输出队列，并安排消息执行；

执行环境层：通过处理从消息路由层接收到的消息来计算执行智能合约所涉及的确定性计算。



子网区块链

所谓的子网是交互副本的集合，这些副本运行共识机制的单独实例，以便创建自己的区块链，在该区块链上可以运行一组「容器」。每个子网都可以与其他子网通信，并由根子网控制，根子网使用链密钥加密技术将其权限委托给各个子网。ICP使用子网来允许其无限扩展。传统区块链（以及各个子网）的问题在于它们受到单个节点机器的计算能力的限制，因为每个节点都必须运行区块链上发生的所有事情才能参与共识算法。并行运行多个独立子网使得ICP突破了这一单机障碍。

为什么失败

如上文所述，ICP架构想实现的目的，简单来说就是去中心化的云服务器。在几年前这个构想也如同AO一样令人震撼，但为什么会失败呢？简单来说就是高不成低不就，在Web3与自己的构想之间并没有找到一个很好的平衡点，最终导致项目并不Web3也不如中心化云好用的尴尬局面，总结来说问题有三点。第一，ICP的程序系统Canister，也就是上文中的「容器」其实有点类似于AO中的AOS和进程，但两者并不一样。ICP的程序是被Canister封装实现的，外界并不可见，需要通过特定接口去访问数据。在异步通信下对于DeFi协议的合约调用很不友好，所以在DeFi Summer中，ICP并没有捕获到相应的金融价值。



第二点是硬件要求极高，导致项目并不去中心化，下图是当时ICP给出的节点最低硬件配置图，即便放在现在也是非常夸张，远超Solana的配置，甚至存储要求比存储公链还高。



第三点是生态匮乏，ICP即便放到现在也是性能极高的公链。如果说没有DeFi应用，那么其它应用呢？抱歉，ICP从诞生至今也没跑出一个杀手级应用，其生态既没有捕获到Web2的用户，也没有捕获到Web3的用户。毕竟在去中心化程度如此不足的情况下，为什么不直接使用内容丰富且成熟的中心化应用呢？但最后不可否认的是ICP的技术依旧很顶尖，其反向Gas、高兼容性、无限扩展的优势还是吸引下一个十亿用户所必备的，而在当前的AI浪潮下，ICP如果能善用自身的架构优势也许还存在翻身的可能。

那么回到上文中的问题，AO会像ICP一样失败吗？我个人认为AO并不会重蹈覆辙，首先导致ICP失败的后两点，对于AO来说都不是问题，Arweave已经有很好的生态基础了，全息状态投影也解决了中心化问题，兼容性上AO也更为灵活。更多的挑战也许要集中于经济模型上的设计，对于DeFi的支撑，以及一个世纪难题：在非金融与存储领域，Web3该以什么形式展现？

Web3不应止于叙事

Web3的世界中出现频率最高的词语必然是“叙事”，我们甚至已经习惯用叙事的角度去衡量大部分代币的价值。这自然是源于Web3大部分项目愿景很伟大，用起来却很尴尬的窘境。相较之下Arweave已经有很多完全落地的应用，并且对标的都是Web2级别的体验。譬如Mirror、ArDrive，你如果使用过这些项目应该很难感受到与传统应用的差别。但Arweave作为存储公链的价值捕获依然存在很大的局限性，计算也许是必由之路。尤其在如今的外部世界中，AI已是大势所趋，Web3在现阶段的结合中还存在很多天然的壁垒，这点我们在过去的文章也谈到过。现在Arweave的AO用非以太坊模块化方案的架构，给了Web3 x AI一个很好的新基建。从亚历山大的图书馆到超并行计算机，Arweave在走一条属于自己的范式。