来源 | Optimism PBC

译者注：1 月份，Optimism 发推更新其 Rollup 的固定开销 (Fixed overhead) 从 2750 gas 减少至 2100 gas，动态开销 (Fee Scalar) 从 1.5 倍降低到 1.24 倍；3 月份又发布更新，称将对交易的 calldata 进行一次系统级别的压缩。而这一系列调整与更新将会给 Optimism 的开销带来极大的变化，进而影响用户的交易费 (交易费平均减少 30%-40%)。这些收费部分在 Optimism 的运作中分别扮演什么角色？本文先整体介绍了 Optimism 开销的组成部分，然后再分析对这些组成部分的调整如何影响用户的交易手续费。

想要理解我们是如何减少开销的，首先需要了解 Optimism 交易费的组成部分：1) Rollup 开销：将交易 “rollup” (打包) 进交易 batch 中然后提交至以太坊主网 (L1) 的开销；2) L2 执行开销：在 Optimism (L2) 上运行交易的开销。想要深入研究，请阅读 "Optimism 是如何运作的" 文档。

1) Rollup 开销

在 Optimism 中用户不再需要支付整个交易执行的 L1 gas 费用，而只需支付将你的交易数据通过交易 batch 提交至 L1 所产生的那部分费用。这笔费用包括你的交易的实际 Calldata (输入数据) 和固定开销 (Fixed Overhead) 产生的费用，即在更大的交易 batch 中添加一个交易所需的额外处理费用。

Optimism 还增加了一个动态开销 (Fee Scalar, 费用比例系数) 作为附加费用。这给了我们一些额外资金用来作为缓冲，以防 L1 价格迅速上升，而多余的资金用于推动公共物品发展。(Optimism PBC 发布的《追溯性公共物品募资》文章中有承诺这一点，还可以阅读我们首轮募资的回顾文章)

Calldata 的开销和 L1 gas 价格是由以太坊 L1 决定的，但是固定开销 (Fixed Overhead) 和费用比例系数 (Fee Scalar) 是可以由 Optimism 调整的 “花哨数字”。

“L1 gas 费” 代表这些 rollup 开销：

Layer 1 Gas Fee =Fee Scalar * L1 Gas Price * (Calldata + Fixed Overhead)

目前 Optimism 一笔交易费中 rollup 开销占大概 99.6%，所以我们可以通过优化这一部分大大地降低交易费用。

2) L2 执行开销

Optimism 上的交易使用的 gas 量与以太坊上的同等交易使用的 gas 量相同；但是，Optimism 上 gas 的标准开销只有 0.001 gwei，比 L1 便宜很多倍。这个 gas 价格在使用率高期间会略有增加，但平均只占总交易费的 0.4%。

“L2 gas 费” 代表着执行开销：

Layer 2 Gas Fee = L2 Gas Price * L2 Gas Used

交易费用的节省

将 rollup 开销和 L2 执行开销相加，我们就得到了总的交易费用。对于简单的交易 (如 ETH 转账)，Optimism 上的费用比以太坊便宜约 5 倍，但对于更复杂的交互 (如进行一笔永续 swap 交易或者期权交易)，Optimism 能比直接使用以太坊 L1 便宜 200 倍以上。

在我们降低费用之前，固定开销参数被设置在 2750 gas 每笔交易，费用比例系数被设置在 1.5 倍。后来对它们都做了一些调整：

1. 更低的开销结构：由于 Optimism 在去年 11 月 11 日进行了 EVM 等同性 (EVM Equivalence) 升级，提交 Optimism 交易 batch 至 L1 需要的 gas 变少了。实际开销减少了将近 25%，从 2750 每笔交易降至 2100 gas 每笔交易。

2. 从经验中学得什么：虽然现在 Optimism 仍处于十分早期的阶段，但自我们上线主网这几个月以来，我们知道我们有能力将额外费用从 35% 的利润率减少至 10% 的利润率 (利润率 = [L2 收集的费用 - L1 提交开销]/L2 收集的费用)。

