L2费用金库：使用反馈控制为L1成本定价 - Layer 2

作者：Lin Oshitani（Nethermind Research）和 Ulysse Pavloff（伯尔尼大学）。

感谢 Conor、Ahmad、Gustavo、Daniel、David 和 Yuewang 参与讨论和/或审阅。

这项工作由 Taiko 资助，属于 Taiko<>Nethermind 战略合作伙伴关系 的一部分。

TL;DR

在 L2 上为 L1 发布成本定价，可以被表述为一个 控制问题：一个 vault 跟踪 L2 fee 收入与 L1 发布成本之间的累计差额，而 L2 fee 就是保持该 vault 平衡的控制杠杆。我们使用一个由历史 L1 base/blob fee 数据驱动的模拟器，比较多种用于在 L2 上为 L1 成本定价的 fee 公式和 controller 设计。

引言

Fee Vault 抽象

在 L2 上为 L1 发布成本定价，可以通过一个核心抽象来理解：vault。每笔 L2 交易都会支付一笔流入 vault 的 fee，而每次 L2 向 L1 发布数据或证明时，成本都会从 vault 中流出。任意时刻的 vault 余额反映的是已收取的 L2 收入与已发生的 L1 成本之间的累计差额。在实践中，这个 vault 可以是部署在 L2 上的一个 smart contract，用来累积 L2 fee，并在来自 L1 的实际上报发布成本时跟踪这些成本——关于其工作方式，请参见 Implementation Notes。

在这种框架下，一个健康的 vault——即没有持续性赤字或盈余的 vault——意味着 L2 fee 收入与 L1 发布成本在长期内大致保持平衡。vault 赤字意味着 sequencer 实际上在补贴 L1 发布成本；vault 盈余则意味着交易发送者被系统性多收费。因此，vault 相对于目标值的偏离为评估 fee 机制提供了一个自然指标。我们使用术语 vault health 来描述这种平衡；更精确的刻画见 What Makes a Good Fee Mechanism? 一节。

L2 protocol 可以直接控制向用户收取的 L2 fee。通过调整该 fee，protocol 可以影响 vault 余额：提高 fee 会增加流入（将 vault 向上推），降低 fee 会减少流入（让 vault 向下漂移）。一个自然目标是设置 fee，使 vault 随时间跟踪其目标值，对 L1 成本和 L2 需求的变化作出反应，同时将 fee 波动保持在足够低的水平，让用户能够体验到可预测的交易成本。

这种框架——一个具有可测量状态（vault balance）、目标（vault target）和可调输入（L2 fee）的系统——正是经典的控制理论场景。

Fee vault（或 pools）最初由 Arbitrum 在其 Fee Pool post 中提出。本文在多个方面扩展了 Arbitrum 的 Fee Pool 思路：

1. 将 L2 fee 定价表述为一个通用的控制理论问题。
2. 引入一个 feedforward 项，从而形成一个统一理论来涵盖从 OP stack 到 Arbitrum 的主要 L2 fee 机制。
3. 在去中心化 sequencer 场景下考虑该问题。
4. 使用一个基于历史 L1 数据的模拟器比较 controller 设计。
5. 记录并分析 Arbitrum Nitro 的 L1 定价 controller——这一设计在其他地方缺乏良好文档——并在模拟中将其与其他方法进行比较。

控制理论类比：恒温器

控制理论中的一个经典例子是恒温器：房间有一个当前温度（可测量状态）、一个期望温度（目标）、一个输出可调的加热器（控制输入），以及天气或开窗等外部因素（扰动）。controller 读取温度，计算与目标的差距，并调整加热功率来缩小这个差距。

总结来说，对于恒温器：

• Measured state → 房间温度
• Target → 期望温度（例如 22°C）
• Control input → 加热器输出
• Disturbance → 天气、开窗等

一个基础 controller 只对测量状态与目标之间的差距作出反应；它会等到误差出现后才进行修正。这就是 feedback：它在扰动已经影响系统之后，对其效果作出反应。对于恒温器而言：

• Feedback → 测量房间温度，并根据其与目标温度之间观测到的差距来调整加热器。

相比之下，一个feedforward 项会直接对扰动的成因作出反应，在影响传导到系统之前就进行处理。对于恒温器而言：

