Arbitrum 的费用仪表盘：ArbGasInfo 预编译合约里能读到什么

费用分两半，参数住在一处

在 Arbitrum 这样的乐观 Rollup 上发一笔交易，你付的钱大致分两块：L2 自己的执行气体，以及把批次数据发布到以太坊的费用。很多人只盯着钱包里的 gas price，却不知道第二块是另一套算法在定的。Nitro 升级后，Arbitrum 大量使用 calldata 压缩，官方的预编译参考页还特别写明：在计费口径上不再区分值为零与非零的 calldata 字节。想把这些定价参数看清楚，链上其实留了一块只读的仪表盘——ArbGasInfo。

仪表盘住在固定地址

在每层 Arbitrum 子链上，ArbGasInfo 都预编译在固定地址 0x000000000000000000000000000000000000006C。所谓预编译，是由节点客户端原生实现的特殊合约，调用它不执行字节码。同一族里还有几个常搭档：0x0000000000000000000000000000000000000064 的 ArbSys 提供系统级功能，0x000000000000000000000000000000000000006E 的 ArbRetryableTx 管理跨链重试票据，0x000000000000000000000000000000000000006D 的 ArbAggregator 配置交易聚合者，0x0000000000000000000000000000000000000070 的 ArbOwner 与 0x000000000000000000000000000000000000006B 的 ArbOwnerPublic 记录链管理员。用 eth_call 直接读它们，不花 gas，也不产生交易。

每个方法告诉你什么

按官方参考页的方法清单，可以把关心的信号分成几组：

• 看 L1 侧估价：getL1BaseFeeEstimate() 返回 ArbOS 当前对以太坊基础费的估计，getL1BaseFeeEstimateInertia() 返回这个估计更新得有多”迟钝”。如果看到 L1 费用已经骤降、L2 的数据费却半天不动，通常就是这个惯性参数在起作用。
• 看 L2 侧供需：getGasAccountingParams() 一次带回速度限制、缓冲池大小与区块气体上限；getGasBacklog()、getPricingInertia()、getGasBacklogTolerance() 分别告诉你积压了多少超速用气、基础费因此涨得多慢、多少积压会被宽容不计。看到最低接受价 getMinimumGasPrice() 上调，往往对应的是积压在恶化。
• 看单交易与账本：getCurrentTxL1GasFees() 返回当前这笔交易为批次发布付了多少钱；getL1PricingSurplus() 与 getL1FeesAvailable() 披露数据发布资金池的盈余（可为负）与可用余额。参考页还标注了一批自 ArbOS 20 起可用的方法，例如均衡单元参数与上次更新时间，升级前后方法清单并不完全相同。

为什么要专门读这些参数

乐观二层的一笔费用里，数据发布那部分是排序器替你把交易字节压进批次、再发到以太坊产生的，它会随以太坊的基础费波动，而不是随你交易的复杂程度波动。钱包上显示的总估价把这两块揉成一个数字，单看它你分不清是”L2 拥堵”还是”L1 太贵”。把这块只读合约当分诊台，能省下大量猜时间：如果 L2 的最低接受价与积压同步上升，那是这条子链自己拥堵，加大优先费有意义；如果积压不高、但数据费分量占大头，那是以太坊主网侧的账单在涨，你在二层里再怎么加价也压不下这块。

怎么把读到的数当真

官方文档建议把这块仪表盘与节点层的模拟接口配合使用：前者给出账本里记录的事实参数，后者给出节点即时估算，两者口径不同本身就是一条信息。交叉核验时记住三条边界。第一，这些方法读到的是”记账参数”，不等于你此刻向任何一家服务商询价得到的最终价格，各家对数据的加工方式不同。第二，链管理员可以调参——管理员合约里就有修改惯性、费率相关参数的入口，看到参数突变先核对管理员的链上操作记录，不要直接误读成协议升级。第三，同一套系统合约被 Arbitrum 生态的多条子链共用，地址相同而参数各自独立，比较两条链的费用画像之前，先确认每一次读取分别发生在哪条链上，跨链混读是这类核验里最常见的错误。

风险提示

费用与气体参数随网络状态和链配置持续变化，本文描述以官方文档口径为准；文中方法名与地址仅为核验入口，不构成投资建议。