ao 计算机的协议规范

ao 是什么？

ao 是运行在 Arweave 上的 Actor Oriented（基于角色的）计算机，组成该计算机的网络节点遵循核心数据协议。本文简要介绍了协议规范、功能和技术细节，让构建者进行实现或集成该服务。

ao 是一个单一的、统一的计算环境（单系统映像 Single System Image），托管在分布式网络中的异构节点集上。ao 被设计为一个可以驻留任意数量并行进程的环境，进程之间通过开放的消息传递层进行协调。

这种消息传递标准将机器独立运行的进程连接到一起，形成一个“网络”，就像网站在独立的服务器上运行，但是通过超链接连接成具备统一体验的整体系统一样。

与现有的去中心化计算系统不同，ao 支持灵活的计算操作，这些计算不受制于协议固有容量限制和形式，同时保持网络本身的可验证性（从而实现最小化信任）。

此外，ao 的分布式和模块化架构允许现有的智能合约平台轻松地“接入”到网络中，开启一个可以与任何其他进程发送和接收消息的单一进程。

ao 不会对所有用户计算环境强加一套规则，ao 使用模块化的形式构建：允许用户选择最适合他们的虚拟机、排序模型、消息传递安全性保证和付款选项。

这个模块化环境通过统一的消息（所有消息采用相同的格式）在 Arweave 的去中心化数据层上进行结算处理。这个模块化环境是一个可满足极其广泛的工作负载需求的统一计算环境，每个进程都可以轻松传递消息和协作。

ao 的核心目标是在没有规模限制的情况下，实现去信任和相互协作的计算服务。这为过去不可能实现的应用程序提供了新的可能性：将智能合约应用的优势（只需对代码信任的服务）与传统计算环境（如亚马逊 EC2 等）的优势结合起来。

aos（ao 的去中心化操作系统）允许开发人员在去中心化网络中启动类似于智能合约的命令行进程。这个过程类似于在云服务上启动服务器，但去中心化和去信任计算是其关键优势。

这些进程运行时不受限于特定的物理位置，通过网络实现了无缝的用户交互。由此产生了一个单一的（单系统映像 Single System Image）、统一的、全球性的计算平台，超越了物理和扩展性限制，由所有参与者共同使用。

简而言之，ao 形成了一个庞大的、可扩展的计算机，在这个计算机上用户可以与任何进程进行交互，形成一个高度协作的生态系统。

对于用户而言，ao代表着一个共享的计算机，他们可以在其上执行多个进程。这些进程不受任何特定服务器的限制，也不受任何个人或团体的支配。一旦激活，这些进程会以加密安全的方式提供服务，确保客观和持久的运行。

这种设计赋予用户长期稳定使用应用程序的权利，从而为用户与系统交互提供了一个可信赖的环境。

核心功能

与现有的去中心化和分布式计算系统相比，ao 协议提供了以下功能：

任意数量的进程（进程类似于智能合约）并行运行：在 ao 中，应用程序由任意数量的通信进程构建。受到原始 actor 模型（Carl Hewitt，1973年）和 Erlang 的启发，ao 不允许进程之间共享内存，但允许它们通过本机消息传递标准进行通信。

然后，这些进程中的每一个都可以使用可用计算资源的全速运行，而不会相互干扰。通过专注于消息传递，ao 实现了更类似于传统 Web2/分布式系统环境的扩展机制，而不是传统的智能合约。

无限的计算资源：在原始版本的 SmartWeave 和 LazyLedger（后来称为 Celestia）的惰性运算架构的基础上构建，ao 网络中的节点在达成关于程序状态转换的共识时无需执行任何计算。

每个进程的的所有日志都被存储，最终进程的全息状态（HolographicState）被留存在了 Arweave 上。然后将计算成本委托给用户，用户可以自行计算其状态，或者请求由他们选择的节点执行计算。

访问 Arweave，一个无限的硬盘：ao 进程可以无缝加载和执行任何大小的数据直接到其内存，并写回网络。这种设置消除了典型的资源约束，实现了完全并行执行，大大扩展了应用程序开发的可能性，超越了传统智能合约平台的限制。

因此，它为需要大量数据处理和计算资源的复杂应用开启了大门，例如机器学习任务和大计算量的自主代理。

自动化合约：在传统的智能合约环境（如以太坊、Solana、Polygon 等）中，合约必须在用户交易的请求下，才能”唤醒”以执行计算。在此环境中，除非用户与其交互，否则程序不会“活跃”，从而减少了可以在其上构建的应用程序的范围。

ao 通过允许合约通过计划任务来消除这一限制，这些交互可以在设定的间隔时间自动唤醒并执行计算。任何用户，或者进程本身，都可以支付费用给一个节点来“订阅”一个进程，从而以适当的频率来触发计算。

支持扩展的模块化架构：ao 的核心架构是一个任何人都可以构建的开放数据协议。从排序器、消息传递中继器，甚至是系统级的虚拟机都可以随意替换和扩展。

这种灵活性将允许 Arweave 生态系统中的现有智能合约系统（Warp、everPay、Mem 等）插入 ao，并能够与统一网络进行消息的发送和接收。这也将允许所有这些智能合约系统共享一些相同的基础设施和工具，从而使 Arweave 上的计算体验更加连贯。

