Arweave、AO、AI——模块化框架与灵活的安全性

作者：Arweave Oasis，来源：推特@ArweaveOasis

最近业内知名研究机构 Messari 发布了一篇题为《Arweave, AO, and AI – 模块化框架与灵活的安全性》的文章，作者为 seth bloomberg。内容非常丰富，对理解 AO 与 AR 架构与未来发展前景有较大的参考价值。但由于其有版权问题，所有无法全文翻译展现给读者。故笔者希望能从中截取片段，用解读的方式来展现给各位。原文内容可以去 Messari 获取（需要付费）。

5 月 30 日，本文的作者 Seth Bloomberg 在 X 上发布了一些对该篇文章的内容总结。具体如下：

Arweave 历来依赖外部应用程序和生态系统将数据传输到其网络中。AO是一个建立在 Arweave 上的新网络，现在将为 Arweave 创造一致的需求。AO 将成为 Arweave 的增长催化剂和应用开发的新平台。
我认为 AO 最大的技术价值之一是它将共识机制与应用程序所需的计算分离开来。将这些拆分给 AO 提供了模块化架构，并允许开发人员扩展其应用程序的安全性和计算能力。
AO 中的应用会激励算力提供商处理状态更新和其他消息。这为应用程序和算力提供商创造了一个新市场。它确保应用程序按需获得该有的资源水平。这与大多数智能合约平台有很大不同。
AO 是虚拟机无关的平台，这为部署计算密集型应用程序打开了潜力。像 @autonomous_af 这样的团队已经在开发 DeFi 自动化。然而，链上 LLM（大语言模型）会是一个完全不同的物种。

随后通读全文，你会发现对 AO 这种完全以不同形式实现的分布式世界计算机的兴趣。总结出的几点主要 Insight 有：

AO 是一个建立在永久数据存储网络 Arweave 之上的全新协议。AO 的核心价值主张之一是其能够在没有扩展性限制之下的完全的并行运行应用程序（在 AO 术语中这种应用程序称为进程 Process），并在本地维护相关状态，而不需要在全网络中共享全局状态。
所有 AO 上的应用程序通过定义好的消息（在 AO 术语中成为 Message）标准进行通信，为进程提供开袋即食的读写数据解决方案。
AO 的一个独特特性是能够灵活地扩展进程的安全性。进程开发者可以配置其应用程序所需的安全性，并通过有效支付额外的验证者（在 AO 术语中称为计算单元 CU）来计算应用程序的状态，从而扩展安全性。
由于 AO 的可扩展性特性、虚拟机无关架构（这里指的是 AO 可以支持多种虚拟机，使开发者可以根据具体需求选择不同的虚拟机来运行他们的应用程序，而不必局限于单一的虚拟机环境。）和原生 cron 作业功能（指系统原生支持定时任务调度的功能，而不需要依赖外部工具或第三方服务），许多团队希望在网络上构建自动化工具和 AI 驱动的产品。

模块化和灵活安全性

作者总结了在过去几年中出现的两个主要基础设施：模块化框架与灵活安全性。

模块化框架：使开发者可以选择通用区块链模块化组件（例如，执行、数据可用性、结算和共识），并将它们组合在一起。文中以 Base 的 Rollup 与 Celestia 数据可用性层作为代表举例。

灵活且可扩展的安全性：指的是一些网络能够通过租赁安全性来更加高效地保护其服务，而不是自己去启动一个非常重的验证者网络。作者用 Eigenlayer 作为案例进行了相应的解释。

模块化框架的目标是鼓励每个组件的可选性和专业化。例如，开发者可以自由选择最适合其需求的执行环境。而灵活安全提供者则帮助网络更好地管理和微调其系统的经济安全性。

AO 就是同时利用这两种基础设施模式的典型范例。这一建立在 Arweave 之上的新系统为开发者提供了选择执行环境和安全模型的灵活性。

不同于像以太坊和 Solana 这样的链拥有单一的全球状态概念（例如，用户账户余额、智能合约数据等），AO 将状态本地化到每个应用程序（在 AO 术语中称为进程）。本地化状态使应用程序更容易并行化计算，与非并行环境相比，完全释放了总体性能限制，并且可以为计算定制安全性。

