OP-Stack：构建区块链的最简框架

关键要点

• 启动你自己的区块链或 Rollup 具有明显的优势，例如可定制性和可扩展性，并且在各种选项中，OP-Stack 是最容易部署的软件。

• OP-Stack 由 4 个节点组件和一些智能合约组成，并且有各种项目正在围绕 OP-Stack 构建。

• 然而，OP-Stack 存在局限性：故障证明系统、中心化以及缺乏核心创新。

• 结论：OP-Stack 使得个人 Rollup 的创建更加简单，为生态系统的增长和定制 Rollup 领域的创新奠定了基础。

1. 使用 OP-Stack 启动区块链

随着去中心化应用程序 (dApp) 的持续增长，以及越来越多的传统企业开始参与区块链，一个明显的趋势正在出现。 对于构建自己的区块链或 Rollup 存在浓厚的兴趣，原因有很多。

启动他们自己的区块链可以提供一些显着的优势。 为什么应该使用 OP-Stack 开展这样的投资，可以通过检查以下关键优势来解答：

1.1 可定制性

在可定制性方面，创建你自己的 Rollup 或区块链，开启了一个充满可能性的世界。 可以自由地定制各个方面以满足特定需求，这提供了多重好处。 无论你关注的是治理模型、交易费用还是智能合约的功能，你都可以更改这些元素以满足你的特定需求。

OP-Stack 设计中固有的模块化鼓励了定制化。 该结构经过精心设计以实现适应性，从而可以使执行客户端等组件多样化。 这意味着你可以调整这些元素以适应你项目的独特要求，从而提供控制和灵活性。

1.2 可扩展性

Rollup 和区块链从根本上设计用于解决可扩展性问题。 当你承担启动自己的解决方案的任务时，你可以仅使用你的用例的资源，从而以更低的成本实现高交易吞吐量。 这允许一定程度的可扩展性，通常超过现有平台所提供的。 例如，考虑通过优化你自己的区块链来最大化交易速度的潜力。 与目前在更拥挤的平台上可以实现的交易速度相比，这将实现更快、更高效的运营。

1.3 资源效率

OP-Stack 能够利用数据可用性层的安全功能，并且可以使用单个排序器进行操作。 虽然 Cosmos 或 Polkadot 提供的专用 SDK 提供了各种优势，例如互操作性解决方案和各种核心功能定制，但它们需要高昂的成本来运营单独的验证器集，或者需要包含以利用共享安全属性。 此外，它们的开发工具不像以太坊生态系统中的那样丰富。 相反，OP-Stack 可以利用以太坊生态系统中可用的工具，并且可以利用底层数据可用性层（例如以太坊）的安全功能。

2. 关于 OP-Stack

OP-Stack 是一种开源的模块化方法，专为构建 Optimistic Rollup 而设计。 2023 年 6 月 6 日的 Bedrock 升级是 OP-Stack 的初始主网发布。 随着 Optimism 网络进行了重要的 Bedrock 升级，它降低了交易费用，提高了安全性并提供了更多的可定制性。 改进的主要细节如下。

此次升级导致 Optimism 主网上的协议成本降低了 47%。 通过优化批量压缩并利用以太坊来实现数据可用性，从而降低了交易费用。 其中 99% 在状态链承诺中，20% 在批量提交成本中。 未来，OP-Stack 旨在推动 Optimism 成为互连区块链的“超级链”，从而使基于 OP-Stack 的链能够与共享基础设施互连。

3. 架构

3.1 组件

OP-Stack 解决方案包含 四个基本组件：节点（op-geth，op-node）和特定于排序器的组件（op-batcher，op-proposer）。 每个组件在支持 Rollup 的过程中都发挥着独特的作用。

节点：

• op-geth 位于关键的事务处理交叉点，将用户事务引导到执行层，从而确保准确高效的网络事务。 此外，op-geth 根据事务调整状态，将事务应用于先前的状态以创建新的状态。 它在整个事务处理过程中管理状态的存储和修改，从而准确地反映所有状态更改。