ao 架构简介

ao 的基本组件如下：

进程：网络中的计算单位。进程可以表示为存储在 Arweave 上交互日志，这些日志由的信息数据项组成。初始化进程的时候，需要定义计算环境（包括虚拟机、调度器、内存和必要的扩展）。

进程的状态可以通过满足需求的计算单元进行运算，并获得共识。除了从用户钱包接收消息外，进程还通过信使单元从其他进程接收消息。进程的开发者可以自由选择如何确定这些消息的可信度（见下文）。

消息：ao 中与进程的每次交互都由消息表示。从根本上讲，消息是符合ANS-104标准的数据项。用户和进程（通过其发件箱和信使单元）可以通过调度单元向网络中的其他进程发送消息。

ao 消息的语义定义处于 UDP 和 TCP 之间：保证只发送一次，但如果消息从未被信使单元转发，或者接收方从未实际处理它，那就相当于该消息从未发生。

调度单元（SUs）：调度单元负责为发送给进程的信息分配原子递增时隙编号（类似于以太坊 nonce）。分配后，调度器需要确保数据上传到 Arweave，从而永久地供其他人访问。

进程可以自由选择其首选的排序器，其可以以各种方式实现：去中心化的、中心化的，甚至是用户托管的。

计算单元（CUs）：计算单元是计算 ao 中进程状态的节点，它的输入使用了用户和信使单元提供的信息。调度单元只会对进程消息进行排序，需要额外的计算单元进行进程的状态计算。

这创建了一个点对点的计算市场，在这个市场上，计算单元提供计算进程状态的服务，并相互竞争。这些计算单元在价格、计算需求以及其他参数之间进行权衡博弈。一旦状态计算完成，计算单元将向调用者返回一个附带签名的输出证明。

计算单元也可能生成并发布签名的状态证明，其他节点可以选择加载这些证明——可以选择支付由 UDL 指定的费用。

信使单元（ MUs）：信使单元负责在 ao 网络中传递消息，这些消息通过一个称为 Cranking（专有名词，拥有“启动“和“重复执行”等含义） 的过程进行传递。

本质上，当信使单元在系统中处理一条消息时，它们会将信息发送到合适的 SU 进行处理，信息被 SU 交付给 CU 计算输出再返回 SU，信使单元不断重复这一过程。

这个过程持续进行，直到没有更多消息需要处理。用户和进程也可以支付费用给 MU 来订阅一个进程，处理由其定时计划任务交互产生的任意消息。进程还可以选择性地将一条消息标记为广播（cast），这将导致 MU 将消息发送给其 SU，但不监听响应。

通过这种方式，ao 能够提供一个充满活力的环境，为用户提供和进程最大的选择自由度——虚拟机（VM）、支付方式、调度器类型、消息安全性等——而无需就昂贵的计算本身达成共识。

相关工作

目前还没有类似的案例可以描述 ao 及其使用体验。然而，有许多相关项目和网络可以与 ao 进行对比，以阐明其特性。在这一部分中，我们依次讨论每个相关工作。

Actor 模型

Actor 模型由 Carl Hewitt、Peter Bishop 和 Richard Steiger 在他们的论文《用于人工智能的通用模块化 Actor 形式化》中引入，作为理解和实现计算机系统中并发性的基本框架。

该模型认为，计算的基本单位是 “actor”，即可以做出本地决策、创建更多 actor、发送消息，并确定如何响应接收到消息的实体。这种系统设计和编程方法有助于创建分布式、高度并发和可扩展的应用程序。

Erlang

ao 在很大程度上受到 Erlang 计算环境及其编程语言的启发。Erlang 是 Actor 模型的一种实现，提供了极其轻量级的进程，由 runtime 中的调度器处理，以便在大规模并行系统（具有多个物理线程的机器和网络）中实现高效利用。

这些功能产生了一种“进程导向”的编程形式，开发人员自然地将他们的计算分成许多协作和并行的组件，以实现他们的目标。虽然 Erlang 在主流计算领域并不是非常出名，但它在许多需要高性能的环境中被广泛使用：电话交换机、即时通讯服务如 WhatsApp 等。

ao 计算机直接继承了 Erlang 的面向进程方法。Erlang 的实证表明，通过进程传递消息而不共享内存来实现分布式计算的环境可以非常高效。ao 将这种方法应用到了智能合约领域，同时首次提供了 Erlang 式环境的单一系统映像。

智能合约平台（例如以太坊）

以太坊是一个去中心化的计算网络，所有用户共享内存和一个执行线程。最初是基于将图灵完备计算添加到区块链的想法，以太坊演变成了一个构建“世界计算机”的项目。

推出时，以太坊首次成功展示了无需信任的任意代码计算的能力 — — 这是在没有产生一个独立的区块链网络的情况下实现的。虽然该网络在用户和开发者中获得了巨大的关注，但自2015年推出以来，核心网络的吞吐量并未提高。

