一文对比 Optimism Bedrock 和 Arbitrum Nitro 的设计差异

原文作者：OP Labs 研发人员 Norswap，本文由 DeFi 之道编译

这是一篇有关 Optimism Bedrock 以及 Arbitrum Nitro‌ 之间设计差异的分析文章。

这一切都源于我对 Nitro 白皮书‌的阅读，以及我对 Bedrock 设计的感性认识。

这变得非常技术性， 如果你想关注并感到困惑，我建议你参考一下 Bedrock 概述以及我关于 Cannon 故障证明系统的演示文稿‌，当然还有 Nitro 白皮书。

准备好了之后，让我们开始吧！

首先，Nitro 白皮书很棒，读起来令人愉快， 我建议所有感兴趣的人都去看看。

说到这里，我的印象是 Bedrock 和 Nitro 大致使用了相同的架构，但有一些较小的差异。

白皮书大体上证实了这一点。 尽管如此，还是有很多的不同之处，包括一些我没想到的。这就是这篇文章要讲的东西。

（A）固定与可变区块时间

最有趣和最重要的事情之一是， Nitro 将像当前版本的 Optimism 一样工作，每笔交易一个区块，并且区块之间的时间可变。

我们放弃了这一点，因为它背离了以太坊的工作方式，也是开发人员的痛点。而 Bedrock 将有“真正”的区块，并且固定时间为 2 秒。

不规则的区块时间使很多常见的合约变得不稳定，因为它们是使用区块而不是时间戳来表示时间。这尤其包括源自 Sushiswap 的分配 LP 奖励的 Masterchef 合约。

我不确定为什么这些合约用区块而不是时间戳来表示时间！以太坊矿工在操纵时间戳方面有一些回旋余地，但默认情况下，客户端不会构建距离 wallclock （Geth 为 15 秒）太远的区块，所以没有问题。

无论如何，在 Optimism 上，这导致 StargateFinance 奖励比其他链提前几个月用完，因为他们没有考虑到这种特殊性！

“每笔交易一个区块”模型还有其他的问题。首先，存储链的开销很大（每笔交易一个区块头）。其次，这意味着状态根需要在每次交易后更新。

更新状态根是一项非常昂贵的操作，其成本要在多笔 tx 中进行分摊。

(B) Geth 作为库或作为执行引擎

Nitro 使用 Geth “作为一个库”，通过钩子（hooks）对其进行了最低限度的修改，以调用适当的功能。

在 Bedrock 中，一个经过最少修改的 Geth 作为“执行引擎”独立运行，它从 rollup 节点接收指令，就像执行层从 Etp 中的共识层接收指令一样。 我们甚至使用完全相同的 API！

这有一些重要的影响。 首先，我们能够使用除 Geth 之外的其他客户端，在它们之上应用类似的最小差异。 这不仅仅是理论，我们已经准备好了 Erigon‌。

其次，这让我们可以重用整个 Geth（或其他客户端）堆栈，包括在网络层，这可以实现对等发现和状态同步等功能，而无需进行任何额外的开发工作。

(B) 状态存储

Nitro 将一些状态（“ArbOS 的状态”）保存在一个特殊帐户中（它本身存储在 Arbitrum 的链状态中），使用特殊的内存布局将密钥映射到存储槽。

（这纯粹是架构，对用户没有影响。）

从这个意义上说，Bedrock 并没有太多的状态，它只有很少的状态存储在普通 EVM 合约中（公平地说，你可以使用 EVM 实现 ArbOS 状态布局，但我认为他们并不是这样做的）。

在确定/执行下一个 L2 块时，一个 Bedrock 副本会查看：

1. L2 链头部的区块头；
2. 从 L1 读取的数据；
3. L2 链上 EVM 合约中的一些数据，目前只有 L1 费用参数；

在 Bedrock 中，节点可能会崩溃并立即优雅地重启。它们不需要维护额外的数据库，因为所有必要的信息都可以在 L1 和 L2 区块中找到。我认为 Nitro 的工作原理是一样的（架构使这成为可能）。

但很明显， Nitro 比 Bedrock 做了更多的记账工作。

(C) L1 到 L2 的消息包含延迟

Nitro 会延迟 10 分钟处理 L1 到 L2 的消息（我们称之为“存款交易”或简称“存款”）。在 Bedrock 上，通常应具有几个区块的小确认深度（可能是 10 个 L1 区块，所以大约是 2 分钟）。

我们也有一个称为“排序器漂移”（sequencer drift）的参数，它允许 L2 区块的时间戳在其 L1 原点之前漂移（L1 区块标志着 L1 区块范围的结束，批次和存款是从中派生的）。

我们仍然需要确定最终的数值，但我们也倾向于 10 分钟，这意味着最坏的情况是 10 分钟。然而，此参数旨在确保在与 L1 的连接暂时丢失期间 L2 链的活性。

然而，通常在确认深度后会立即包含存款。