作者： outprog
审阅：0xmiddle
这是一篇关于技术的零碎文字，甚至不能成为一篇文章。随意的聊一聊 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 的质押将被罚没。具体的实践查看 Sam 的 X https://twitter.com/samecwilliams/status/1764023657058148718 。
没有预言机？都是预言机！
当数据需要和区块链需要交互时，我们需要预言机，将“神谕”附加到链上。区块链需要的预言机，是由一群用户进行多重签名产生的神谕；人类需要的预言机神谕，来自区块链算法产生的共识，但是当人去阅读这个共识时，往往需要第三方传谕，这个第三方一般叫做 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 提供可信的计算信息。
单信任模式
- P3 中的代码向 P1 发出计算请求。
- SU 调度器将 P3 的请求分派给 CU4(P1) 进行计算。
- CU4(P1) 响应计算结果，返回 P3。
此时 P3 完全信任 CU4 中的 P1 计算结果，并继续进行运算。
多信任模式
- P3 中的代码向 P1 发出计算请求，同时 P3 要求 SU 分配多个计算单元。
- SU 将 P3 的请求分配给 CU1(P1)，CU3(P1)， CU4(P1)。
- CU1(P1)，CU3(P1)， CU4(P1) 响应计算结果。
此时 P3 收到了多个结果，P3 可以对这些结果先进行比较，通过比较判断是否可信。例如 P3 要求所有节点返回的内容完全相等。或者，P3 要求 2/3 的结果完全相等。
信任模式只是 AO 上的一种开发模式，开发者可以根据信任的需求开发判断规则。P3 的程序甚至可以要求 100 个 CU 进行计算，并要求 100 个 CU 计算结果完全一致。这完全取决于开发者如何实现 P3 中的代码。
因此，你可以自己决定你需要的信任模式和验证支出。但是，记住，最终的共识安全仍然是由 Arweave 永存与 SCP 保障的！
APP 
