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

作者：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 导入 o​​p-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 以及开源社区的无限创造力的发展，通过测试实施和参与漏洞赏金计划，将有许多额外的机会为堆栈做出贡献。