• Feedforward → 感知室外温度或查阅天气预报，提前调整加热器输出。

映射到 Fee Vault

fee vault 可以直接映射到这一结构：

• Measured state → vault balance
• Target → vault target
• Control input → L2 fee
• Disturbance → L1 base/blob fee 波动、L2 需求变化

fee vault controller 可以同时使用 feedback 和 feedforward：

• Feedback → 观察 vault balance，并根据与目标余额之间观测到的差距来调整 L2 fee。
• Feedforward → 观察当前的 L1 base fee 和 blob fee，并直接将其计入 L2 fee，而不是先等 vault balance 下跌。

事实上，在这个框架中，像 Optimism 这样的链所使用的常见 L2 fee 机制，可以被视为纯 feedforward 设计。这些系统根据 sequencing 时观测到的 L1 base fee 和 blob base fee，估算每笔交易的 L1 发布成本，并据此向用户收费。换句话说，它们是基于 sequencing 时做出的估算来为 L1 数据定价，而不是基于 batch 实际提交时实现的发布成本。另一方面，它们不会维护一个 vault，也不会对累计盈余或赤字作出反应。从控制理论角度看，它们通过 feedforward 项将扰动（L1 成本）直接传递到 fee，而不在 vault 中跟踪已实现成本，也不使用来自 vault 状态的 feedback。

这个 feedback + feedforward 框架可以被看作一个统一框架，涵盖了所有主要的、用于回收 L1 成本的 L2 fee 策略。纯 feedforward（在 sequencing 时按每笔交易的 L1 成本收费）、纯 feedback（fee 仅由 vault 赤字驱动）以及混合设计，都只是这个框架中的特例。

关于去中心化 Sequencer 的说明

带有 feedback 控制的 vault 机制，尤其适用于具有多个轮换 sequencer 的 rollup，例如 Taiko 的设计，原因有三点。

1. 它不仅对 L1 成本变化作出反应，也能对需求变化作出反应。 纯 feedforward 设计无法感知 L2 侧需求的变化。如果需求下降，较少的交易要覆盖相同的固定发布成本，余额会被悄悄侵蚀，但 feedforward 机制不会注意到这一点。中心化 sequencer 可以通过等到 batch 装满后再发布来缓解这一问题，从而让需求基本保持恒定。轮换 sequencer 没有这种余地：每个 sequencer 只有有限窗口，且必须在截止时间前发布，因此如果在其窗口期间需求较低，它们就会以大致相同的 L1 成本发布一个更小的 batch，从而显著提高单笔交易成本。vault 能捕捉到这一点，因为需求变化会表现为流入变化——进而表现为 vault health 恶化——然后 controller 会据此调整 fee。
2. 它可以在 sequencer 之间平滑 L1 成本峰值。 没有 vault 时，每个 sequencer 都必须承担其 slot 期间碰到的任何 L1 成本。如果某个 sequencer 恰好遇到 base fee 激增，它就要独自吞下全部成本。有了 vault，protocol 就可以从共享池中补偿 sequencer，因此 L1 成本峰值会随时间被平滑，而不是落到某个倒霉 sequencer 身上。这需要防范那些不承担全部成本的 sequencer 进行鲁莽发布；详见 [Q1] How do we prevent reckless posting under reimbursement?。这使 sequencer 经济更可预测，并鼓励它们即使在 L1 条件剧烈波动时也继续参与。
3. 它能够实现对错过 proposal 的激励式恢复。 假设某个 sequencer 错过了向 L1 发布的窗口。没有 vault 时，选择要么是错过的 batch 触发一次 L2 reorg（糟糕的 UX），要么是另一个 sequencer 自掏腰包恢复它而得不到补偿（糟糕的激励）。共享 vault 解决了这个问题，因为下一个 sequencer 可以将错过的 batch 与自己的 batch 一起发布，从恢复的 batch 中收取 fee 收入中的 L1 成本部分作为补偿。

什么样的 Fee 机制才是好的？

在比较具体的 fee 公式之前，值得明确说明我们希望它们实现什么。我们从两个维度评估机制：vault health 和 fee volatility。