• op-node 组件对于通过标准的以太坊引擎 API 将来自数据可用性层的原始数据转换为执行层的已处理输入至关重要。 它从以太坊区块数据、排序器事务批次和已存入的事务事件中获取输入，当前系统状态会引导其解析原始输入数据。 这种机制确保了高效和精确的数据处理。 功能包括将 L2 存款和取款事务提交到 L1、重试失败的事务、更新 L2 事务状态以及根据最近的提示计算 L1 Gas 价格。

特定于排序器:

• op-batcher 主要处理将事务写入 L1 网络（以太坊），压缩事务以优化网络效率并简化数据传输和存储。

• 最后，op-proposer 在最终确定状态转换方面至关重要。 在 op-geth 修改状态后，op-proposer 将对事务后状态的承诺写入 L1，从而记录更新后的状态。 它提出了更新后状态的新 Merkle 根，利用 Merkle 根来最大程度地减少写入 L1 的数据，从而降低了事务成本。 这些状态根提案会发布到 L1 网络上的 L2OutputOracle。 这些输出提案必须经过 7 天的故障挑战期才能获得权限，从而促进潜在的争议和挑战，从而增强网络的可靠性和可追溯性。

3.2 合约

需要部署多个合约才能运行 OP-Stack Rollup。 一些主要合约包括以下内容：

3.2.1 部署在 L1 上的 OptimismPortal

OptimismPortal 是一种有助于 L1 和 L2 之间通信的合约。 它是 Optimism 系统中跨链消息传递的主要网关。

该合约支持多个关键功能。 首先，它允许存入计划在 L2 上执行的 L1 交易。 其次，它有助于验证 L2 提款并从 L1 提款。 第三，它具有暂停跨链消息传递的内置功能，该功能由 Guardian 管理（可以暂停存款和取款的地址）。 最后，它会跟踪已确认的提款和 l2Sender，从而方便了提款的最终确定。

此外，L2OutputOracle 和 SystemConfig 合约似乎在此系统中具有特定角色。 L2OutputOracle 协助验证 L2 状态，而 SystemConfig 合约大概有助于设置系统参数。

3.2.2 部署在 L1 上的 L2OutputOracle

L2OutputOracle 是一种合约，它保存 op-proposer 提交的 L2 的结果状态根。 此合约允许其他 L1 合约验证有关 L2 状态的信息。

该合约支持多个关键功能。 它允许提议者以特定的提交间隔提交新的 L2 输出。 此外，它使挑战者可以删除任何无效的 L2 输出。 此外，它允许其他合约通过审查 L2 输出来验证有关 L2 状态的信息。 最后，它还能够根据 L2 区块时间计算 L2 的时间戳和区块编号。

本质上，L2OutputOracle 合约是 L1 合约有关 L2 链状态的可靠信息来源。 通过存储对 L2 状态的承诺，它有助于信息的跨链验证。

3.2.3 部署在 L2 上的 L1Block

L1Block 是一种合约，用于保留有关最新已知 L1 区块的信息。

此合约可能是 L2 合约有关最新 L1 区块的权威信息来源。 通过在 L2 上存档此数据，L2 合约可以访问有关 L1 的详细信息，而无需跨链调用。 存储的信息可以通过多种方式使用：

• 它支持计算 L2 事务的 L1 Gas 价格。

• 它有助于验证排序器提交的 L1 区块数据。

• 它允许 L2 合约验证特定的 L1 交易是否已成功挖掘。

排序器大概管理存款人地址，该地址会在每个新的 L1 区块达到其最终状态时刷新合约的值。

更多合约可以在此链接中找到。

3.3 演练

3.3.1 事务

事务需要在 L1 (以太坊) 上记录。 通常，op-batcher 为 L2 事务处理此过程，但是任何用户都可以选择发送 L1 事务以提交 L2 事务，这会绕过 op-batcher。

然后，要修改状态，需要由 op-geth 执行事务。 随后，op-proposer 生成对事务后状态的承诺，并将其写入 L1。 值得注意的是，op-proposer 不需要在每次状态转换后都创建承诺。

L2 事务的过程涉及几个关键步骤：

将事务发布到 L1

首先，将事务写入 L1。 这包括两个子步骤：压缩和发布到 L1。 在压缩期间，op-batcher 将排序器批次划分为多个通道，以最大程度地提高压缩率。 通道一旦已满或超时，就会被压缩和转录。

