这篇文章讨论了Optimism rollups的 calldata 压缩技术,旨在通过优化交易数据存储来减少用户费用。文章详细介绍了不同压缩算法的性能评估以及它们在历史交易数据应用中的效果,预计将通过引入新的压缩技术降低费用30-40%。同时,作者也提到未来将继续开发更先进的压缩策略以进一步降低成本。
这篇文章是关于实现低于一美元 ORU 交易的系列文章中的第二篇。要了解完整背景,请查看 第一篇 !
Optimistic rollups 正在迅速成熟。当我们步入“从零到一”阶段之后,优化成为了游戏的关键,最直接的优化就是成本。在接下来的一个月内,我们将通过在任何生产 ORU 网络上部署首个系统范围的 calldata 压缩,降低 30-40% 的费用。做好准备。
展望未来,我们计划在这个夏天通过 Optimism: Bedrock 解锁更多的节省。这篇文章深入探讨了 calldata 压缩的细节:特别是我们如何评估压缩算法,以及如何利用它们为低于一美元的费用铺平道路。
Optimism 使用 Ethereum 作为数据可用性层。这意味着在 Optimism 上执行的每笔交易都会被存储(但不会被执行)在 Ethereum 上。目前,我们将 Optimism 交易存储在 calldata 中。多个 L2 交易被打包成一个二进制 blob,该 blob(加上一些其他信息)被存储在交易的数据字段中。为了后续检索这些数据,我们查看交易的主体(这些交易保存在区块中)。由于 Ethereum 块被保存,因此 Optimism 链始终可以从 Ethereum 中重建。
虽然在区块中存储数据相比于在合约状态中存储数据要便宜得多,但无限期保存历史区块仍然会对节点运营商产生成本。因此,Ethereum 对 calldata 收取费用。每个零字节的费用为 4 gas,每个非零字节的费用为 16 gas(零字节在提交给 Optimism 的交易中约占 40%)。
虽然发布 calldata 是 rollup 节省的很大一部分来源,但它仍然是传递给用户的主要成本。因此,我们越能减少发布的数据量,越能降低 rollups 的成本。引入压缩:减少数据大小的艺术!接下来是对在实际数据上进行的压缩统计分析的深入讨论。
我们调查了 Optimism 提交给 Ethereum 的 22000 个批次(近 300 万个独立交易),并在不同配置下对其进行压缩,以确定最佳的压缩实施方法并尝试可能的结果。
我们还查看了多种压缩算法,测量了压缩率(压缩数据的大小占未压缩大小的百分比)和预计的费用节省(假设交易中 40% 的字节是零字节)。
一个重要的配置选项是字典的存在。字典预先创建,以向算法展示在现实世界数据中常用的数据片段。压缩算法利用字典来更好地压缩数据,特别是在一次压缩少量数据时。通过随机抽样交易,我们可以为 zlib 和 zstd 创建一个字典,这将提高压缩单个交易和批次的压缩比。
由于 Ethereum 交易中的大多数字段是随机的(地址和函数选择器是哈希,签名应该是随机的),单个 Ethereum 交易的压缩效果不佳。因为 Ethereum 还大幅优惠零字节,压缩算法很快去除这些零字节,因此费用节省不会像压缩率那么大。因此,为了获得最高的费用节省,我们需要对尽可能多的数据运行高级算法。
以下是单独压缩交易的结果:
compressiontable1.csv – Medium
算法 | 模式 | 使用字典? | 压缩率 | 预计费用节省 | |
---|---|---|---|---|---|
zlib | 交易 | 否 | 63.97% | 8.61% | |
zlib | 交易 | 是 | 59.33% | 15.24% | |
zstd | 交易 | 否 | 62.87% | 10.18% | |
zstd | 交易 | 是 | 48.31% | 30.99% | |
LZW | 交易 | 否 | 68.29% | 2.44% | |
Brotli | 交易 | 否 | 65.78% | 6.02% | |
ZLE | 交易 | 否 | 59.37% | 15.18% |
查看原始 individual-transactions.csv 由❤提供的 GitHub
如你所见,单独压缩交易仅能获得 10–15% 的节省。请注意,交易的大小减少多于此,但节省较少,这是因为上面讨论的更便宜的零字节。
使用字典的 Zstandard 性能显著更好,因为每个交易之间以及存储在字典中的内容具有共性。然而,zstd 在压缩更大量数据时仍然表现更佳。
另外一个极端是一次性压缩每个示例交易。这在实践中不可能,但作为可能的最大压缩比的示例。
batched-transactions.csv – Medium
算法 | 模式 | 使用字典? | 压缩率 | 预计费用节省 | |
---|---|---|---|---|---|
zlib | 总计 | 否 | 38.40% | 45.14% | |
zlib | 总计 | 是 | 38.40% | 45.14% | |
zstd | 总计 | 否 | 35.92% | 48.68% | |
zstd | 总计 | 是 | 36.19% | 48.31% | |
LZW | 总计 | 否 | 62.30% | 11.00% | |
Brotli | 总计 | 否 | 34.41% | 50.84% | |
ZLE | 总计 | 否 | 59.37% | 15.18% |
查看原始 total-transactions.csv 由❤提供的 GitHub
所以,在这个例子中,由于压缩,我们期待在 10% 到 50% 之间的节省。但我们实际可以取得怎样的效果呢?
在压缩交易批次(数百笔交易)时,压缩率明显优于压缩单独的交易,但略低于一次性压缩所有交易。这是因为用户往往与某些合约的交互频繁,而某些字段(如链 ID 和 gas 价格)在交易中往往相似。压缩算法依赖于这些相似性来完成其工作。
batched-transactions.csv – Medium
算法 | 模式 | 使用字典? | 压缩率 | 预计费用节省 | |
---|---|---|---|---|---|
zlib | 批次 | 否 | 40.13% | 42.67% | |
zlib | 批次 | 是 | 39.61% | 43.41% | |
zstd | 批次 | 否 | 40.12% | 42.68% | |
zstd | 批次 | 是 | 37.31% | 46.70% | |
LZW | 批次 | 否 | 62.24% | 11.09% | |
Brotli | 批次 | 否 | 39.21% | 43.99% | |
ZLE | 批次 | 否 | 59.37% | 15.18% |
查看原始 batched-transactions.csv 由❤提供的 GitHub
在比较不同的压缩算法时,我们识别出 zlib、zstd 和 brotli 是压缩效果最佳的算法。由于 Brotli 的速度大大慢于 zstd 或 zlib,尽管它们的压缩比类似,因此我们将其排除在外。一般而言,压缩率越高的算法(或算法的设定),其运行速度通常越慢。ZSTD 在常见基准测试中,在多种压缩速度/比率选项上表现得更好。此外,请注意,Ethereum 交易的特征与基准中的数据不同。
Zlib 和 zstd 非常接近,我们将在短期内推出 zlib 压缩(不使用字典),因为它具有相当好的结果、良好的速度以及在多种编程语言中的良好可用性。从长远来看,我们预计将依赖 zstd 以实现最高的压缩率和最低的用户费用。
总结来说:如果历史趋势持续,我们可以通过引入上述所解释的压缩,将费用降低 30–40%。
基于 Zstd 的压缩(使用字典)已在 Optimism: Bedrock 的路线图上,预计将在今年晚些时候发布。
除了通过压缩降低用户费用外,Optimism 还希望通过 EIP-4844 和类似方法来改善 Ethereum 作为数据可用性层的能力,以进一步削减成本。
暂时就是这些!敬请关注下一篇关于低于一美元交易道路上又一步的文章!哦,一如既往,如果你有兴趣加入一支致力于构建可扩展和可持续未来的优秀 Optimists 团队,我们很乐意听到你的声音!查看我们 招聘信息上的所有开放职位。
appendix.csv – Medium
算法 | 压缩选项 | 上游链接 | |
---|---|---|---|
zlib | golang 默认级别 | https://pkg.go.dev/compress/zlib | |
zstd | 第 3 级 | http://facebook.github.io/zstd/ | |
LZW | LSB, 8 | https://pkg.go.dev/compress/lzw | |
Brotli | 第 6 级 | https://github.com/google/brotli | |
ZLE | 不适用 | https://github.com/ethereum/pyethereum/blob/develop-snapshot/ethereum/compress.py |
查看原始 appendix.csv 由❤提供的 GitHub
ZLE 是零字节长度编码的缩写。它是一种简单的压缩算法,将一串零替换为应该有多少个零。
- 原文链接: medium.com/ethereum-opti...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!