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 的性能仍然更好。

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