超并行计算机-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 的结果。

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

没有预言机？都是预言机！

当数据需要和区块链需要交互时，我们需要预言机，将“神谕”附加到链上。区块链需要的预言机，是由一群用户进行多重签名产生的神谕；人类需要的预言机神谕，来自区块链算法产生的共识，但是当人去阅读这个共识时，往往需要第三方传谕，这个第三方一般叫做 infura.io 。我们一般会信赖 infura 的传谕，那么这个传谕保真吗？（这瓜保熟吗？）

需要注意：

• BTC/ETH 的信任仅仅局限于链上环境内部，对于链外环境很难提供去信任化能力。即，用户请求 BTC/ETH 节点，仅能通过 http 协议获得状态，用户无法判断请求的节点是否可信，状态是否正确。如果要进行状态验证，用户必须运行轻节点或者全节点。
• 在 AO/SCP 网络中，用户的请求需要签名，节点返回的状态也需要签名，所有记录都存储在 Arweave 上形成“全息数据”，保证可验证性。用户无需运行任何节点也可以获得可信状态。在 AO/SCP 模式下，网络的所有信息都是上链的，甚至包括了查询和返回这些请求信息（http 请求不上链）。AO 解决了去信任化最后一公里的问题。

在工程实践上，AO/SCP 打破了链上/链下的概念，将可信计算和预言机二者整合成了一个统一的系统。该系统具备去中心化的特性，打破了 Web2 和 Web3 的边界。AO/SCP 和链上计算是两个完全截然不同的范式。或可把这套系统看成一个完全由预言机组成的全球计算机，预言机呈现的神谕则是不可篡改的客观事实。

弹性验证

不知从什么时候起，共识成为了一个二元问题。要么有共识要么没有共识。就没有一种中间的共识？

这种认知体现在区块链行业中。要么是个神，要么是个渣。一如宗教信仰，非此即彼，水火不容。

但是 AO 提供了完全不同的共识架构—— 由 Arweave 永存和 SCP 范式提供坚实的共识基础，也就是我们反复提及的「可验证性」，但应用方花多少代价去验证这个共识则是弹性的。

事情的起因是 X 上一直有人陷入上文所说的两类争议中。在一番口水战后终于问到两个 AO 线程之间如何验证 msg。所有的 msg 都有签名这里就不再赘述。但是 Process 怎么知道收到的 msg 是可以信任的？下面是模拟了两个信任模式用于解释这个问题。

有计算单元 CU1，其中运行了 P1 和 P2 两个进程，表示为 CU1(P1, P2)。

现在有：CU1(P1, P2) & CU2(P3, P4) & CU3(P1) & CU4(P1) 。

计算目标：CU2 中的 P3 请求 P1 提供可信的计算信息。

单信任模式

1. P3 中的代码向 P1 发出计算请求。

2. SU 调度器将 P3 的请求分派给 CU4(P1) 进行计算。

3. CU4(P1) 响应计算结果，返回 P3。

此时 P3 完全信任 CU4 中的 P1 计算结果，并继续进行运算。

多信任模式

1. P3 中的代码向 P1 发出计算请求，同时 P3 要求 SU 分配多个计算单元。

2. SU 将 P3 的请求分配给 CU1(P1)，CU3(P1)， CU4(P1)。

3. CU1(P1)，CU3(P1)， CU4(P1) 响应计算结果。

此时 P3 收到了多个结果，P3 可以对这些结果先进行比较，通过比较判断是否可信。例如 P3 要求所有节点返回的内容完全相等。或者，P3 要求 2/3 的结果完全相等。

信任模式只是 AO 上的一种开发模式，开发者可以根据信任的需求开发判断规则。P3 的程序甚至可以要求 100 个 CU 进行计算，并要求 100 个 CU 计算结果完全一致。这完全取决于开发者如何实现 P3 中的代码。

因此，你可以自己决定你需要的信任模式和验证支出。但是，记住，最终的共识安全仍然是由 Arweave 永存与 SCP 保障的！