文档：https://ao.arweave.dev/#/spec

本文主要基于对AO白皮书的翻译和筛选。

架构

核心概念：

• 进程：进程由两个东西表示：
• • 初始化数据：定义其所需的计算环境（虚拟机、调度程序、内存需求和必要的扩展）
  • Arweave上的消息日志

除了从用户钱包接收消息外，还可以从MU转发来自其他进程的消息。项目方可选择如何确定消息可信度。

• 消息：与进程的所有交互都通过消息完成。消息符合ANS-104。消息介于UDP和TCP数据包之间：保证仅传递一次，且这个传递会被处理（即：如果消息未被MU转发——或者接收者未处理它——那么就不算传递过）。
• SU (Scheduler Units)：SU负责把原子自增的槽编号（slot numberings)分配给进入进程的消息，分配完成后，确认消息被上传至Arweave。进程可以选择它使用的SU，可以是去中心化，中心化的，甚至user-hosted。
• CU（Compute Units）:CU是用户或MU可以选择的，用来计算进程的状态的计算单元。这是个市场，因为SU只负责把消息编号后存到Arweave，而CU提供了计算状态的收费服务。CU之间是竞争关系，用户可以在价格，需求等参数的考虑下选择CU。一旦状态计算完成，CU将会返回给调用者一个针对特定消息的，签过名的验证过的输出；CU也可以被要求对外公开这个输出（ UDL 费用），以供其他节点加载。
• MU (Messenger Units)：MU是一种在AO网络里传输消息的节点，它依照一个叫cranking的进程来工作。它会将消息发送到合适的SU，然后与CU配合工作来产生输出。它会对每个发件箱递归的进行这个流程，直到发件箱为空。用户和进程可以付费订阅，从而产生定时事件（也就是定时触发，而不是必须由用户触发）。进程也可以把消息设置为cast (投掷）模式，这样消息会被发送给SU，但不会返回响应。这些特性给了用户和进程很多灵活性，比如VM, 支付方式，调度方式等。

进程 Process

用Pi来代表第i个进程，定义：Pi=(Logi,Initi,*Envi），其中：

• Logi代表Pi的所有排序的message
• Initi代表Pi的Pi的初始化数据
• Envi代表Pi的计算环境
• Schedi代表Pi的排序器Scheduler

需注意，由于AO专注于为去中心化和可验证的计算提供通用模型，所以它不局限于特定虚拟机和参数。当开发人员在AO上创建进程时，他需要确定这些待定内容，如：

• 进程可用的最大内存
• 处理单个Msg时可用的最大操作数（就像区块的gas limit）
• 虚拟机相关信息，如进程所需的虚拟机扩展（如对本地文件的访问等）

Pi在给定时间点的状态S(Pi) = F(Logi, Envi)，其中F是由Envi定义的函数。针对新发送的Msg的输出: Outboxm = F (Logi, Envi, m)，其中m就是要计算输出的msg。（这里F(Logi, Envi)里的Envi，我觉得应该是Initi，不知道是不是原文错误)。

消息Message

Mij代表Pi的第j个msg，Mij是符合ANS-104的数据项。这个消息的投递状态D(Mij)：

Msg使用最多投递一次策略。另外由于msg都被作为log记录在Arweave，所以任意未被投递的msg，都可以被保证投递到Pi，并计算出它的输出

1.3 Staking

每个Unit都需要stake一定的token来保证安全性，作恶时stake的token会被罚没。

1.4 Scheduler Units (SU)

当进程Pi收到一个msg时，它的SU（记为SUpi)的动作：

1. Assignment，SUpi会给m指定一个nonce，来代表这个m在这个Pi里的消息顺序。这个Assignment表示为：

其中

代表SU pi对msg和nonce的签名

1. Persistence，msg和签名（我想应该是assignment)会被保存到Arweave。

用SSUpi代表SUpi的stake，在以下场景下，它会被slash：

• 没有对m签名，或丢弃了m （即审查攻击，但如何发现这个问题呢？）
• 如果做了签名，但没有成功保存到Arweave，导致Pi的log里发生了gap.
• 针对同一个nonce，对不同的msg进行了签名。

1.4 CU (Computing Unit)

CU使用由Envi定义的虚拟机，针对mj，执行Pi的转换函数：

其中：ΦPi表示新的状态，Outboxj表示输出信息集，Attestj表示签名的对计算的证明 如果其他方证明Attestj不正确，则发现方有权发起一个对该CU的slash.随后，MU将采纳这个结果。

1.5 Messenger Unit (MU)

MU为用户传送消息。工作流如下

1. MU从用户或客户端接收到消息mi
2. mi被发送到Scheduler SUk,签名并发布，
3. MUm要求一个被选中的CUi给出确认的执行结果λ(Pi,mi)到outbox
4. 如果Outbox中还有其他消息（注意是outbox，应该是msg的操作结果对当前或其他进程产生了消息要处理），则对消息签名，发给合适的SU，递归地处理完这些消息。

当CUi对上个消息的处理都完成后，递归结束。对本次用户调用结束给出一个签名

消息被Push(MUm,m)，接收侧会根据对消息的验证情况决定如何处理

如果被发现MUm签署发送的是无效交易，则会引发对其slash。

参考实现

目前测试网中，CU,MU,SU都已实现。初始实现提供：

• 基于 WASM 的虚拟机环境，最高支持 4 GB RAM。
• 编译为 WASM 的Lua 运行时环境 ( ao-lib)，旨在允许轻松开发ao.
• 一种操作系统环境 ( aos)，允许用户通过 Lua 命令行界面与系统交互并操作系统。
• 权威证明 (PoA) 风格的消息传递服务。
• 自托管调度程序的能力以及所有人都可以使用的开放 PoA 网络

注意：CU,MU,SU的服务是付费的，P3支付通道。代币：AO 文档中描述了各种消息的格式，req, response等，此处略。

总结

AO是一个构建在Arweave上的计算层，它的方式跟铭文比较像。 与以太坊的差别就是，AO可以对交易历史（也就是区块）有共识，但不会对当前状态有共识。所以跟铭文和indexer的方式是一样的。 一个进程就相当于一个DApp，所有的从用户端发起的交易，从其他进程发来的消息，以及定时任务发起的消息，都会被排序后（通过nonce）记录到Arweave上；同时这些消息的处理结果也会被记录到Arweave上。 状态是通过CU计算出来，并应用的。CU是一个去中心化的算力网络，提供CPU和内存服务。 网络的安全性是通过stake和slash达成的。

通过以上信息，理解起来就很容易了，所以就不赘述其他内容了。