Arweave的AO学习

  • maodaishan
  • 更新于 2024-03-26 22:27
  • 阅读 1235

Arweave 的AO学习 - 架构

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

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

架构

核心概念:

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

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

  • 消息:与进程的所有交互都通过消息完成。消息符合ANS-104。消息介于UDPTCP数据包之间:保证仅传递一次,且这个传递会被处理(即:如果消息未被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达成的。

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

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
maodaishan
maodaishan
0xee37...1912
江湖只有他的大名,没有他的介绍。