• Vault health 衡量机制在长期内让 vault balance 保持接近其目标值的能力。如果一个机制能避免深度或持续性赤字，并在成本冲击后以合理速度回归目标值，那么它在这个维度上表现良好。如果 vault 长时间偏离目标值，或持续振荡而无法稳定下来，则表现较差。
• Fee volatility 衡量从用户视角看 L2 fee 变化的突兀程度。大幅或频繁的跳变会让 fee 变得更不可预测，即使长期平均值并未改变。

这些目标天然存在张力。为了让 vault 接近目标而激进反应的机制，往往会更直接地把冲击传递给用户，从而增加 fee volatility。相反，那些为用户平滑 fee 的机制，往往会让 vault 吸收这些冲击，从而导致更深或更持久的目标偏离。下文研究的设计位于这一权衡的不同位置。

值得强调的是，在仅有 feedforward 的设计中，vault 最好被理解为一种会计抽象：它跟踪 fee 收入与已实现 L1 发布成本之间的累计差额。而在基于 feedback 的设计中，vault balance 会成为用于设定 fee 的控制信号的一部分，并且可能对应一个显式的链上合约。

Fee 公式说明

问题设定

在这一控制理论框架下，核心设计问题是：到底应该如何根据当前的 vault balance 和观测到的 L1 成本来更新 L2 fee？ 对这个问题的不同回答会导向不同的 controller 设计。本文研究的 controller 由两个概念上不同的组成部分构成。

第一部分是 feedforward 项（FF）：它是对当前 L1 发布成本的直接估计，来源于 sequencing 时观测到的 L1 base fee 和 blob fee。FF 完全不使用 vault 状态，它是在扰动影响 vault 之前就为其定价。

第二部分是一组 feedback 项，用于修正 vault balance 与其目标之间的差距：

• P（比例）：对当前赤字 epsilon(t) 作出反应
• I（积分）：对一段时间内累计的赤字作出反应
• D（微分）：对赤字变化的速度作出反应

FF 和 feedback 项的性质并不相同：FF 是预测，而 P/I/D 是修正。尽管如此，它们仍可以被视为模块化构件：一个 controller 可以单独使用其中某个项、组合多个项，或者混合 feedforward 和 feedback 项。这里研究的机制是这个更广泛设计空间中的一些示例组合：仅 FF、仅 P、PI（比例 + 积分）、P+FF，以及 Arbitrum 风格的 controller，后者最好理解为 PD（比例 + 微分）。

假设与范围：

• 非弹性需求。 在全文中我们都将需求视为非弹性——在某个 fee cap 之下，更高的 fee 总会增加 vault 流入。如果需求是弹性的，controller 可能会变得不稳定：提高 fee 反而把用户赶走，使赤字加深而不是缩小。有关缓解方法，参见 [Q3] What if the fee gets too high and drives users away?。
• 仅考虑 L1 成本。 本文聚焦于 L2 fee 中的 L1 成本部分。L2 拥堵定价（根据 L2 block 利用率调整 fee）是一个正交问题，可以独立叠加，因为拥堵定价响应的是 L2 利用率，而 vault controller 响应的是 L1 成本缺口。
• 抽象化的按交易数据核算。 在实践中，每笔交易所分担的 L1 发布成本取决于它对待发布 batch 的数据贡献量。在全文中，我们抽象掉这种按交易的数据核算，并将 F(t) 视为每单位数据的 fee。

符号说明

通用变量：

• t：当前时间步（即 block timestamp）
• F(t)：在时间 t 收取的 L2 fee（controller 的输出）
• V(t)：时间 t 的 vault 值
• V_target：目标 vault 值
• delay：以 L1 block 为单位的观测延迟（用 Taiko 的术语来说，即 anchoring lag——当前锚定的 L1 block 相比最新 L1 head 落后多远）
• epsilon(t)：时间 t 的归一化赤字比率，定义为 (V_target - V(t - delay)) / V_target
• F_min：允许的最小 fee
• F_max：允许的最大 fee
• FeeRange：fee 范围，定义为 F_max - F_min
• clamp(x, lo, hi)：将 x 限制在区间 [lo, hi] 内——如果 x 小于 lo 则返回 lo，如果大于 hi 则返回 hi，否则返回 x 本身

模拟设置

本文中的所有模拟都由 365 天的 Ethereum mainnet 历史 base fee 和 blob base fee 数据驱动（2025-02-06 到 2026-02-06），如下所示：