压缩后，事务将发布到 L1。 当通道已饱和时，它将作为单个或多个事务分派到 L1，具体取决于数据大小。 L2 事务可以占用三种状态：不安全（已处理但尚未写入 L1）、安全（已处理并写入 L1，但可能会由于 L1 重组而被丢弃）和已完成（已以足够成熟的区块写入 L1）。 一旦事务达到“已完成”状态，它将不可撤销。

执行

状态处理阶段涉及两个主要步骤：将事务应用于现有状态以产生新状态，以及提出表示该状态的新 Merkle 根。 这是由两个组件执行的：op-geth 和 op-proposer。

在初始阶段，op-geth 将事务应用于当前状态。 此操作会导致随着事务的应用而更改状态。 op-geth 是对以太坊 geth 的最小修改。

提议状态根

在后续步骤中，op-proposer 介入并提出该状态的新 Merkle 根，并将该根存储在 L1 中的 L2OutputOracle 合约中。 Merkle 根用作紧凑的表示形式，而不是直接将整个状态转录到 L1，这将因其庞大的规模而导致资源密集型。 此根封装了有关状态更改的关键信息，并支持有效的验证。

3.2.2 区块生产

在 Bedrock 升级之前，为每个事务生成一个区块。 但是，升级后，每 2 秒生成一个区块，其中包括此期间的事务和更改后的状态根。 此外，每个区块都有一个名为 L1 Attributes Deposited Transaction 的系统事务，该事务封装了 L1 区块的最新信息。 然后，op-geth 接收事务并将它们应用于先前的状态。

L1 Attributes Deposited Transaction 具有两个关键作用。 首先，它为 L2 合约配备了有关最新 L1 区块的最新更新，从而无需单独的跨链调用。 其次，它使 L2 合约能够验证有关排序器提供的 L1 区块信息的正确性。

L1 Attributes Deposited Transaction 具有一组独特的功能。 来自 L1 区块的 Rollup 节点在区块派生期间生成它。 此事务包含有价值的信息，包括 L1 区块号、时间戳、基本费用、哈希和其他相关详细信息。 它们源自 L1 Attributes Depositor 帐户，并且不携带任何 ETH 值，也不会与 L2 Gas 池进行交互。 无论其有效性如何，它们始终包含在区块中，以确保无缝的区块构建。 L1 Attributes Predeployed Contract 存储并使此信息可访问。

L1 Attributes Deposited Transaction 的标准工作流程如下：

• op-node 创建一个 L1 Attributes Deposited Transaction，在 L2 区块中包含最新的 L1 区块详细信息。

• 此事务在 L2 上执行，然后启动 L1 Attributes 预部署合约。

• 预部署的合约保留 L1 区块数据并触发事件。

• 其他 L2 合约现在可以与预部署的合约交互以获取最新的 L1 区块信息。

总之，L1 Attributes Deposited Transaction 充当 L2 合约 L1 区块的可信参考。 通过将此信息直接嵌入到 L2 区块中，L2 合约可以轻松访问最新的 L1 数据，从而无需跨链调用。

4. 相关项目

4.1 OP-Stack 链

随着 OP-Stack 的推出，多个项目一直在使用 OP-Stack 代码库构建 Rollup。 Coinbase 的 Base、BNB 上的 opBNB 和 ZORA 链就是一个例子，目前正处于测试网阶段。 这可能会导致更多的工具和实验。 以下是一些示例案例。

4.1.1 OP-Clave

(来源: Opclave | ETHGlobal)

以太坊支持椭圆曲线 secp256k1 上的椭圆曲线数字签名算法 (ECDSA)。 但是，这需要通过新部署的智能合约来处理其他椭圆曲线的验证，从而导致大量的验证成本。 考虑到各种椭圆曲线可以提供的广泛潜在应用和优势，这是一个固有的挑战。

为了解决这个问题，引入了 OP-Clave。 这是一个自定义 Rollup，它包含一个“secp256r1 验证器”作为预编译的合约，符合 Optimism 的 Bedrock 版本的标准。 这种集成为应用 Face-Id 和 Touch-Id 验证事务的环境铺平了道路。 OP-Clave 的独特方法优化了效率和经济性，同时确保了安全可靠的事务。

