作者: 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 保障的!