作者 | Arbitrum
翻译 | Arbitrum 中文社区
感谢 Arbitrum 中文社区 @arbitrum_cn 的投稿。
在几个月前的 Arbitrum 奥德赛中，Arbitrum One 经历了史无前例的用户流量。一些敏锐的用户注意到了一个奇特的现象：随着 L2 gas 价格的上升，一笔特定的交易所使用的 L2 gas 数量实际上会减少。
事实证明，这正是系统的工作原理——但对不熟悉的人来说，这看起来确实有点令人困惑。
如果你对到目前为止我们所说的内容而感到有些困惑，那这篇文章会试图把它梳理清楚；如果你实在太困惑了，甚至都不知道在困惑什么，那么欢迎你继续读下去。与此同时，你可能会发现这些关于以太坊和 Arbitrum gas 的入门读物很有用。(而且如果你已经能准确地把握这篇文章的走向，那你完全应该在这里申请一个职位: https://offchainlabs.com/careers/)。
二维费用
关于 Layer 2 的支付费用，在一个经济设计的系统中(如 Arbitrum)，你实际上是在为两件事项同时付费：L1-native 资源和 L2-native 资源。Arbitrum One 是一个 Rollup，你所支付的 L1 资源基本上只是以太坊 calldata；也就是说，你支付的是你交易的原始数据大小乘以 L2 对 L1 calldata 的价格估算（大致可以这样理解）。
你需要支付的 L2 资源是你的交易在 Arbitrum 上的通用虚拟机 (VM) 中进行的任何计算——执行、存储等。这个数值是 L2gas 价格乘以 ArbGas——Arbitrum 的基本计算单位——你的交易使用的数量。一笔交易要成功，需要支付的 L2 费用总额是这两部分的总和。
在一维的世界里...
棘手的是，尽管像 Arbitrum 这样的 L2 费用本质上是二维的，但目前的以太坊生态系统主要是在 L1 建立的，其费用可以用一维 (one-dimensional) 来表示。这意味着目前的基础设施——钱包、开发者库等等——假设交易格式中的费用是单一 gas 单位和单一 gas 价格的产物；当在 Arbitrum 上进行交易时，我们要被迫将 L1 和 L2 维度都塞进这种限制性格式中。
那么，我们是如何做到的呢？
我们是如何做到的
因此，综上所述，我们的主要限制是总费用——必须包括 L1 和 L2 费用——需要表示为两个值的乘积，我们称之为 "类似 gas 价格"(P)和 "类似 gas 限额"(G)。
我们使用的P值（由 Arbitrum 的估算 gas 价格 RPC 折返）实际上只是 L2 的 gas 价格(估算 gas 价RPC 增加了一个小百分比的缓冲；任何超出的部分都会被退回)。G 是我们考虑 L1 维度的地方；调用Arbitrum 的估算 gas，RPC 会给出一个值，其用于 L2 计算的 ArbGas 加上一个额外的缓冲区(B)，这样 P*G 最终足以覆盖全部交易成本。换句话说，我们增加了 "gas 限制 "之类的字段，以便在给定的gas 价格下支付的总金额足以支付 L1 和 L2 层面的费用。
通过一些代数运算，我们发现这个缓冲区 B 必须等于(L1 calldata 成本)/P。
因此，总的来说，G，解压为：
L2 gas 使用量+(L1 calldata 价格 L1calldata 大小) /(L2 gas 价格)*
...其中 "L2 gas 价格 "的分母（回到最初的困惑）显示了为什么在所有其他数值相同的情况下，L2 gas价格的增加，实际上是减少了 G 的价值。
迈向二维收费标准
如果这一切看起来比较麻烦——我们非常清楚这一点；我们目前被困在生态系统目前支持的一维费用基础设施中，但理想的情况是，一个多维收费标准将被采纳并被广泛使用；现有几个提案存在，我们同样也有自己的想法。如果你有兴趣帮助协调一个新的标准，请联系我们/参与我们的研究论坛。
想要了解更多关于 Arbitrum 如何处理 gas 信息，请查看我们的 Inside Arbitrum 文档。
声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系ethereumcn@gmail.com进行授权。