这个时间窗口包含了一个值得注意的 blob fee 峰值，出现在 L1 block 22389679 附近，在比较不同 fee 机制对峰值的反应时，这一位置很适合放大观察：

关键模拟参数：

• 数据发布频率： 每 10 个 L1 block 一次
• L2 TPS： 1 tx/s
• Vault target： 10 ETH
• Fee 范围： 0.01–1 Gwei

这些参数的选择是为了尽量真实且具有说明性，而不是针对某个特定部署进行校准。L1 fee 数据和 controller 模拟可以在这个 simulator UI 中进行交互式探索。

仅 Feedforward（FF-only）

仅 feedforward 方法是当前部署最广泛的方法，被 Optimism 和其他主要 L2 使用。其思想是在 sequencing 时估算 L1 发布成本，并直接向用户收取，不使用 vault，也没有 feedback 回路。从控制理论角度看，这是一种纯 feedforward：controller 观察 L1 成本（扰动），并在其实际变成发布成本之前将其定价进 fee 中。

公式如下：

• BaseFee(t)、BlobFee(t)：时间 t 的 L1 execution base fee 和 blob base fee。
• alpha_gas、alpha_blob：将 L1 gas 和 blob 成本转换为每笔 L2 交易分摊份额的缩放权重。

FF(t) = alpha_gas * BaseFee(t - delay)
      + alpha_blob * BlobFee(t - delay)

F(t)  = FF(t)

这里的 delay 参数反映了一种 trust/latency 权衡。具有受信任 sequencer 的链（例如 Optimism）可以通过 oracle 将最新的 L1 base fee 和 blob fee 推送到 L2，因此实际上以 delay ≈ 0 运行。一个无信任替代方案是通过链原生的 L1→L2 消息路径导入 L1 状态（例如 Taiko 的 anchor transaction 或 Arbitrum 的 delayed inbox），这样可以避免对 oracle 的信任假设，但会引入若干个 L1 block 的观测延迟。

模拟与分析

尽管 FF-only 不把 vault 作为输入，我们仍在模拟中跟踪其隐含的 vault balance，作为评估指标。结果如下：

这种方法的优缺点如下：

优点：

• 在 fee 仍有调整空间的时期——也就是尚未被最大值封顶时——vault 能较好地跟踪其目标值。

缺点：

• FF-only 也会让 L2 用户直接暴露于 L1 fee 波动之下。虽然为简化起见，本文假设需求是非弹性的，但那些与 L2 需求无关的 fee 峰值可能会特别严重地冲击用户，因为此时支付意愿并没有增加，从而使需求在事实上更具弹性，并增加在 L1 峰值期间扼杀 L2 活动的风险（这与需求驱动的峰值不同，后者通常伴随更高的支付意愿）。有关是否以及如何平滑这种波动，参见 [Q2] How much should L2 fees be isolated from L1 fee fluctuations?。
• FF-only 能为当前的 L1 条件定价，但无法修复累计的遗漏收入。这些遗漏主要来自大规模 L1 峰值期间的 F_max 截断。一旦峰值过去，就没有 feedback 项把 vault 推回目标值。

下方对 F_max 的扫描尤其清晰地展示了这一权衡。将 F_max 从 1 gwei 提高到 2、5 和 10 gwei，会显著改善 vault health，因为更少的 L1 峰值被截断，更多的实际发布成本被传递给用户。但代价是明显更高的 fee volatility：

P-controller（仅 P）

P-controller 直接根据当前的 vault 赤字来设定 fee：vault 越低于目标值，fee 就越高，反之亦然。它的权衡是：如果 vault 稳定在一个持续存在的小赤字上，P-controller 会无限期地施加同样微弱的修正而不继续增强，导致 vault 始终略低于目标值。（稳态偏差）

• Kp（比例增益）：控制 fee 对当前赤字的反应有多激进。更高的 Kp 表示每单位赤字会带来更强的修正。

公式如下：

P(t) = Kp * epsilon(t) * FeeRange
F(t) = clamp(P(t), F_min, F_max)

模拟与分析

结果如下图所示。第一张图展示 controller 随时间收取的 L2 fee，第二张图展示 vault balance 的轨迹。红线标记目标值，蓝线跟踪实际 vault 值（向下移动表示赤字扩大）。

放大观察 blob fee 峰值附近时：

这种方法的优缺点如下：