预测和优化

下一步就是将更低的开销转化成 Optimism 用户更便宜的手续费。为了恰当地调整固定开销和费用比例系数这两个参数，我们必须理解什么影响了我们的费用：

1. Calldata：Calldata gas 的多少由交易类型决定 (比如，ETH 转账：0 calldata gas、Chainlink 预言机更新：890 gas、Uniswap V3 交易：3200 gas)。平均一笔交易使用 1100 calldata gas，但这个 gas 可能会变高，也可能会随着 Optimism 上不同的 app 被普遍采用之后变低。

2. 开销：随着总 batch 的尺寸变大，在一个 batch 中添加一笔交易的开销会减少。这是 L2 扩容与 L1 扩容不同的一个地方：交易越多，交易费就越便宜。开销已经从 2750 gas 减少到 2100 gas，并会随着 Optimism 的使用率增加继续减少。

3. L1 Gas 价格：交易在 Optimism 上发生了之后过几分钟就会被提交至 L1，而 L1 gas 价格在这段时间内变化相当大。如果 L1 gas 价格升高，提交者需要支付比预期多的 gas 费；如果 L1 gas 价格下降， 那么就会支付比预期少的 gas 费。在 gas 价格波动期间，可以有 10% 的差距。

现在我们知道这些因素是什么样的了，但一旦我们降低费用，预计使用情况就会发生变化 (比如，更多的交易，使用更多的 calldata)。因此，我们做了一些假设，提出了一系列的方案，然后在这些范围内模拟了 5000 个随机日 (参考蒙地卡羅方法, Monte Carlo method)。之后我们得到一个简单的优化问题：通过调整固定开销和费用比例系数，尽可能地接近 10% 利润的目标。

结论是：将固定开销调为 2100 gas，费用比例系数调为 1.24 倍。

想了解最新的数据吗？请看我们的交易开销 dashboard

Optimistic rollup 正迅速地走向成熟。我们度过了 “0 到 1” 的阶段之后，接下来要开始进行 “优化” 了 —— 最实在的优化是开销方面的优化。在下个月之内，我们将在任意的产品级 ORU 网络上部署首个系统级别的 calldata 压缩，实现费用降低 30-40%。

未来，我们还有其他一些计划来节省更多的 gas 费，今年夏天会推出下一个主要版本：Bedrock。这篇文章深入探讨了 calldata 压缩的细节：特别是我们如何评价各类压缩算法，以及如何利用它们实现我们的亚美元级别的收费。

Optimism 使用以太坊作为其数据可用性层。这意味着每一笔在 Optimism 执行的交易都会存储在以太坊上 (但不在上面执行)。目前我们将 Optimism 的交易存储在 calldata 中。多笔 L2 交易被成批地打包进一个二进制 blob 中，并且该 blob (加上其他信息) 存储在交易的数据字段中。想要检索回那个数据，我们需要看回交易主体本身 (存储在区块内)。因为以太坊的区块有保存下来，Optimism 链的交易总是可以借助以太坊重构。

虽然在区块中存储数据比在合约状态中存储数据要便宜得多，但永久保留历史区块确实会给节点运行者带来成本。因此，以太坊对 calldata 收费。每一个 0 字节的 calldata 消耗 4 gas，每一个非 0 字节的 calldata 消耗 16 gas (0 字节类的在提交给 Optimism 的交易中占 40% 左右的字节)。

虽然将 calldata 发布至 L1 是 rollup 节省 gas 费的一个重要部分，但这个费用同时也是二层用户进行交易的主要开销。也就是说，我们可以减少 calldata 发布的数据量越多，rollup 的交易费就可以越便宜。走进压缩：缩小数据大小的艺术！下面将对实际运行的数据压缩进行深入分析：

我们研究了 Optimism 提交给以太坊的 2.2 万个 batch (将近 300 万笔单独交易)，并以不同的配置对其进行压缩，以确定如何最好地执行压缩，并对可能的情况进行实验。

