Arweave 的AO学习 - 架构
文档:https://ao.arweave.dev/#/spec
本文主要基于对AO白皮书的翻译和筛选。
核心概念:
除了从用户钱包接收消息外,还可以从MU转发来自其他进程的消息。项目方可选择如何确定消息可信度。
用Pi来代表第i个进程,定义:Pi=(Logi,Initi,*Envi),其中:
需注意,由于AO专注于为去中心化和可验证的计算提供通用模型,所以它不局限于特定虚拟机和参数。当开发人员在AO上创建进程时,他需要确定这些待定内容,如:
Pi在给定时间点的状态S(Pi) = F(Logi, Envi),其中F是由Envi定义的函数。针对新发送的Msg的输出: Outboxm = F (Logi, Envi, m),其中m就是要计算输出的msg。(这里F(Logi, Envi)里的Envi,我觉得应该是Initi,不知道是不是原文错误)。
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)的动作:
其中
代表SU pi对msg和nonce的签名
用SSUpi代表SUpi的stake,在以下场景下,它会被slash:
1.4 CU (Computing Unit)
CU使用由Envi定义的虚拟机,针对mj,执行Pi的转换函数:
其中:ΦPi表示新的状态,Outboxj表示输出信息集,Attestj表示签名的对计算的证明 如果其他方证明Attestj不正确,则发现方有权发起一个对该CU的slash.随后,MU将采纳这个结果。
1.5 Messenger Unit (MU)
MU为用户传送消息。工作流如下
当CUi对上个消息的处理都完成后,递归结束。对本次用户调用结束给出一个签名
消息被Push(MUm,m),接收侧会根据对消息的验证情况决定如何处理
如果被发现MUm签署发送的是无效交易,则会引发对其slash。
目前测试网中,CU,MU,SU都已实现。初始实现提供:
ao-lib
),旨在允许轻松开发ao
.aos
),允许用户通过 Lua 命令行界面与系统交互并操作系统。注意:CU,MU,SU的服务是付费的,P3支付通道。代币:AO 文档中描述了各种消息的格式,req, response等,此处略。
AO是一个构建在Arweave上的计算层,它的方式跟铭文比较像。 与以太坊的差别就是,AO可以对交易历史(也就是区块)有共识,但不会对当前状态有共识。所以跟铭文和indexer的方式是一样的。 一个进程就相当于一个DApp,所有的从用户端发起的交易,从其他进程发来的消息,以及定时任务发起的消息,都会被排序后(通过nonce)记录到Arweave上;同时这些消息的处理结果也会被记录到Arweave上。 状态是通过CU计算出来,并应用的。CU是一个去中心化的算力网络,提供CPU和内存服务。 网络的安全性是通过stake和slash达成的。
通过以上信息,理解起来就很容易了,所以就不赘述其他内容了。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!