优点：

• 与 FF-only 相比，P-controller 的 fee volatility 较低，因为它响应的是累计的 vault 误差，而不是把每一次 L1 成本峰值都直接传递出去。
• 它可以随着时间恢复 vault health。冲击之后，fee 会维持在较高水平，直到 vault 恢复，而不是在 L1 峰值过去后立刻回落。

缺点：

• controller 完全是被动反应的，因此对于突发的 L1 成本峰值，需要一段时间后才会反映到 L2 fee 中。
• 它存在稳态偏差：一旦 vault 略低于目标值，controller 可能会稳定在一个略高的 fee 上，使 vault 接近目标值，但无法精确回到目标值。

这一权衡在 L1 block 22389679 附近的 blob fee 峰值中表现得尤其明显，如下图所示并与 FF-only 进行对比。蓝线是仅 P，绿线是 FF-only，并被封顶在 1 gwei。

PI Controller

解决 P-controller 稳态偏差的常见方法，是增加一个积分项。积分会随时间累计赤字信号，因此如果 vault 长时间低于目标值，controller 就会施加越来越强的修正，直到偏差被消除。

• Ki（积分增益）：控制 fee 因持续赤字而上升的激进程度。
• I_acc(t)（积分累加器）：赤字信号的运行和。
• I_min、I_max：积分状态的边界（用于anti-windup）。

公式如下：

I_acc(t)  = clamp(I_acc(t-1) + epsilon(t), I_min, I_max)

P(t)      = Kp * epsilon(t) * FeeRange
I(t)      = Ki * I_acc(t) * FeeRange

F(t)      = clamp(P(t) + I(t), F_min, F_max)

模拟与分析

结果如下，蓝色为仅 P，棕色为 PI controller。

如果放大到 blob fee 峰值时段：

PI-controller 的优缺点如下：

优点：

• PI 解决了 P-controller 的稳态偏差：如果 vault 长时间低于目标值，积分项会不断累积，并把 fee 推高到足以弥合剩余差距。
• 在经历长时间赤字后，PI 往往比仅 P 恢复得更快，因为积分项保留了持续误差的“记忆”。

缺点：

• 积分项可能导致过冲：在条件恢复正常后（例如 L1 峰值过去后），累积的积分仍可能使 fee 保持高位，暂时将 vault 推高到目标值之上，从而增加用户视角下的 fee volatility。
• PI 引入了额外的调参复杂性（Ki 和 anti-windup 边界的选择）。调参不佳可能导致振荡或收敛缓慢。

P + Feedforward（P+FF）

P+FF 是在单个 controller 中组合 feedforward 和 feedback 项的一个例子。在这里，feedforward 项会立刻将观测到的 L1 条件定价进 fee，而比例项仍然用于修正任何剩余的 vault 赤字。

FF(t) = alpha_gas * BaseFee(t - delay)
      + alpha_blob * BlobFee(t - delay)

P(t)  = Kp * epsilon(t) * FeeRange          // 与上面相同的比例项
F(t)  = clamp(FF(t) + P(t), F_min, F_max)

模拟与分析

P+FF 最适合通过与仅 P 在 blob-fee 峰值附近进行直接比较来评估，因为在这里这种权衡最明显：

这种方法的优缺点如下：

优点：

• 它让 vault 比仅 P 更接近目标值，因为预期的 L1 成本有一部分会在发布成本真正冲击 vault 之前就被计入 fee。

缺点：

• 它会把更多的 L1 波动直接传递给用户，因此产生比仅 P 更高的 fee volatility。

在实践中，这次模拟中相较于仅 P 的 vault-health 改善幅度并不大，因此是否值得付出额外的 fee 波动代价，是存疑的。

Arbitrum 风格 Controller

上述 controller 只会对 vault balance 相对于目标值的位置作出反应。Arbitrum Nitro 的 L1 定价 controller 还会对差距变化的速度和方向作出反应。除了“比例”信号之外，它还对 vault 值进行“微分”。从这个意义上说，它最好被理解为一个PD风格的 controller。

• F(t)：更新 t 之后的有效 fee 水平
• U(t)：在发布区间中消耗的数据单位（在 Nitro 中：压缩后的 calldata 字节数 × 16）
• EquilUnits：平衡周期，即用多少数据单位来消化当前盈余。值越大，修正越温和。
• Inertia：设定阻尼中点。InertiaUnits = EquilUnits / Inertia 是恰好施加一半修正时的区间大小。