我们还研究了各种压缩算法，并计算了压缩率 (压缩后的数据大小占未压缩大小的百分比) 和预估节省的费用 (假设交易中 40% 的字节是 0 字节)。

需要了解的一个配置选项是字典 (dictionary)。提前创建一个字典，以显示现实数据中常用的算法数据分块。压缩算法使用字典来更好地压缩数据，特别是在一次性压缩少量数据时。通过随机抽取交易样本，我们可以为 zlib 和 zstd 创建一个字典，这可以在压缩单笔交易和交易 batch 时提高压缩率。

由于以太坊交易中的大多数字段都是随机的 (地址和函数选择器是哈希值，签名应该都是随机的)，单笔以太坊交易的压缩率并不高。因为以太坊上 0 字节本身就很省 gas，而压缩算法会迅速移除这些字节，所以节省的费用不会像压缩率那么多。因此，为了节省最多的费用，我们需要在尽可能多的数据上运行一个高级的算法。

下面是对交易本身进行压缩的结果：

正如你所看到的，压缩单笔交易本身只会让我们节省 10-15%。请注意，交易大小减少的幅度比这个还大，但节省的幅度较小 —— 这是由于上面讨论的更便宜的 0 字节。

带有字典的 zstandard 算法明显性能更好，因为每笔交易和存储在字典中的交易之间都有共通点。但是，当一次性压缩大量数据时，zstd 的性能仍然更好。

另一个极端就是一下子压缩所有单笔交易。这在实际中是不可能实现的，但可以作为最大压缩比率的例子研究。

另一个极端就是一下子压缩所有单笔交易。这在实际中是不可能实现的，但可以作为最大压缩比率的例子研究。

因此，在这个例子中，我们可以通过压缩节省 10%-50% 的开销。但在实践中，我们能实现什么呢？

当查看交易的压缩 batch 时 (数百笔交易)，它们的压缩率明显比压缩单笔交易的压缩率高，但是要比一次性压缩所有交易略低一些。这是因为用户倾向于与某些合约交互。此外，某些字段 (如链 ID 和 gas 价格) 在交易中趋于相似。压缩算法依赖于这些相似性来完成它们的工作。

在比较不同的压缩算法时，我们发现 zlib、zstd 和 brotli 是压缩率最高的算法。我们排除了 Brotli 是因为在差不多的压缩率下，它比 zstd 或 zlib 慢得多。一般来说，某种算法的压缩率越高 (或某个算法的设置压缩率越高)，这个算法就运行得越慢。在通用基准测试中，在比较过一系列压缩速度/压缩率之后，zstd 往往比其他压缩算法性能更好。还要注意的是，以太坊交易与基准测试中的数据具有不同的特征。

Zlib 和 zstd 十分接近，我们将在短期内推出 zlib 压缩 (不带字典)，因为它在不同的编程语言中都有良好的结果、速度和可用性。长期来看，我们希望 zstd 能够帮助实现尽可能高的压缩率和尽可能低的用户费用。

综上所述：如果按照这样的历史趋势继续下去，我们预计可以通过引入上述所说的压缩方法，将费用减少 30%-40%。

使用 Zlib 压缩算法的 batch 很快就会在 Optimism 上应用。

• 3/17 推出 Kovan 测试网

• 3/24 上线主网

基于 Zstd 算法的压缩 (带有字典的) 在 Optimism 未来的升级路线规划中：Bedrock，将在今年晚些时候发布。

除了通过压缩减少用户的费用之外，Optimism 同时正研究如何通过 EIP-4844 和类似的方法来改善以太坊作为数据可用性层的能力，以进一步减少开销。

ZLE 是零字节运行长度编码 (zero-byte run length encoding) 的缩写。它是一种简单的压缩算法，将一串零替换成应该存在的多少个零。

声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系ethereumcn@gmail.com进行授权。