与其他 Rollup 生态系统不同，AO 为所有应用程序定义了统一全球消息标准（Message）。作者认为这种方法在概念上类似于 Cosmos 生态系统，后者利用 IBC 进行链与链之间的通信。因此，AO 可以维持其模块化框架，并且随着其生态系统的增长，应用程序将受益于这种原生的通信标准。从长期来看，AO 这种脱离了传统智能合约平台模型，形成了自己独特的架构，促进一个繁荣的应用程序发展的生态系统。

AO 的架构

作者认为 AO 与 Arweave 的关系大致类似于主权 Rollup 与数据可用性层的关系。但 AO 提供了一个类似于智能合约平台的通用框架，主要目标是通过可扩展的计算服务实现这些不同应用程序的信任互操作性。

应用程序之间的互操作性源自 AO 的消息标准。诸如 Optimism、Polygon、Arbitrum 和 zkSync 等生态系统通常先发展链上的经济活动，然后再开发互操作性解决方案以解决碎片化的用户体验问题。而 AO 将从原生互操作性开始其旅程。

AO 的架构我们在各种文章中都有介绍，在本文中也同样做了一些从作者角度的解读：

进程（Process）

从最终用户的角度来看，进程可以被视为一个应用程序。如果消费者在使用基于 AO 构建的产品，它通常会以进程的形式出现。

一个进程也可以被视为写入 Arweave 中的一系列有序日志（即消息），代表其在任何给定时间点的状态。

每个进程相对于 AO 上的其他进程独立运行，使它们能够并行化运算，互不影响。进程通过消息相互交互。AO 实际上就是一个消息的传递协议，所以消息的概念是其中的核心结构。

消息和消息单元（MU）

无论是由最终用户发起还是由另一个进程发起的与进程的交互，都表示为一条消息。AO 中的每条消息都符合 Arweave 生态读写数据的 ANS-104 的特定格式。至于 ANS-104 是什么，可以查阅这个链接详细了解。

作者对比了 AO 与以太坊直接的区别。在 AO 中，进程通过消息请求另一个进程的信息并等待数据返回来完成进程之间的交互。但在以太坊上，应用程序（即智能合约）由于 EVM 的全局性，可以直接访问任何其他应用程序的状态。

这两者之间有从根本的区别。从模块化的角度来看，预先标准化不同进程的互操作性是有利的；大多数模块化网络（例如 Optimism 的 Superchain）也在开发类似标准。

调度单元（SU）

作者将调度单元简单地类比为许多 Rollup 系统中的排序器。由于排序器在许多 Rollup 中负责一系列操作（例如，交易处理、交易排序、零知识证明生成等），因此调度单元更像是典型排序器的一个子集。

调度单元主要有两个与其关联的进程功能：

确保每条消息唯一且按顺序排列。这在概念上类似于以太坊等其他区块链环境中的 nonce 递增。这对于一个进程的正常运行至关重要。

确保每条消息都写入 Arweave。这使进程能够访问彼此的数据。

每个 AO 进程都会有一个关联的调度单元。

计算单元（CU）

计算单元为更新 AO 进程提供计算能力。消息单元通知计算单元其服务需要。

在计算单元（供应方）和需要某个特定进程计算的用户（需求方）之间形成一个市场。再一次，这种架构与传统区块链模型不同。传统平台（如以太坊）上的节点需要处理交易，而计算单元可以选择性地竞标其更新的进程。

一旦计算完成，计算单元会将签名的计算输出证明返回给原始消息单元。

AO 安全模型

在安全模型的部分，目前相关信息较少，需要等 AO 白皮书发布之后会有更多细节。不过该文作者给出了自己的理解。

他认为在这个发面，AO 也与以太坊走了截然不同的道路。在以太坊生态中，安全性都是由以太坊 PoS 机制来统一保障，所以无论是简单的转账操作，还是复杂的 DeFi 交互，都是共享相同的安全级别，这往往会导致资源浪费。

而在 AO 的安全框架中，虽然所有数据都使用了 Arweave 的 SPoRes 共识机制的安全保障，但在 AO 层面，也有更多的灵活性以此来根据不同需求和目标来定制化安全级别。

目前，虽然没有确切的信息，但生态内普遍认为在 AO 的安全机制上大概率会使用 PoS 机制（例如，抵押和惩罚 AO 代币）。完全去中心化的永久存储网络 Arweave 加上以提高扩展性与灵活性的 AO 计算平台，PoS 机制显然是符合发展需要的。

