AO —— 你无法想象的超并行计算机

来源：PermaDAO

这是一篇关于技术的零碎文字，甚至不能成为一篇文章。随意的聊一聊 AO。

全球共享硬盘

20 年 7 月初次了解到 Arweave，第二周我们就在咖啡厅讨论了去信任化计算的可能性。设想：Arweave 是图灵机的纸带，无处不在的状态机是用户手中的客户端，用户的操作系统和所有运行的程序都会从 Arweave 上下载。全球无处不在的计算单元，他们共享一个巨大的区块链硬盘。运行在这套体系下的所有的应用都可以获得共识和去信任化。

讨论的结论是这个目标很难实现，显然微软和苹果等巨头不可能将操作系统和应用程序放到 Arweave 上。

如今 AO 实现了这一切。最初和 Sam 设计 MSG Protocol（AO 原型）时，我认为这是一个区块链上的 kafka。然而，重点不是为应用提供去中心化消息队列，而是将 C/S 架构中的 http 通讯替换为去信任化的 msg 通讯。如果用户的 request 和服务器的 response 都使用了 AO。那我们将在 AO 上重新创造一个真正的去中心化互联网生态，一如 20 年 7 月的设想。

AO 具备将整个互联网搬到 Arweave 上的巨大潜力。Arweave 这座亚历山大的图书馆不再局限于存储，它不仅记录了过去。使用 AO 我们可以记录今天的故事，使用去中心化的方式分配未来的价值。

争议

最近关于 AO 出现争议点，主要是两个问题：

1. AO 是如何实现可验证性的？

首先，AO 是不解决可验证性问题。可验证性来自 Arweave 的不可变存储。Arweave 存储了 AO 每一个 Process 的全息数据（包括 AO 本身的全息数据）。任何人可以通过全息数据恢复 AO 和 AO 上的任何一个线程。这由数学进行保证，具备可验证性！这是基于存储的共识范式，我们常提的 SCP 理论。

重点：我们知道 UTXO 的交易是验证后上链，但是 SCP 范式下不管是好的坏的数据都上链 AR，这就和 BTC 的 UTXO 出现了非常大的差异化。但是重复上链、双花上链就不具备可验证性吗？SCP 程序只需要把全息交易全部跑一遍就可以验证了！如果是重复的交易会被 SCP 程序抛弃。

可验证，强调的是“可”，无需强调快速验证，轻节点验证等等。如果把可验证和快速验证、轻节点验证混淆。此时就无法讨论 AO 了。

2. SCP 应用有可验证特性，那么 AO 是如何解决可以验证问题的？需要用户跑全节点？

当第一个问题得到一定的解答后，提问者会思考用户必须计算全账本，这个太难了。这里和 BTC/ETH 的默克尔树要解决的问题相违背，在 BTC/ETH 的思路下默克尔是验证的核心，默克尔的 root 通过 PoW 上链，所以才可以验证。现在你竟然告诉我 AO 没有默克尔树？所以结论就是 AO 根本不能验证，没有共识，是骗局！于是回到了问题 1。一般提问者会在这两个问题上循环提问，就不会去思考 AO 的设计架构和原理了。

重点：AO 不解决可验证问题，AR 和 AO 的职能是完全拆分开的！AR 做不可变存储，保证安全性和可验证性，这里有默克尔，也有共识，共识的是数据顺序，而不是数据计算的状态。AO 只做计算，对 AR 上具备顺序的数据进行计算并生成状态，AO 无法更改 AR 的数据顺序，即 AO 无法更改共识。通过 PoW/PoS 对计算出的状态进行验证，这是链上计算范式，和 SCP 截然不同。

AO 的功能是对不可变数据进行计算，并展示这些计算的状态。可验证性问题由 SCP 保障，所以不需要默克尔树，也不需要 PoW/PoS，此时提问者再次回到了问题 1，无法继续思考。如果看到这里你还能思考，那么请看 AO 的实践：

AO 通过 SCP 实现了一个可验证的 Token，用该 Token 的经济模型促使大家提供正确的数据展示（有点像 Chainlink 预言机）。记住 AO 主要做状态呈现，可验证性不是 AO 的职能。该 Token 经济模型是：在不呈现正确状态时进行罚没（slash），在提供正确状态时进行激励（mint）。

关键点

AO 又不产生共识，如何进行 slash 和 mint 动作？很简单，AO 是一个 SCP 应用，此时查询状态和返回状态两个事件都上链到 Arweave，AO SCP 程序会加载到这两个事件（查询和返回），通过对这两个事件计算出 mint 和 slash 的结果。

这部分直接看代码更容易理解：

https://github.com/outprog/slash-demo/blob/main/vm/vm_test.go

结论

用户不需要跑一个应用的全节点，会有服务商去跑 CU（计算单元）。用户向 AO 提出一个查询请求，该请求通过 SU（调度单元）分配到特定的 CU。计算单元按照用户的请求计算状态，该状态由计算节点签名（也上链），反馈到用户用。用户如果不信任单个 CU，可以向更多的 CU 发起请求，获得更多可信状态。每个 CU 返回的状态都由 CU 节点进行签署（可验证）。如果 CU 提供了错误状态，CU 的质押将被罚没。