4.1.2 Celestia OP-Stack

(来源: Celestia)

Celestia 发布了一个 演示代码库，该代码库允许使用 Celestia 作为数据可用性层来运行基于 OP-Stack 的 Rollup。 鉴于 OP-Stack 的大部分运营费用来自在以太坊上存储事务，因此这种实施方式使 Rollup 能够在 Celestia 上存储交易数据，而只有指向交易数据的参考链接存储在以太坊上。 因此，这导致了运营成本的降低。

4.1.3 支持 OP-Stack 的 RaaS

Rollup 即服务 (RaaS) 是一个新兴领域，它提供用于部署和管理 Rollup 的工具。 Conduit 和 Caldera 等公司是支持 OP-Stack 的解决方案。 他们的服务有助于简化 Rollup 的管理和部署，从而支持 OP-Stack 应用程序的增长和发展。 Zora 最近宣布 的自己的 Rollup 链也是使用 Caldera 构建的。

4.2 基础设施工具

OP-Stack 的一个显着优势是它能够利用以太坊生态系统中使用工具。 这允许使用各种以太坊工具。

(来源: DappCamp)

4.2.1 op-erigon

op-erigon 由 Test in Prod 开发，是 op-geth 的替代执行客户端， 建模为 erigon 实施的变体。 目前，只有 op-geth 是生产中使用的唯一执行客户端。 但是，作为第二个替代执行客户端，它已部署到主网，预计将提高执行客户端的多样性。

4.2.2 Magi

Magi 由 a16z 开发，是 op-node 的替代 Rollup 客户端，旨在增强 Rollup 中的客户端多样性。 Magi 用 Rust 编写，与 Geth 和 Besu 等执行客户端兼容。 虽然它与 op-node 共享相同的功能，但预计经过几个月的额外开发后，它将成为可行的替代方案。

5. 局限性

5.1 故障证明的局限性

Optimistic Rollup 已经过数百万笔交易的生产中的广泛测试。 但是，它需要将输入数据（事务）和输出存储到昂贵的数据可用性层，并且 7 天的最终确定时间太长。 这就是 zkEVM 越来越受到关注的原因。 尽管 最近发布了 RFP（提案请求）以在 OP-Stack 上实施 zk，但是将零知识集成到 OP-Stack 中可能需要大量时间。 此外，当前的故障证明系统仅涉及少数参与者，这表明需要提高效率和去中心化。 但是，随着 OP-Stack 中即将到来的里程碑专注于此故障证明系统，我预计在不久的将来会有重大进展。

5.2 去中心化

当前 OP-Stack 系统的主要缺点之一是排序器的中心化性质。 排序器由单个实体运营，并且在 Bedrock 升级后，每 2 秒生成一个区块，而不是每个事务一个区块，这为不良 MEV（例如抢先交易）打开了可能性。 目前，为了防止矿工可提取价值 (MEV)，mempool 保持私有。 但是，Optimism 团队在其路线图上制定了去中心化的计划，并希望在不久的将来实现这一目标。

5.3 核心实现

虽然以太坊生态系统拥有一个充满活力的开发者社区，但核心方面的实验却很少。 大多数已实施的功能都更通用，而不是特定于应用程序的核心更改。 特定应用程序所需的以太坊改进提案 (EIP) 通常很难包含在以太坊核心升级中。 因此，大多数此类实施都发生在智能合约方面。 这也适用于 Optimism 生态系统。

6. 结论

OP-Stack 已经为轻松构建自己的 Rollup 铺平了道路，并且有许多项目正在此生态系统中构建。 随着生态系统的不断增长和繁荣，Rollup 的部署将变得像部署智能合约一样简单。

我认为，仅使用智能合约构建应用程序肯定存在制约。 尽管在基于智能合约的 dApp 中进行了无数的创新和实验，但我相信这些自定义 Rollup 空间内的更多有趣的进展将会激增。 这得益于像 OP-Stack 这样的框架，它需要更少的资源来启动自己的 Rollup。

感谢 Kate 为本文设计图片。

• 原文链接： 4pillars.io/en/articles/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～