以太坊生态系统并没有试图将基础网络的扩展超过单个小线程执行的处理能力，而是转向了以 “rollup 为中心” 的路线图。

这种扩展方法侧重于支持附加的 “rollup” 网络，这些网络继承了以太坊的一些属性，但并非全部。截至撰写本文时，在以太坊生态系统中有 14 个 rollup 网络，这些程序后面的项目总价值超过 1 亿美元。

这 14 个 rollup 项目中的每一个代表了另一个可以并行执行的单线程（ao 术语中的一个“进程”）计算。

ao 从一开始就致力于构建一个从头开始专注于并行执行而不是共享内存的体系结构，为任意数量的独立进程提供了全新的架构，同时保持程序可以去中心化和去信任化。

去中心化计算市场（例如 Akash）

在像以太坊这样的传统智能合约平台上，共享线程架构限制了每个用户只能执行较小的计算任务。这种限制约束了网络上操作的复杂性和可扩展性。这种共享资源模型本质上限制了应用程序的可扩展性和效率，影响了更计算密集型智能合约的潜力。

一些网络旨在在去中心化环境中促进大规模计算，例如 Akash。与强调可验证和可重现计算的平台不同，Akash 和类似的网络提供了一个用于容器托管服务的去中心化市场。

这种方法允许在 x86 架构物理机器上执行传统的、非确定性的程序。然而，这种方法牺牲了创建去信任服务的能力，例如由智能合约支持的服务。

ao 允许开发者选择他们偏好的虚拟机（VM），初始参考实现专注于使用 WebAssembly（WASM）来执行进程。在 ao 中的 WASM 容器可以管理高达 4 GB 的内存，随着 WASM64 的采用，这一限制预计将会增加，从而使得长时间计算成为可能。

WASM 生态系统中丰富的编译工具支持多样化的程序。WASM 最近的使用示例包括在网络浏览器中执行大型语言模型（LLM）变换器模型、语音识别，甚至计算密集型的图像处理软件（如 Photoshop）。

ao 除了有显著的计算能力，得益于其全息状态机制，它甚至能保持传统智能合约的属性。ao并不就计算本身的状态达成共识，而是专注于确保交互日志被写入Arweave，并具备持久的可用性。

通过确定性的计费虚拟机以及所有进程消息在 Arweave 上的可用性，可以投射出一个“全息图”：状态可能尚未由任何参与者实际计算出来，但一旦计算完成，我们可以保证其输出始终是一致的。

此外，通过 Arweave 上的消息日志启用的全息状态系统，使得 ao 进程能够基于时间对隐含的消息做出响应，唤醒自身并执行动作。

结合其全息状态机制，ao 还提供了一个分布式的 Compute Units 计算单元网络，这些计算单元为用户提供关于计算结果的加密签名声明。这些计算节点在一个市场中相互竞争，降低了用户解析全息状态的成本。

点对点虚拟机托管（例如Urbit）

Urbit 是一个点对点计算系统，与 ao 有一些相似之处。Urbit 通过专注于交互日志的传输和可用性，能够提供一个分布式计算环境，在这个环境中，“服务器”可以从一个物理主机迁移到另一个。

在从一个主机切换到另一个主机的过程中，可以执行与托管计算的交互日志，以重新计算当前状态。Urbit 进程还可以相互发送消息以进行通信。

与 ao不同，Urbit 不对其交互日志达成去中心化的共识。实际上，这意味着没有对其 “rollup” 的权威性协议或确保其可用性——因此，其进程的状态也没有保证。

在这种情况下，Urbit 可以被视为与 Akash 和其他去中心化计算市场类似，但它具有额外的能力，可以在主机愿意过渡的情况下，以可验证的方式将计算从一个主机迁移到另一个主机。

ao 在这个模型的基础上进行了扩展，通过确保通过调度单元（SUs）向进程发送的日志消息可用，这些调度单元将它们上传到 Arweave。通过强制执行这个日志的可用性，用户进程是去中心化的——不再驻留在特定的计算节点上——允许它们的状态由分布式的计算单元（CUs）网络实时解决。

这种架构上的差异确保了 ao 进程具有必要的属性，使得可以部署无需信任的智能合约（可验证的去中心化计算），以及能够托管任意数量的进程。这后一种能力之所以出现，是因为进程仍然可以全息表示（它们的消息日志永久可用），而无需当前附加任何计算单元来执行它们。

灵活的信任和安全模型

正如本文档所述， ao 核心数据协议为安全计算提供了一个框架，但本身不提供或强制执行任何形式的经济保证。相反， ao 提供了一个灵活的加密安全元素系统，可以实现经济安全机制。

为了实现向用户提供经济安全的角色，正在开发 ao 质押合约和代币，该合约和代币能够经济上强制执行网络中单元的正确操作。

虽然这种机制的详细规范不在本数据协议定义的范围之内，但我们在下一节提供了一个蓝图，以说明如何在 ao 之上构建这样的系统。

进程的状态主要隐含在 Arweave 上存储的交互日志。虽然状态不被存储，但任何参与者都可以确定性地计算它。这种方法确保进程的状态虽然不能直接监测，但可以独立验证并且在整个网络中保持一致。