Layer2 压缩 Calldata

自 2020 年以来，以太坊的扩展路线图一直围绕着“rollup”展开：独立的执行环境，它使用证明（零知识证明或乐观欺诈证明）来继承以太坊的安全性。

经过多年的发展，rollup 终于被部署并获得了采用。旗舰级的 Arbitrum 乐观 rollup 已经上线近一年，超过 27 亿美元的资产存入桥中，而 Optimism 紧随其后。Loopring 和 dYdX 等特定于应用程序的零知识 rollup 也获得了大量采用，并且许多竞争性的通用零知识 rollup 计划在未来几个月内推出。

尽管 rollup 领域取得了快速的扩展进步，但有些人表示担心这些费用仍然太高。

事实上，Arbitrum 和 Optimism 上的交易费用仍然远高于 Solana 和 Polygon 等“低费用”链。

那么是什么阻碍了这些 rollup 呢？

了解 rollup 经济学

要了解交易费用，我们首先需要分解区块链交易产生的各种成本：

执行

这是网络中所有节点执行交易并验证结果有效所需的成本（例如：你实际上拥有你尝试转移的代币）。

存储/状态

这是使用新值更新区块链“数据库”的成本（例如：在代币转账之后，发送者的余额减少，接收者的余额增加）。

数据可用性

为了确保区块链保持无需信任且可供所有人验证，区块链必须确保有关交易的所有相关数据都公开共享给所有网络参与者。

本质上，这是确保世界上每个人都可以看到你的交易的保证。如果没有这种保证，各种攻击都是可能的（称为数据扣留攻击）。

正如我们将看到的，数据可用性是当今区块链的关键瓶颈之一...

Rollup：将执行转移到链下

Rollup 的主要进步来自于将区块链的执行和存储“链下”转移到有限的节点组的能力。我们不必让网络中的每个以太坊节点都需要执行所有交易并存储每次更新，而是可以将此任务委托给 rollup 运营商。

等等，信任一小群运营商？这难道不是中心化的吗？

好问题！

Rollup 旨在通过各种证明类型来继承以太坊的相同安全性。乐观 rollup 允许单个诚实实体提交“欺诈证明”并获得不良行为排序器的奖励，而 ZK rollup 使用零知识证明（翻译：花哨的密码学） 来证明 layer-2 链已正确更新。

数据可用性权衡

将执行移出主链可以显着降低执行和状态存储的成本。但是，rollup 仍然必须将其数据发布到 layer-1 链，以确保数据可用性。

本质上，rollup 为执行和存储支付廉价的 layer-2 成本，但仍必须支付 layer-1 费用来发布其数据。

这可以在 ArbiScan 区块浏览器中任何交易的“高级 TxInfo”选项卡上看到。交易费用分为发布到 L1 的 calldata 成本、L2 上使用的计算以及 L2 存储。 在几乎所有交易中，L1 calldata 都是费用的主要驱动因素。

简而言之：将数据发布到 Layer-1 是 rollup 费用的主要瓶颈。

数据可用性的未来

虽然数据可用性是当今 rollup 的瓶颈，但预计这种情况会随着时间的推移而得到缓解。

以太坊升级，如 Proto-Danksharding 以及最终的完整 Danksharding 将大大降低将数据发布到以太坊的成本。此外，像 Celestia 这样的项目旨在提供专门用于提供廉价数据可用性的独立链。

从长远来看，像 Danksharding 和 Celestia 这样的系统将使数据可用性变得廉价且充足，从而将瓶颈转移回执行。但是，这些解决方案需要时间才能成熟：Celestia 距离其主网启动还有几个月的时间，并且以太坊可能需要一年多的时间才能添加像 Proto-Danksharding 这样的数据可用性升级。

Calldata 压缩

数据压缩是一个比计算机本身更古老的领域！莫尔斯电码发明于 1838 年，是最早的数据压缩示例。然而，计算机的使用加速了对数据压缩的研究，霍夫曼编码等算法在 1950 年代被发明出来。

鉴于 rollup 具有廉价的执行成本但昂贵的数据可用性成本，毫不奇怪这些团队已将数据压缩算法集成到其协议中。Optimism 已将 Zlib 压缩算法集成到他们的 rollup 中（阅读有关其算法选择过程的更多信息），而 Arbitrum 即将推出的 Nitro 升级 使用 brotli 压缩算法。

注意：此实验可能已在 Nitro 发布之前匆忙推出，以便在未压缩的 Arbitrum calldata 上进行实验 🙂

数据压缩算法当然是有用的工具，可以帮助降低这些 calldata 成本。但是，压缩区块链交易是一项艰巨的任务：数据压缩通过查找常见模式并缩短它们来实现。但是，交易中充满了地址、哈希和签名，这些对于这些压缩算法本质上是“随机数据”。

真正降低 calldata 成本的方法是让开发人员注意如何在他们的应用程序中最大限度地减少 calldata。2020-2021 年的天价 gas 价格迫使开发人员优化他们的代码，以最大限度地减少执行和状态存储。

当我们过渡到 L2 世界时，calldata 从最便宜的资源变为最昂贵的资源，开发人员必须再次学习这些新的优化方法。