因此，AO 可以针对每个组件角色提出一定不同的 Staking 质押方案，并设置相应的惩罚机制。

计算单元 – 计算单元针对其签名的输出证明进行质押。任何人都可以质疑计算单元的输出，如果证明存在作恶行为，其抵押可以被 Slash。
消息单元 – 消息单元针对其在系统中传递的消息进行质押。如果发现其传递和签署无效消息，其质押可以被 Slash。如果无效签名是由于计算单元的不当行为导致的，消息单元可以发起针对计算单元的 Slash 事件。
调度单元 – 如果调度单元未能正确排序消息或未将消息上传到 Arweave，则可以被 Slash。后者的 Slash 事件在设计上类似于数据可用性保证。

最终，一个进程可以在某种意义上设计其自己的安全模型。在进程的代码执行期间，例如，可以决定忽略某个被认为不可信的计算单元或消息单元。

图中展示了传统智能合约平台的安全性一致性，与 AO 平台的安全可定制型。这让 AO 能够为不同业务定制不同级别的安全性，如朋友间的小额转账不用与 B2B 的大宗交易的安全性一致。

AO 和 AI 的未来

作者进一步对 AO 与 AI 未来的结合表达了自己的观点。他认为 AI 的分类可以是两种：

完全确定性的和完全参数化的，比如说具有可配置设置的机器人；

非确定性的，具有适应能力的，比如 ChatGPT 或 LLM 应用程序。

在 AO 中的发展，作者觉得起点会是前者，比如说 DeFi 自动化工具。

DeFi 自动化

AO 上的一个早期 DeFi 自动化项目是 @autonomous_af。该团队构建了一个“DCA 代理”，使用户能够以美元成本平均法（DCA）买入指定代币。

DCA 代理产品遵循模式：

用户定义他们希望 DCA 买入的代币，以及其他参数，如滑点容忍度、特定的 DeFi 池、DCA 交易的频率和每笔 DCA 交易的金额。

DCA 代理响应收到的通知（即定时任务）并在满足预定义条件时执行 DCA 交易。

用户最终可以暂停 DCA 代理或永久停用它。

需要明确的是，这种代理是以规则为基础的方式执行操作，并有效地遵循其底层脚本中定义的指令。这在分类上就是前者 —— 完全确定性和参数化的 AI。

在这点上，其实 Arweave 创始人 @samecwilliams 也曾经表达过相似观点，在目前主流金融系统中，大量的交易并非由投资者操作，而是各种机器人在自动交易。所以这也天然适用于 DeFi 交互场景。事实上，最安全的实现某些目标的方法是为代理设置严格的规则和操作。这实际上将这些产品拉近到与传统金融产品和功能的相同水平（例如，设置止损，从银行账户设置 DCA 产品等），从用户体验角度来看，这是一个好事。

超越 DeFi 自动化

除了上述的较为简单的 AI，目前科技届主流的对 AI 的套路都是集中在非确定性，具有适应能力的 AI 上，比如说 Chatgpt 与 LLM 模型。

显然，这类系统相较于“DCA 代理”来说会更加高级。但它也非常昂贵。一般来说，LLM 产品需要 GPU 来提供必要的计算能力，而 GPU 计算比典型的 CPU 计算更昂贵。自托管一个 LLM 基础模型的成本很容易达到每月约 2 万美元。作者给出了一项 a16z 的数据，一些生成式 AI 初创公司仅在 AI 计算上就花费了 80% 的资金。

所以，如果要想在 AO 上构建使用 LLM 的应用程序，经济成本的考量是无法避免的。但与其他智能合约平台相比，AO 的架构使开发者能够扩展和微调其进程的安全级别。这种结构将极大地有利于 AO 开发者，因为大多数 LLM 生成的消息价值较低。

最后的思考

作者在最后给出了他对 AO 机构的思考：

AO 的独特架构为应用程序的开发提供了一个有吸引力的平台，从 DeFi 到 AI 驱动的应用程序。

异步消息传递结合并行计算使应用程序比典型的智能合约应用程序更加丰富和复杂。

支持进程的可扩展和灵活的安全性也是 AO 所独有的，尤其是 LLM 驱动的产品，将利用这一属性。