InertiaUnits       = EquilUnits / Inertia
desiredSlope(t)    = -S(t) / EquilUnits
actualSlope(t)     = (S(t) - S(t-1)) / U(t)
slopeCorrection(t) = desiredSlope(t) - actualSlope(t)
feeChange(t)       = slopeCorrection(t) * U(t) / (InertiaUnits + U(t))
F(t+1)             = max(0, F(t) + feeChange(t))

该 controller 以盈余 S(t) = V(t) - V_target 为工作变量（注意其符号与前文使用的赤字 epsilon(t) 相反），并在每次发布事件后增量更新一个有效 fee F(t)。根据当前盈余，它会计算一个 desiredSlope，表示盈余必须以多快的速度变化，才能在 EquilUnits 规定的数据量内回到零。当发生一次 L1 batch 发布时，它会计算 actualSlope，也就是盈余实际上每单位数据变化了多少。fee 会根据二者之间的差距进行调整：slopeCorrection = desiredSlope - actualSlope。

然而，actualSlope 是有噪声的，尤其是在消耗的数据单位很少（U(t) 很小）时。为了避免过度反应，修正会按 U(t) / (InertiaUnits + U(t)) 进行缩放：当 U(t) 很小时，大部分修正会被抑制；当 U(t) 很大时，大部分修正会被应用；当 U(t) = InertiaUnits 时，恰好应用一半修正。

模拟与分析

下图比较了 blob-fee 峰值附近 Arbitrum 风格与仅 P 的表现：

优点：

• 在峰值窗口中，它比仅 P 实现了更好的 vault health，下探更浅。
• fee volatility 远低于 FF-only。

缺点：

• fee volatility 高于仅 P；fee 会在低值和高值之间反复跳变，而不是像仅 P 那样沿着更平滑的驼峰形路径变化。
• 与普通 P-controller 相比，这个 controller 更难理解和调参，因为其行为取决于 EquilUnits、Inertia、发布节奏以及区间大小 U(t) 之间的相互作用。

模拟结论

模拟指向了一个一致的权衡：更好的 vault health 通常要以更高的 fee volatility 为代价。

• P-controller 在这些模拟中提供了最低的 fee volatility，但 vault health 中等，同时也能随着时间恢复赤字。它的主要弱点是 vault health 恢复速度不是最快的，而且对突发的 L1 成本峰值需要一段时间才能作出反应。
• Arbitrum 风格 在 vault health 上强于仅 P，但代价是比仅 P 更高的 fee volatility，尤其是在 L1 成本峰值这样的尖锐压力事件附近；不过它的 fee 更新也更锯齿化，复杂度更高。
• FF-only 在 fee 有足够余量时（即 F_max 足够高，使峰值不被截断）可以很好地跟踪已实现的 L1 成本，但它会把 L1 波动直接传递给用户。而且如果在大峰值期间 fee 被 F_max 封顶，它无法在之后恢复遗漏收入，因为没有 feedback 项把 vault 推回目标值。
• P+FF 相较于仅 P 改善了 vault health，但在这次模拟中，这种收益相较于把更多 L1 波动直接注入 fee 所带来的 UX 成本来说，并不显著。
• PI-controller 相较于仅 P 改善了稳态跟踪能力，但可能引入过冲和更多面向用户的 fee 波动。

总体来看，模拟表明，如果 L2 fee 波动是一个关注点，那么主要的设计选择是在 仅 P 和 Arbitrum 风格 之间：如果优先考虑 fee 平滑性、实现简单性和可预测性，则选择仅 P；如果更紧的目标跟踪值得接受更嘈杂的 fee 和更复杂的 controller，则选择 Arbitrum 风格。虽然 PI 减少了稳态偏差，但它往往会过冲，而且调参复杂，使它的吸引力下降，尤其是在仅 P 的稳态偏差仍处于可接受范围内时。

值得注意的是，这里探索的 controller 只代表了广阔设计空间中的很小一部分。还有许多其他 controller 架构，包括 PID controller 的其他变体、自适应增益方案，以及以不同比例混合 feedback 和 feedforward 的混合设计，仍未被探索，留待未来工作。