实验：我们可以将简单的代币转账压缩多少

这里是一个试验的页面

实验设计和控制用例

为了运行我们的实验，我们将构建一个简单的智能合约，该合约会将代币从交易发送者转移到任何给定的地址。

这个示例智能合约确实要求用户在发送我们实际的测试交易之前发送一个 approve() 交易。由于此限制，任何用户都实际不会想要使用此系统进行代币转账。但是，此实验中使用的节省成本的技术可以应用于其他合约（例如，优化的 Uniswap 路由器）。

为了开始这个实验，我们将发送一个“控制”交易来获得一个基准成本。此交易调用一个简单的 Solidity 函数，传递代币地址、接收者地址和要转移的代币数量。

我们的测试交易 使用了 576,051 ArbiGas，总费用为 0.43 美元。

简单的 calldata 压缩

查看控制用例使用的 calldata，我们可以看到有很多不必要的数据可以删除。

首先，让我们删除所有零，这些零只是作为填充添加的。零确实比非零字节便宜，但它们仍然会产生费用，所以让我们删除它们。

开头还有一个 4 字节的函数签名，它是我们尝试调用的 Solidity 函数的标识符。我们可以删除这些数据，并让我们的代码简单地推断出我们试图采取的行动。

这两个优化使我们可以将字节码从 100 字节减少到 43 字节。我们的测试交易 使用了 494,485 (减少了 14%)，成本为 0.37 美元。

确定性的“辅助”合约

我们的大部分数据现在由我们的 calldata 中的两个地址组成：一个是我们将要转移的代币的地址，另一个是转移的接收者的地址。

但是，我们可以想象大多数用户都在转移相同的几个代币（WETH、Dai、USDC）。我们可以从 calldata 中删除整个代币地址的一种方法是为该代币部署一个特殊的“辅助”合约。我们现在将我们的交易发送给这个辅助合约，完全避免了包含代币地址的需要。

这让我们将数据字节码减少到 23 字节。我们的测试交易 使用了 457,546 (比控制减少了 21%)，成本为 0.34 美元。

地址查找表

我们的最后一个阶段使用了一个“辅助合约”来从我们的 calldata 中删除一个地址，但是我们的 calldata 中仍然有另一个地址。

是否有另一种可以更一致地用于“压缩”地址的技术？

值得庆幸的是，Arbitrum 有一个名为“ 地址表注册表”的内置合约，我们可以使用它来缩短我们的 calldata。

此合约本质上是一个“电话簿”，它将 20 字节的以太坊地址映射到简单的整数。想象一下你的朋友有一个传统的电话簿：你不必向他们读出你的整个电话号码，你可以简单地说“我是电话簿第 200 页上的第 4 个电话号码”，让他们查找你的号码。

因此，我们可以做的是制作一个合约，该合约将接受一个“地址索引”来代替完整的地址，并在内部查找完整的地址。

通过替换“代币”和“接收者”地址，我们可以将 calldata 减少到 9 个字节。我们的测试交易 使用了 428,347 (比控制减少了 26%)，成本为 0.32 美元。

现在将它们全部结合起来！

最后，让我们将我们所有的技术组合成一个：

• 删除填充和函数选择器
• 使用确定性辅助合约来删除常见的地址
• 使用 Arbitrum 地址表来缩短其他地址

总而言之，我们的 calldata 大小现在只有 6 个字节！最终的测试交易 使用了 426,529 (也比控制减少了 26%，略低于之前的测试用例)，成本为 0.32 美元。

其他技术：有损压缩

我们已经介绍的所有压缩技术都是“无损压缩”的示例，其中压缩后的输出包含与原始输入相同的所有数据。

但正如照片和视频文件使用“有损压缩”算法来删除不必要的信息一样，我们也可以删除在大多数情况下不必要的数据。

这方面的主要例子是缩短数字以消除不必要的精度。例如，ERC-20 代币通常保留 18 位小数的精度，但大多数用户通常只关心最多约 4 位小数的精度。我们可以构建一个合约，该合约默认接受具有 8 位小数的数字并乘以 10^10，并为需要更高精度的用户提供辅助函数。

总结

总而言之：calldata 已经从以太坊 L1 上最便宜的资源变为以太坊 rollup 上最昂贵的资源。像 Proto-Danksharding 和 Celestia 这样的数据可用性技术最终将缓解这一瓶颈，但两者都尚未启动，并且可能需要数年时间数据可用性才能变得廉价且充足。

因此，区块链开发人员需要注意他们的交易需要多少 calldata，因为这些会对最终用户的交易费用产生重大影响。

这篇文章概述了许多可用于减少 calldata 的技术，但我希望随着“优化器”将他们的注意力转向 layer 2，会出现更多技术。

有什么想法或问题？请在 Twitter 上与我联系 @dmihal。

L2Fees.info 是 CryptoFees 网站系列的一部分，旨在提供数据驱动的视角来帮助理解加密生态系统。在 Twitter 上关注 @CryptoFeesInfo，或 加入我们在 Telegram 上的社区。

• 原文链接： l2fees.info/blog/rollup-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～