来源 | Optimism PBC

译者注：1 月份，Optimism 发推更新其 Rollup 的固定开销 (Fixed overhead) 从 2750 gas 减少至 2100 gas，动态开销 (Fee Scalar) 从 1.5 倍降低到 1.24 倍；3 月份又发布更新，称将对交易的 calldata 进行一次系统级别的压缩。而这一系列调整与更新将会给 Optimism 的开销带来极大的变化，进而影响用户的交易费 (交易费平均减少 30%-40%)。这些收费部分在 Optimism 的运作中分别扮演什么角色？本文先整体介绍了 Optimism 开销的组成部分，然后再分析对这些组成部分的调整如何影响用户的交易手续费。

想要理解我们是如何减少开销的，首先需要了解 Optimism 交易费的组成部分：1) Rollup 开销：将交易 “rollup” (打包) 进交易 batch 中然后提交至以太坊主网 (L1) 的开销；2) L2 执行开销：在 Optimism (L2) 上运行交易的开销。想要深入研究，请阅读 "Optimism 是如何运作的" 文档。

1) Rollup 开销

在 Optimism 中用户不再需要支付整个交易执行的 L1 gas 费用，而只需支付将你的交易数据通过交易 batch 提交至 L1 所产生的那部分费用。这笔费用包括你的交易的实际 Calldata (输入数据) 和固定开销 (Fixed Overhead) 产生的费用，即在更大的交易 batch 中添加一个交易所需的额外处理费用。

Optimism 还增加了一个动态开销 (Fee Scalar, 费用比例系数) 作为附加费用。这给了我们一些额外资金用来作为缓冲，以防 L1 价格迅速上升，而多余的资金用于推动公共物品发展。(Optimism PBC 发布的《追溯性公共物品募资》文章中有承诺这一点，还可以阅读我们首轮募资的回顾文章)

Calldata 的开销和 L1 gas 价格是由以太坊 L1 决定的，但是固定开销 (Fixed Overhead) 和费用比例系数 (Fee Scalar) 是可以由 Optimism 调整的 “花哨数字”。

“L1 gas 费” 代表这些 rollup 开销：

Layer 1 Gas Fee =Fee Scalar * L1 Gas Price * (Calldata + Fixed Overhead)

目前 Optimism 一笔交易费中 rollup 开销占大概 99.6%，所以我们可以通过优化这一部分大大地降低交易费用。

2) L2 执行开销

Optimism 上的交易使用的 gas 量与以太坊上的同等交易使用的 gas 量相同；但是，Optimism 上 gas 的标准开销只有 0.001 gwei，比 L1 便宜很多倍。这个 gas 价格在使用率高期间会略有增加，但平均只占总交易费的 0.4%。

“L2 gas 费” 代表着执行开销：

Layer 2 Gas Fee = L2 Gas Price * L2 Gas Used

交易费用的节省

将 rollup 开销和 L2 执行开销相加，我们就得到了总的交易费用。对于简单的交易 (如 ETH 转账)，Optimism 上的费用比以太坊便宜约 5 倍，但对于更复杂的交互 (如进行一笔永续 swap 交易或者期权交易)，Optimism 能比直接使用以太坊 L1 便宜 200 倍以上。

在我们降低费用之前，固定开销参数被设置在 2750 gas 每笔交易，费用比例系数被设置在 1.5 倍。后来对它们都做了一些调整：

1. 更低的开销结构：由于 Optimism 在去年 11 月 11 日进行了 EVM 等同性 (EVM Equivalence) 升级，提交 Optimism 交易 batch 至 L1 需要的 gas 变少了。实际开销减少了将近 25%，从 2750 每笔交易降至 2100 gas 每笔交易。

2. 从经验中学得什么：虽然现在 Optimism 仍处于十分早期的阶段，但自我们上线主网这几个月以来，我们知道我们有能力将额外费用从 35% 的利润率减少至 10% 的利润率 (利润率 = [L2 收集的费用 - L1 提交开销]/L2 收集的费用)。