实现说明

在实践中，L1 发布成本必须从 L1 导入到 L2，才能在位于 L2 上的 vault 中进行核算。高层流程如下：

1. 在 L1 上记录 L1 成本。 当 sequencer 将 L2 数据或证明发布到 L1 时，L1 inbox contract 会记录实际发布成本（gas used × base fee，blob count × blob fee）。
2. 通过 L1→L2 消息导入到 L2。 记录的成本会通过链的 L1→L2 message-passing 机制传递给 L2 fee vault contract。在 Taiko 中，这是通过 anchor transaction 完成的——每个 L2 block 都包含一个 anchor，用来导入最新的 L1 状态，包括任何新记录的发布成本。Arbitrum 使用 delayed inbox 机制。
3. 更新 vault balance 并计算 fee。 L2 上的 fee vault 从其余额中扣除导入的成本，得到更新后的 V(t)。然后 controller 使用这个余额来计算下一个 L2 fee F(t)。

这意味着，vault 对 L1 成本的视图天然存在延迟。它只能反映那些已经在 L1 上记录并且已经导入到 L2 的成本。这个延迟由上文 controller 公式中的 delay 参数表示。

开放问题

[Q1] 如何在补偿机制下防止鲁莽发布？

如去中心化 Sequencer 说明一节所述，vault 可以补偿 sequencer 的 L1 发布成本。但这会带来潜在的道德风险：sequencer 可能会过于频繁地发布（小而低效的 batch）、不能把握时机避开 L1 fee 峰值，或者在 priority fee 上出价过高——因为无论如何成本都是由 vault 吸收。

可考虑的缓解措施：

• 在补偿公式中使用固定 priority fee，或者完全不考虑 priority fee。 这会限制 vault 愿意覆盖的部分——如果某个 sequencer 在 priority fee 上过度支付，超出部分由其自行承担。
• 将补偿上限设定为低于 100%（例如 90%），当 sequencer 亏损发布时也不全额报销。这样可以让 sequencer 始终有“skin in the game”，从而激励其以成本更高效的方式发布。

[Q2] L2 fee 应该在多大程度上与 L1 fee 波动隔离？

任何带有 feedforward 组件的 controller（FF-only、P+FF）都会将 L1 base fee 和 blob fee 的波动直接传递到 L2 fee 中。这种波动对 L2 需求来说是外生的。在 L1 上，fee 峰值是由需求驱动的，因此造成拥堵的用户就是付费的人，更高的 fee 不一定会扼杀活动。而在 L2 上，情况不同：L1 成本峰值（例如 L1 上的一次 Token 发售）会抬高 L2 fee，但 L2 用户的支付意愿并没有相应上升。由于 L2 用户没有理由去为这种峰值赋予更高价值，需求弹性会更陡，从而增加扼杀 L2 活动的风险。

这就引出了一个设计问题：vault 是否应该有意吸收短期 L1 峰值以降低 fee volatility，还是应该将其传递出去以获得更紧的 vault health？

[Q3] 如果 fee 过高并把用户赶走了怎么办？

上述所有 controller 都假设，在某个 fee 上限（F_max）内，更高的 fee 会带来更大的 vault 流入。但在实践中，如果 fee 升得太高，用户会停止交易，而交易量的下降可能会完全抵消、甚至超过单笔交易 fee 的上升。这会形成一个死亡螺旋：高 fee → 更少交易 → 更深赤字 → 更高 fee。

已经存在的缓解措施：

• F_max clamp：所有 controller 都会施加一个硬性 fee 上限，这是防止 fee 被推得过高的主要保护措施。

在假设 F_max 足够低、不至于赶走显著需求的前提下，当前模拟结论成立。但这仍然只是一个假设；如果 F_max 高于需求开始变得弹性的点，那么 controller 仍可能进入上述“死亡螺旋”。

可考虑的额外缓解措施：

• 在假设需求弹性曲线的条件下进行模拟： 在一个交易量会随着 fee 上升而下降的模型下运行 controller 模拟，以测试其在非非弹性区间之外的稳健性。
• 监控并响应需求变化： 跟踪滚动的 L2 gas 使用量，并在一次 fee 上涨后交易量快速下降时自动放缓 fee 上调。

• 原文链接： ethresear.ch/t/the-l2-fe...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～