本文探讨了社会去中心化原则及 L2 架构如何使 Layer2 能够扩容这一原则，并介绍了 Optimism Collective 正在如何利用该架构构建其防故障系统。本文源自 OP Labs 研究员 protolambda 所着文章 《Social Decentralization & the OP Stack’s Fault Proof Virtual Machine》，由 Foresight News 编译、整理。
（前情提要：Layer2模组化战争：OP Stack vs. ZK Stack，谁能赢？ ）
（背景补充：疯狂多链宇宙｜OP Stack如何靠「一键建立Layer2」颠覆市场 ）
本文目录
为了建立最强大和安全的互操作性 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 上实现了相同的架构：
然而，L2 架构在此堆叠中添加了一个新层：验证层（proving layer）。
这是将 L2 输出安全地桥接回 L1 的层级，正如拥有多个客户端是确保在 L1 和 L2 上达成共识和执行的最佳实践一样，对於 L2 的验证层来说，采用多种证明方法可以确保最佳安全性。
类似於具有不同客户端的验证者们达成共识，链上证明的法定数量可以表明 L2 状态宣告已经以不同方式得到验证，从而大大降低了错误导致完全失败的可能性。
目前共有三种常见的证明型别：证明（attestations）、错误证明（也称为欺诈证明）和零知识有效性证明。後两者共享一个常见模式，它们以同步形式表达 L2 状态转换，并在给定 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 类似，它证明指令如下：
Cannon，第一个 FPVM，就是以这种方式实现了 MIPS 虚拟机器。有关虚拟机器的更多资讯，请参阅 相关文件 和 cannon-specs 。FPVM 与 FP 程式之间的介面是标准化的，并在 规范 中有所记录。
从 FPVM 到 ZKVM
故障证明不是唯一型别的状态转换证明，ZK 有效性证明是一个有吸引力的选择，因为它具有快速跨链桥接的潜力（由於 ZK 有效性证明没有链上挑战游戏，所以没有争议视窗）。为了支援先进的以太坊堆叠并托管不同的客户端实现，我们仍然需要将虚拟机器和程式解耦。
延伸阅读：从Type1到Type4，各类型ZK-EVM的差异在哪？
这是 ZK RFP 专案采取的方法，以证明一个最小的 RISC-V（由 Risc0）或 MIPS（由 O (1) Labs）虚拟机器可以托管与故障证明中使用的相同程式。
支援 ZK-VM 确实需要进行一些小的调整，使得预映像预言机能够以非互动方式载入资料，但通过将虚拟机器通用化，ZK 证明在面对 OP Stack 变化时更具未来性。
外部贡献者的机会
OP Stack 欢迎额外的虚拟机器和程式选项，以及额外的独立证明系统，从证明到零知识证明。就像客户端多样性一样，证明多样性是一个集体努力的结果。
目前正在进行中的对 OP Stack 证明层的补充包括：
随着 Cannon、op-program、bisection-game 以及开源社群的无限创造力的发展，通过测试实施和参与漏洞赏金计划，将有许多额外的机会为堆叠做出贡献。
📍相关报导📍
技术》BNB Chain 新推出的L2「opBNB」是什麽？
OP Stack如此抢眼，ZK Stack和Starknet Stack的机会在哪？
OP Rollup挑战机制从没出现挑战：Optimism的验证是否太「乐观」？