来源 | github.com/arbitrum-cn

作者 | 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 文档。



点击“阅读原文”获取文章内部链接!

原文链接:

https://github.com/arbitrum-cn/Arbitrum-Library/blob/main/Share/guide/2_dimensional_fee.md



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