撰文:protolambda,OP Labs 研究员
编译:Frank,Foresight News
为了创建最强大和安全的互操作性 Layer2 网络,Optimism Collective 正在通过许多不同的途径追求去中心化。
而 OP Stack 即将推出的防故障系统将是技术去中心化的一大一步,OP Stack 的开源和模块化设计正在为 L2 生态系统的社会去中心化创造了前所未有的舞台。
在本文中,我们将探讨社会去中心化原则,以及 L2 架构如何使 Layer 2 能够扩展这一原则以包括证明多样性和客户端多样性,并介绍 Optimism Collective 如何利用该架构构建其防故障系统。
受以太坊启发的「社会去中心化」
以太坊协议受益于社会去中心化,尤其是通过在解决方案中提供可选择性,使广泛的贡献者能够参与构建一个强大的去中心化网络。
对于节点软件而言,这意味着客户端多样性:拥有更多的客户端,那单点故障对验证者网络的影响就越小。
Layer1 的核心开发者将这种贡献模式描述为「集市」(bazaar),它喧闹且看似混乱,但却非常高效且充满活力。通过采用彻底开放式的协议开发方法,可以使最广泛的贡献者参与并改进协议。
而 Optimism Collective 具有独特的优势,可以实施和迭代以太坊实现社会去中心化的方式:OP Stack 通过提供开放规范和 MIT 许可证下的开源软件来实现社会去中心化,并且 Optimism Collective 可通过创建超级链对其进行迭代。
对 L2 架构的更详细了解
以太坊在 L1 具有开放的规范,以及将共识层和执行层分开的模块化客户端架构。
OP-Stack 在 L2 上实现了相同的架构:
共识层由 op-node 和 Magi 提供支持,这两个客户端遵循 L1 并导出执行输入;
执行层由 op-geth、op-erigon 和 op-reth 提供支持;
然而,L2 架构在此堆栈中添加了一个新层:验证层(proving layer)。
这是将 L2 输出安全地桥接回 L1 的层级,正如拥有多个客户端是确保在 L1 和 L2 上达成共识和执行的最佳实践一样,对于 L2 的验证层来说,采用多种证明方法可以确保最佳安全性。
类似于具有不同客户端的验证者们达成共识,链上证明的法定数量可以表明 L2 状态声明已经以不同方式得到验证,从而大大降低了错误导致完全失败的可能性。
目前共有三种常见的证明类型:证明(attestations)、错误证明(也称为欺诈证明)和零知识有效性证明。后两者共享一个常见模式,它们以同步形式表达 L2 状态转换,并在给定 L1 数据和 L2 前状态作为输入时,证明其执行。
隔离证明系统组件以实现证明多样性
证明系统可以进一步分解为独立的组件:
- 一个「程序」,定义了同步的 L2 状态转换;
- 一个「虚拟机」(VM),运行并验证该程序;
- 一个「预映像预言机」(pre-image oracle),将 L1 数据和 L2 预状态作为输入;
今天的许多零知识证明仍然在紧密地耦合这些组件,创建了一个在单一 L1 交易数据上运行的 ZK-EVM。然而,OP 堆栈将它们解耦以隔离复杂性,并实现客户端的多样性,从而使整体更加强大。
交互式故障证明将二分游戏(bisection-game)添加到虚拟机跟踪中,以验证链上的证明,而基于虚拟机的零知识证明则对执行进行算术化和折叠,并提供有效性证明。(请参阅 Risc0 和 O(1)-Labs 正在设计以响应 Optimism ZK RFPs 的基于虚拟机的零知识证明)。
该程序将实际的状态转换定义为「客户端」,将输入获取(L1 数据和 L2 预状态)定义为「服务器」。该程序在没有虚拟机的情况下,与服务器 / 客户端独立运行,这与常规区块链节点非常相似,并且共享了大量代码。
例如,Go op-program 客户端是通过从 op-geth 导入 op-node 的派生和 EVM 来构建的,而服务器则从 L1 和 L2 以太坊 RPC 获取其数据。
FPVM 的功能概述
故障证明虚拟机(FPVM)是 OP Stack 中故障证明堆栈的模块之一。
除了提供正确的接口(尤其是与预映像预言机相关的接口),该虚拟机没有实现任何特定于以太坊或 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 以及开源社区的无限创造力的发展,通过测试实施和参与漏洞赏金计划,将有许多额外的机会为堆栈做出贡献。