预测和优化

下一步就是将更低的开销转化成 Optimism 用户更便宜的手续费。为了恰当地调整固定开销和费用比例系数这两个参数，我们必须理解什么影响了我们的费用：

1. Calldata：Calldata gas 的多少由交易类型决定 (比如，ETH 转账：0 calldata gas、Chainlink 预言机更新：890 gas、Uniswap V3 交易：3200 gas)。平均一笔交易使用 1100 calldata gas，但这个 gas 可能会变高，也可能会随着 Optimism 上不同的 app 被普遍采用之后变低。

2. 开销：随着总 batch 的尺寸变大，在一个 batch 中添加一笔交易的开销会减少。这是 L2 扩容与 L1 扩容不同的一个地方：交易越多，交易费就越便宜。开销已经从 2750 gas 减少到 2100 gas，并会随着 Optimism 的使用率增加继续减少。

3. L1 Gas 价格：交易在 Optimism 上发生了之后过几分钟就会被提交至 L1，而 L1 gas 价格在这段时间内变化相当大。如果 L1 gas 价格升高，提交者需要支付比预期多的 gas 费；如果 L1 gas 价格下降， 那么就会支付比预期少的 gas 费。在 gas 价格波动期间，可以有 10% 的差距。

现在我们知道这些因素是什么样的了，但一旦我们降低费用，预计使用情况就会发生变化 (比如，更多的交易，使用更多的 calldata)。因此，我们做了一些假设，提出了一系列的方案，然后在这些范围内模拟了 5000 个随机日 (参考蒙地卡羅方法, Monte Carlo method)。之后我们得到一个简单的优化问题：通过调整固定开销和费用比例系数，尽可能地接近 10% 利润的目标。

结论是：将固定开销调为 2100 gas，费用比例系数调为 1.24 倍。

想了解最新的数据吗？请看我们的交易开销 dashboard

Optimistic rollup 正迅速地走向成熟。我们度过了 “0 到 1” 的阶段之后，接下来要开始进行 “优化” 了 —— 最实在的优化是开销方面的优化。在下个月之内，我们将在任意的产品级 ORU 网络上部署首个系统级别的 calldata 压缩，实现费用降低 30-40%。

未来，我们还有其他一些计划来节省更多的 gas 费，今年夏天会推出下一个主要版本：Bedrock。这篇文章深入探讨了 calldata 压缩的细节：特别是我们如何评价各类压缩算法，以及如何利用它们实现我们的亚美元级别的收费。

Optimism 使用以太坊作为其数据可用性层。这意味着每一笔在 Optimism 执行的交易都会存储在以太坊上 (但不在上面执行)。目前我们将 Optimism 的交易存储在 calldata 中。多笔 L2 交易被成批地打包进一个二进制 blob 中，并且该 blob (加上其他信息) 存储在交易的数据字段中。想要检索回那个数据，我们需要看回交易主体本身 (存储在区块内)。因为以太坊的区块有保存下来，Optimism 链的交易总是可以借助以太坊重构。

虽然在区块中存储数据比在合约状态中存储数据要便宜得多，但永久保留历史区块确实会给节点运行者带来成本。因此，以太坊对 calldata 收费。每一个 0 字节的 calldata 消耗 4 gas，每一个非 0 字节的 calldata 消耗 16 gas (0 字节类的在提交给 Optimism 的交易中占 40% 左右的字节)。

虽然将 calldata 发布至 L1 是 rollup 节省 gas 费的一个重要部分，但这个费用同时也是二层用户进行交易的主要开销。也就是说，我们可以减少 calldata 发布的数据量越多，rollup 的交易费就可以越便宜。走进压缩：缩小数据大小的艺术！下面将对实际运行的数据压缩进行深入分析：

我们研究了 Optimism 提交给以太坊的 2.2 万个 batch (将近 300 万笔单独交易)，并以不同的配置对其进行压缩，以确定如何最好地执行压缩，并对可能的情况进行实验。

