解读OP Stack将推出的防故障系统:受以太坊启发 技术去中心化的一大步

2023-09-28 08:43

免责声明 免责声明:内容来源于网络收集,不构成任何投资建议!

作者:protolambda,OP Labs 研究员;编译者:弗兰克,前瞻新闻

为了创建最强大、最安全、可互操作的第2 层网络,Optimism Collective 正在通过许多不同的途径追求去中心化。

OP Stack 即将推出的故障安全系统将是迈向技术去中心化的重要一步。 OP Stack的开源和模块化设计正在为L2生态系统的社会去中心化创造前所未有的舞台。

在本文中,我们探讨了社会去中心化的原则,L2 架构如何使Layer 2 能够扩展该原则以包括证明多样性和客户端多样性,并描述Optimism Collective 如何利用该架构来构建其故障安全系统。

受以太坊启发的「社会去中心化」

以太坊协议受益于社会去中心化,特别是通过提供解决方案的选择性,使广泛的贡献者能够参与构建强大的去中心化网络。

对于节点软件来说,这意味着客户端多样性:拥有的客户端越多,单点故障对验证器网络的影响就越小。

Layer1的核心开发人员将这种贡献模型描述为“集市”,这里嘈杂且看似混乱,但非常高效和动态。通过采用完全开放的协议开发方法,最广泛的贡献者可以参与并改进协议。

Optimism Collective 在实施和迭代以太坊的社会去中心化方法方面具有独特的优势:OP Stack 通过在MIT 许可下提供开放规范和开源软件来实现社会去中心化,而Optimism Collective 则可以通过创建超级链迭代来实现社会去中心化。

对 L2 架构的更详细了解

以太坊在L1 上有开放的规范,以及将共识层和执行层分开的模块化客户端架构。

OP-Stack 在L2 上实现了相同的架构:

共识层由op-node 和Magi 提供支持,这两个客户端遵循L1 并导出执行输入;

执行层由op-geth、op-erigon 和op-reth 提供支持;

然而,L2 架构在此堆栈上添加了一个新层:证明层。

这是将L2 输出安全地桥连接回L1 的层,就像拥有多个客户端是确保L1 和L2 上达成共识和执行的最佳实践一样,对于L2 的验证层,使用多种证明方法可以确保最佳安全性。

与不同客户端的验证者达成共识的方式类似,链上证明的法定数量可以表明L2 状态声明已经以不同的方式得到验证,从而大大减少了导致彻底失败的错误机会。

目前常见的证明类型有三种:证明、错误证明(也称为欺诈证明)和零知识有效性证明。后两者有一个共同的模式,即它们以同步形式表达L2 状态转换,并在给定L1 数据和L2 预状态作为输入的情况下证明它们的执行。

隔离证明系统组件以实现证明多样性

表明系统可以进一步分解为独立的组件:

定义同步L2 状态转换的“程序”;

用于运行和验证程序的“虚拟机”(VM);

以L1 数据和L2 预状态作为输入的“原像预言机”;

当今的许多零知识证明仍然紧密耦合这些组件,创建在单个L1 交易数据上运行的ZK-EVM。然而,OP 堆栈将它们解耦,以隔离复杂性并实现客户端多样性,使整个事情更加健壮。

交互式故障证明将二分游戏添加到虚拟机痕迹中以验证链上证明,而基于虚拟机的零知识证明算法并折叠执行并提供有效性证明。 (请参阅Risc0 和O(1)-Labs 正在设计的基于虚拟机的零知识证明,以响应Optimism ZK RFP)。

该程序将实际状态转换定义为“客户端”,将输入采集(L1 数据和L2 预状态)定义为“服务器”。该程序独立于服务器/客户端运行,无需虚拟机,很像常规的区块链节点,并且共享大量代码。

例如,Go op-program 客户端是通过从op-geth 导入op-node 的fork 和EVM 构建的,而服务器则从L1 和L2 以太坊RPC 获取数据。

FPVM 的功能概述

故障证明虚拟机(FPVM)是OP Stack中故障证明堆栈的模块之一。

除了提供正确的接口(特别是与原像预言机相关的接口)之外,该VM 没有实现任何特定于以太坊或L2 的功能,并且在FPVM 内运行的故障证明程序(FPP)客户端用于表达L2 状态转换部分。

通过这种分离,虚拟机保持极简:对以太坊协议的更改(例如添加EVM 操作码)不会影响虚拟机。

相反,当协议发生变化时,FPP可以简单地

单地更新以导入节点软件中的新状态转换组件,类似于在同一游戏主机上玩新版本的游戏,L1 证明系统可以更新以证明不同的程序。

虚拟机负责执行低级指令,需要模拟 FPP。虚拟机要求较低:程序是同步进行的,并且所有输入都通过相同的预映像预言机加载,但所有这些仍然必须在 L1 EVM 链上得到证明。

为了做到这一点,每次只能证明一个指令。二分游戏(bisection-game)将把证明完整执行跟踪的任务缩小到只有一个指令。

对于每个 FPVM 来说,指令证明可能看起来不同,但通常看起来与 Cannon 类似,它证明指令如下:

  • 为了执行该指令,虚拟机模拟类似于线程上下文(thread-context)的指令周期的东西:从内存中读取指令、进行解释,并且寄存器文件和内存可能会发生一些变化;

  • 为了支持预映像预言机以及内存分配等基本程序运行时的需求,执行还支持 Linux 系统调用的子集。读 / 写系统调用允许与预映像预言机进行交互:程序将哈希作为请求写入,以获取预映像,然后按一小块一小块地每次进行读取;

Cannon,第一个 FPVM,就是以这种方式实现了 MIPS 虚拟机。有关虚拟机的更多信息,请参阅相关文档和 cannon-specs。FPVM 与 FP 程序之间的接口是标准化的,并在规范中有所记录。

从 FPVM 到 ZKVM

故障证明不是唯一类型的状态转换证明,ZK 有效性证明是一个有吸引力的选择,因为它具有快速跨链桥接的潜力(由于 ZK 有效性证明没有链上挑战游戏,所以没有争议窗口)。为了支持先进的以太坊堆栈并托管不同的客户端实现,我们仍然需要将虚拟机和程序解耦。

这是 ZK RFP 项目采取的方法,以证明一个最小的 RISC-V(由 Risc0)或 MIPS(由 O(1) Labs)虚拟机可以托管与故障证明中使用的相同程序。

支持 ZK-VM 确实需要进行一些小的调整,使得预映像预言机能够以非交互方式加载数据,但通过将虚拟机通用化,ZK 证明在面对 OP Stack 变化时更具未来性。

外部贡献者的机会

OP Stack 欢迎额外的虚拟机和程序选项,以及额外的独立证明系统,从证明到零知识证明。就像客户端多样性一样,证明多样性是一个集体努力的结果。

目前正在进行中的对 OP Stack 证明层的补充包括:

  • 由 protolambda 开发的基于 Go 语言编写的 RISC-V FPVM「Asterisc」;

  • 由 Base 和 OP Labs 贡献者共同构建的基于 Magi 和 op-reth 的 rust FP 程序;

  • 由 Risc0 构建的基于 zeth(ZK-reth 分支)的 rust ZK 程序;

随着 Cannon、op-program、bisection-game 以及开源社区的无限创造力的发展,通过测试实施和参与漏洞赏金计划,将有许多额外的机会为堆栈做出贡献。