OP Stack 全貌
OP Stack 是一个用于构建 L2 区块链生态系统的常见开发堆栈，由 Optimism Collective 构建以支持 Optimism。
OP Stack 最好被视为 Optimism Collective 维护的一组软件组件，这些组件要么帮助定义堆栈的新层次，要么作为堆栈内的模块适应其中。
由于 OP Stack 是一个正在进行中的工作，不同层次和模块的景观仍在不断演变。本页面概述了堆栈的不同概念层次，介绍了一些适应这些层次的模块。这并不包括未来可能存在的所有模块或层次，但可以很好地概述 OP Stack 当前的景观。
如果您对了解 OP Stack 的最新“生产”版本感兴趣，即经过高度测试并准备好进行实际操作的堆栈组件，请查看关于 Bedrock Release 的页面。
Note
请注意，本页面描述的并非所有模块都已经处于生产状态 - 这些模块明确标记为“正在开发”或“提议”
# 现有景观
# 层次结构
# 数据可用性
数据可用性层定义了 OP Stack 基于链的原始输入数据发布的位置。OP Stack 链可以使用一个或多个数据可用性模块来获取其输入数据。因为 OP Stack 链是从数据可用性层派生的，所以所使用的数据可用性模块对系统的安全模型有重要影响。例如，如果某个数据无法从数据可用性层检索，可能无法同步链。
# 以太坊 DA
以太坊 DA 目前是 OP Stack 最广泛使用的数据可用性模块。使用以太坊 DA 模块时，源数据可以从以太坊区块链上的任何可访问信息派生。这包括以太坊 calldata、事件和 4844 数据块。
# 排序
排序层确定了 OP Stack 链上的用户交易如何被收集并发布到正在使用的数据可用性层模块。在 OP Stack 的默认 Rollup 配置中，排序通常由单个专用的排序器处理。派生层中定义的规则通常限制了排序器在特定时间段内保留交易的能力。在未来的提案中，排序将是模块化的，这样链可以轻松选择和更改控制其当前排序器的机制。
# 单一排序器
OP Stack 的默认排序器模块是单一排序器模块，其中一个专用的参与者被赋予了充当排序器的能力。单一排序器模块允许治理机制决定在任何给定时间谁可以充当排序器。
# 多个排序器（提议）
对单一排序器模块的简单修改是多个排序器模块，其中排序器在任何给定时间从预定义的一组可能的参与者中选择。基于 OP Stack 的各个链将能够确定定义可能排序器集合的确切机制以及从集合中选择排序器的机制。
# 派生
派生层定义了数据可用性层中的原始数据如何被处理以形成发送到执行层的经过处理的输入，通过标准的 Ethereum Engine API (opens new window)。派生层还可以使用执行层定义的当前系统状态来解析原始输入数据。派生层可以根据许多不同的数据源派生 Engine API 输入。派生层通常与数据可用性层密切相关，因为它必须了解如何解析任何原始输入数据。
# Rollup
Rollup 模块从以太坊区块数据、排序器交易批次、存款交易事件等中派生 Engine API 输入。
# 索引器（提议）
索引器模块是一个提议的派生层模块，它将在特定智能合约发送交易、发出事件或修改存储时派生 Engine API 输入，这些智能合约位于类似以太坊 DA 的数据可用性层模块上。
# 执行
执行层定义了 OP Stack 系统中的状态结构，并定义了改变该状态的状态转换函数。当从派生层通过 Engine API 接收到输入时，将触发状态转换。执行层的抽象打开了对 EVM 修改或完全不同底层 VM 的可能性。
# EVM
EVM 是一个执行层模块，它使用与以太坊虚拟机相同的状态表示和状态转换函数。OP Stack 的以太坊 Rollup 配置中的 EVM 模块是一个轻微修改的 EVM 版本，它增加了对在以太坊上发起的 L2 交易的支持，并为每个交易添加了额外的 L1 数据费用，以应对将交易发布到以太坊的成本。
# 结算层
结算层是外部区块链上的机制，用于在这些外部链上（包括其他 OP Stack 链）建立对 OP Stack 链状态的“视图”。对于每个 OP Stack 链，可能存在一个或多个结算机制在一个或多个外部链上。结算层机制是“只读”的，允许区块链外的参与方根据 OP Stack 链的状态做出决策。
“结算层”一词源于结算层机制通常用于处理从区块链中提取资产。这种提取系统首先需要向某个第三方链证明目标链的状态，然后根据该状态进行提取。然而，结算层并不严格（或甚至主要）用于金融目的，它在本质上只是允许第三方链了解目标链的状态。
一旦交易在相应的数据可用性层上发布并最终确定，该交易也在 OP Stack 链上最终确定。除非破坏底层数据可用性层，否则无法修改或删除该交易。尽管结算层可能尚未接受该交易，因为结算层需要能够验证交易的“结果”，但交易本身已经是不可变的。
# 基于证明的容错机制
基于证明的容错机制使用乐观协议建立对 OP Stack 链的视图。在一般的乐观结算机制中，提议者实体可以提出他们认为是当前有效状态的 OP Stack 链的提议。如果这些提议在一定时间内（“挑战期”）没有被否定，那么机制会假设这些提议是正确的。在特定的 Attestation Proof 机制中，如果一些预定义的参与方提供了与提议中状态不同的有效状态的证明，那么提议可以被否定。这对至少一定数量的预定义参与者的诚实性提出了信任假设。
# 容错乐观结算（提议）
容错乐观结算机制与当前使用的基于证明的容错机制基本相同，但它用一个无需许可的容错证明过程替代了多签名挑战者。一个正确构建的容错证明应该能够在分配的挑战期内使任何不正确的提议无效。这对容错证明构建的正确性提出了信任假设。目前，容错乐观结算机制的开发工作正在进行中。
# 有效性证明结算（提议）
有效性证明结算机制使用数学证明来证明提议视图的正确性。如果没有有效的证明，提议状态将不被接受。这对有效性证明构建的正确性提出了信任假设。
# 治理
治理层是指用于管理系统配置、升级和设计决策的一般工具和流程。这是一个相对抽象的层，可以包含目标 OP Stack 链上和对其他层产生影响的第三方链上的各种机制。
# 多签合约
多签合约是智能合约，当它们从一些预定义的参与者集合中收到阈值签名时执行操作。这通常用于管理基于 OP Stack 的系统组件的升级。目前，这是在 Optimism Mainnet 上管理桥接合约升级的机制。多签合约系统的安全性取决于许多不同因素，包括参与者的数量、阈值和每个参与者的安全程序。
# 治理代币
治理代币被广泛用于去中心化的决策制定。尽管治理代币的确切功能因情况而异，但最常见的机制允许代币持有者对项目必须做出的一些决策进行投票。投票可以直接进行或通过委托进行。