我们还研究了各种压缩算法，并计算了压缩率 (压缩后的数据大小占未压缩大小的百分比) 和预估节省的费用 (假设交易中 40% 的字节是 0 字节)。

需要了解的一个配置选项是字典 (dictionary)。提前创建一个字典，以显示现实数据中常用的算法数据分块。压缩算法使用字典来更好地压缩数据，特别是在一次性压缩少量数据时。通过随机抽取交易样本，我们可以为 zlib 和 zstd 创建一个字典，这可以在压缩单笔交易和交易 batch 时提高压缩率。

由于以太坊交易中的大多数字段都是随机的 (地址和函数选择器是哈希值，签名应该都是随机的)，单笔以太坊交易的压缩率并不高。因为以太坊上 0 字节本身就很省 gas，而压缩算法会迅速移除这些字节，所以节省的费用不会像压缩率那么多。因此，为了节省最多的费用，我们需要在尽可能多的数据上运行一个高级的算法。

下面是对交易本身进行压缩的结果：

正如你所看到的，压缩单笔交易本身只会让我们节省 10-15%。请注意，交易大小减少的幅度比这个还大，但节省的幅度较小 —— 这是由于上面讨论的更便宜的 0 字节。

带有字典的 zstandard 算法明显性能更好，因为每笔交易和存储在字典中的交易之间都有共通点。但是，当一次性压缩大量数据时，zstd 的性能仍然更好。

另一个极端就是一下子压缩所有单笔交易。这在实际中是不可能实现的，但可以作为最大压缩比率的例子研究。

另一个极端就是一下子压缩所有单笔交易。这在实际中是不可能实现的，但可以作为最大压缩比率的例子研究。

因此，在这个例子中，我们可以通过压缩节省 10%-50% 的开销。但在实践中，我们能实现什么呢？

当查看交易的压缩 batch 时 (数百笔交易)，它们的压缩率明显比压缩单笔交易的压缩率高，但是要比一次性压缩所有交易略低一些。这是因为用户倾向于与某些合约交互。此外，某些字段 (如链 ID 和 gas 价格) 在交易中趋于相似。压缩算法依赖于这些相似性来完成它们的工作。

在比较不同的压缩算法时，我们发现 zlib、zstd 和 brotli 是压缩率最高的算法。我们排除了 Brotli 是因为在差不多的压缩率下，它比 zstd 或 zlib 慢得多。一般来说，某种算法的压缩率越高 (或某个算法的设置压缩率越高)，这个算法就运行得越慢。在通用基准测试中，在比较过一系列压缩速度/压缩率之后，zstd 往往比其他压缩算法性能更好。还要注意的是，以太坊交易与基准测试中的数据具有不同的特征。

Zlib 和 zstd 十分接近，我们将在短期内推出 zlib 压缩 (不带字典)，因为它在不同的编程语言中都有良好的结果、速度和可用性。长期来看，我们希望 zstd 能够帮助实现尽可能高的压缩率和尽可能低的用户费用。

综上所述：如果按照这样的历史趋势继续下去，我们预计可以通过引入上述所说的压缩方法，将费用减少 30%-40%。

使用 Zlib 压缩算法的 batch 很快就会在 Optimism 上应用。

• 3/17 推出 Kovan 测试网

• 3/24 上线主网

基于 Zstd 算法的压缩 (带有字典的) 在 Optimism 未来的升级路线规划中：Bedrock，将在今年晚些时候发布。

除了通过压缩减少用户的费用之外，Optimism 同时正研究如何通过 EIP-4844 和类似的方法来改善以太坊作为数据可用性层的能力，以进一步减少开销。

ZLE 是零字节运行长度编码 (zero-byte run length encoding) 的缩写。它是一种简单的压缩算法，将一串零替换成应该存在的多少个零。

声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系ethereumcn@gmail.com进行授权。