Hegota分叉的Gas上限提升与带宽锚定机制

我要感谢 Toni Wahrstaetter、Marius Vanderwijden 和 Parithosh Jayanthi 为促成这份报告所进行的讨论。

这篇博文探讨了在 Glamsterdam 升级之后，Hegota 需要做出哪些改变才能持续提升 gas 上限。出发点只有一个观察：21,000 gas 的 ETH 转账同时约束了区块的两个维度。

• 在执行方面，Glamsterdam 的重新定价将成本推到了转账上限所允许的极限，将最坏情况下的执行性能锁定在 100 Mgas/s。
• 在带宽方面，一个充满转账的区块本身就是一个数据负载（包含信封、签名和 BAL 条目），任何定价工具都无法在不收取超过 21k 费用的情况下触及这些数据。

因此，我们将“全转账区块”作为锚定区块。我们推导出它的带宽性能，找到最大化 gas 上限的 PTC 截止时间，将其与对抗性 calldata + SLOAD 区块进行比较，然后探讨这对状态增长、历史和内存意味着什么。

关键发现

• 21k ETH 转账同时锚定了区块的两端。 它将最坏情况下的执行性能冻结在 100 Mgas/s，并且设定了不可压缩的字节密度约 0.0105 B/gas（每个转账最坏情况下 221 字节），这是任何定价工具都无法降低的。锚定区块的传播速度约为 214 Mgas/s，因此它受执行限制。在 25% 的对称缓冲下同时处理两个上限，可以得到 PTC 截止时间约 6.4s 时 gas 上限约 422M。我们将 25% 缓冲视为指导原则而非硬性下限，并略微放宽以得到整数：我们推荐 在 $D = 6$s 时设定为 450M，此时锚定区块的最坏情况执行缓冲约为 25%，传播缓冲约为 11%。

• Hegota 的重新定价任务是将每种已定价的组合降至转账线。 由于我们无法在不触及 21k 上限的情况下重新定价转账，因此目标是通过设计使其成为最坏情况。Glamsterdam 的定价未能做到这一点：混合 calldata + SLOAD 区块大约是转账线的 2.2 倍，从而将系统限制在约 302M，比锚定最优值低约 120M。解决方案是再次提高 calldata 下限（64 → 96）并覆盖 BAL 字节，或者引入统一的 calldata 费率（约 94）——在机制复杂性和影响广度之间进行权衡。

• 在转账线以下，只有进一步的优化才能移动最优值。 定价可以使不同组成的区块达到转账线，但不能低于它。每千字节传播时间每改进 10%，gas 上限大约增加 +14–18M，最高可达 618M。与此同时，ETH 转账执行时间的改进将允许更高的执行锚定，从而在不改变 PTC 截止时间的情况下实现更高的上限。

背景

Glamsterdam 交付了 ePBS（EIP-7732）、BAL（EIP-7928）以及重新定价包，其中包括数据定价 EIP 7976（calldata 下限 64/64，标准费率 4/16）和 7981（访问列表字节按下限费率收费）。重新定价的目标是最坏情况下的执行性能达到 100 Mgas/s。这个目标无法进一步提高：这样做将需要对 ETH 转账的 gas 成本进行重新定价，使其超过 21,000，这会破坏某些硬件钱包的功能。因此，对于 Hegota 来说，100 Mgas/s 的执行锚定是冻结的，额外的扩展必须来自优化（包括执行和传播）、PTC 截止时间的更改，以及（单独地）降低定价过高的计算操作的成本。最后一种方案会并行分析，本报告中仅在后面的一个交互点提及。

整个报告中使用的假设：

资源分布图

按约束的类型来组织资源是很有帮助的，因为这决定了每种资源如何响应更高的 gas 上限：

接下来的部分涵盖每个Slot的权衡（这设定了 gas 上限），我们将在最后回到累积资源。

将转账区块作为锚定区块

一笔转账携带多少字节？

一笔转账不写入存储，也不运行操作码，但它仍然携带字节：它的信封和签名，以及 EIP-7928 在 BAL 中为其保留的记录。

一个类型 2 的转账信封实际大小约为 110 字节：签名（r、s 各 32 字节，加上 y_parity）约 65 字节，20 字节的接收者地址加上 RLP 框架后约 21 字节，剩余的约 25 字节用于 nonce、两个费用字段、gas 上限、价值、链 ID 和空的访问列表。在表中我们向上取整到 130 字节，作为当前交易类型的最坏情况信封。

对于 BAL，一笔转账涉及两个账户（发送方：余额 + nonce；接收方：余额）。由于 RLP 以最小长度（≤ 11 字节，受总 ETH 供应量限制，而非 32）编码余额，并以 1–2 字节编码 nonce，最坏情况下的边际贡献约为 91 字节。

传播模型是基于snappy 压缩后的字节进行校准的，因此我们通过将转账区块视为不可压缩（snappy 后 ≈ 原始大小）来将这 221 字节映射到线路上。这是最坏情况安全的——签名是不可压缩的随机字节，snappy 无法处理——并且是本报告中影响最大的单一假设：任何实际压缩只会放宽约束并提高可达到的 gas 上限。在实际编码的区块上测量压缩边际字节斜率是本报告指出的影响最大的数据任务。

PTC 截止时间应该设置在哪里？

截止时间 $D$ 将Slot分为两个窗口：从 $T_1 = 3$s 到 $D$ 的传播窗口，以及从 $D$ 到 12s 的执行窗口。在两者都保持 25% 缓冲指导原则的情况下，当锚定区块能够在时间内同时完成传播和执行时，gas 上限 $L$ 是可行的：

$$ L \le 0.75 \cdot R \cdot (12 - D) \qquad \text{(执行)} $$

$$ 0.443 \cdot \beta_t \cdot \frac{L}{1000} + 569 \le 0.75 \cdot (D - T_1) \cdot 1000 \qquad \text{(传播)} $$

第一个上限随着 $D$ 的推迟而下降；第二个上限则上升。最优值是两者的交叉点：

在两个窗口都保持 25% 指导原则下，转账锚定的最优值大约是 在 $D \approx 6.4$s 时的 422M。25% 缓冲是指导原则而非硬性下限，因此我们略微放宽以推荐四舍五入的操作数——在 $D = 6$s 时设定为 450M，将截止时间稍提前以用传播余量换取更高的上限。执行缓冲保持在约 25%；传播缓冲吸收了这一变化，从 25% 降至约 11%——此时锚定区块使用约 89% 的传播窗口，而不是 75%：

剩余的不确定性在于传播拟合（p90 百分位数以及 Toni 的强调尾部与保守的 $\sqrt{n\cdot\text{size}}$ 权重）和 snappy 压缩后的假设。传播改进（下文）将恢复 450M 时的对称 25% 缓冲，或将上限推得更高。

对抗性区块

转账区块并非最坏情况

转账区块锚定了Slot，但它不是我们可以构建的最密集的区块——它的 $\beta_t \approx 0.0105$ 字节/gas 是一个下限，而非上限。由于我们无法在不触及 21k 上限的情况下对转账区块定价，我们的目标是通过设计使其成为最坏情况：协议定价的每种组合所携带的字节/gas 最多应为 $\beta_t$。任何定价高于 $\beta_t$ 的区块都会在转账区块之前约束Slot，并将 $L^*$ 拉低至 422M 以下，因此我们逐一检查每种情况。

单一资源区块的字节密度是其每操作的字节占用除以 gas 成本，即 $\beta = b/c$：

• 下限 calldata 为 $1/F$
• 冷 SLOAD 为 $32/c$（32 字节 BAL 键）
• 冷账户访问（如 BALANCE）为 $20/c$（20 字节地址）
• 冷 SSTORE 为 $64/c$（BAL 中 32 字节键 + 32 字节值）

混合区块添加了最密集的廉价 calldata——即 16 gas/字节的标准费率，直到仍低于 7976 下限的部分——并用冷 SLOAD 填充剩余部分：

$$ \beta(F, c) = \frac{1 - 512/c}{F} + \frac{32}{c} $$

在 Glamsterdam 假设的价格（冷 SLOAD 3,000，冷账户访问 3,000，冷 SSTORE 13,000，calldata 下限 $F = 64$）下评估菜单，得到：

关键观察：

• 只有冷 SLOAD 能匹敌转账线。 冷 BALANCE 只将其 20 字节地址以 3,000 gas 写入 BAL（0.63×），冷 SSTORE 以 13,000 gas 写入 64 字节键值对（0.47×）——两者都舒适地低于转账线。冷 SLOAD 的 3,000 gas 支付的 32 字节存储键是状态访问每 gas 可以添加的最密集字节，这就是为什么对抗性区块由冷 SLOAD 构建。

• 冷 SLOAD 基本上就在转账线上。 在 3,000 gas 时，其 32 字节键给出 0.01067 字节/gas，比 $\beta_t$ 高 1%；在 $c = 3{,}041$ 时恰好达到线。

• 两种定价区块超过了线：纯 calldata（1.49×）和混合区块（2.25×）。 两者超出的根本原因相同——calldata 定价低于转账线——但正如我们接下来所示，它们需要不同的修复。

最小的杠杆：再次提高 calldata 下限

纯 calldata 区块超出线的原因很简单：EIP-7976 的下限为 64 gas/字节，意味着 $1/64 = 0.0156$ 字节/gas，比 $\beta_t$ 高 49%。修复方法是一个常数——将下限提高到

$$ F^* = \left\lceil 1 / \beta_t \right\rceil = \lceil 1 / 0.01052 \rceil = \lceil 95.06 \rceil = 96 \text{ gas/字节} $$

这是 Hegota 最容易的数据定价更改。然而，这仍然不能修复混合区块。 提高 $F$ 会缩小廉价 calldata 的份额（从 $16/64 = 25%$ 降至 $16/96 = 16.7%$），但冷 SLOAD 的剩余部分仍在向 BAL 添加字节，导致整体字节密度为 $\beta(96, 3000) = 0.0193$ 字节/gas。这仍然是线的 $1.84\times$。

事实上，当 $F \to \infty$ 时，字节密度趋向于 $32/c$，这本身就是 SLOAD 区块的密度。这意味着没有有限的 calldata 下限能够充分降低混合区块。

驯服混合区块的三种方法

剩余的瓶颈是混合区块，它是线的 $1.84\times$。我们有三种选择。前两种对 calldata 下限无法看到的 BAL 字节进行定价，叠加在刚刚推导出的 $64 \to 96$ 下限提升之上；第三种保持 BAL 未定价，而是移除混合区块所利用的双费率 calldata 结构。

选项 1：BAL 字节加入下限。 显而易见的解决方案是开始将 BAL 字节纳入下限计算。Toni 的这个提案将 7623 风格的下限扩展到每个有效负载字节，包括 BAL 字节。那么每个定价字节每 gas 最多产生 $1/96$ 字节，无需更改 SLOAD。代价是一个新的 gas 记账机制，该机制在每个冷访问路径上维护一个运行时下限累加器。这仅作用于下限侧，因此普通用户和 21k 转账不受影响。

选项 2：内在数据附加费。 或者，我们可以为每个对 BAL 有贡献的操作（冷访问、冷存储等）添加显式的数据组件。这仅仅是常数变化，是在下限之上的最简单机制。但以这种方式对 BAL 字节定价实际上是对状态访问的重新定价。将混合区块降至线需要大幅提高冷状态访问成本，这与冻结锚定的理由相矛盾，尽管它在执行上是安全的。此外，这进一步错误定价了纯操作码区块，它们已经低于线。

选项 3：统一的 calldata 价格，不进行 BAL 定价。 混合区块之所以有效，是因为 calldata 有两种费率——廉价的 16 gas/字节标准费率（被推至下限份额）和下限之上的费率。如果我们给 calldata 一个单一费率 $p$，这个瓶颈就会消失。每个 calldata 字节花费 $p$，因此 calldata 区块的上限为 $1/p$，将其混合到状态区块只会稀释密度。最坏情况回归到最密集的未定价状态操作，即冷 SLOAD 的 $32/c$。因此 $p$ 只需要阻止纯 calldata 超过 SLOAD：

$$ \frac{1}{p} \le \frac{32}{c} \Rightarrow p \ge \frac{c}{32} \approx 94 \text{ gas/字节} \quad (c = 3{,}000) $$

这略低于下限的 96：降低下限改变的是谁买单，而不是费率。 下限 96 只打击数据密集型交易，而统一的 94 则对每个 calldata 字节收取下限费率。这是标准费率 16 的约 6 倍提升。作为交换，它是最简单的机制（单一费率，无 BAL 记账，无 max()）。

选择在于机制复杂性和影响广度之间。选项 1 对用户的影响最小——它只影响超过 calldata 下限的区块——但它引入了新的 gas 记账机制。选项 2 和 3 都只是常数变化，但它们影响每个使用 BAL 影响操作的用户（选项 2）或每个使用 calldata 的用户（选项 3）。选项 3 比选项 2 更清晰、更合理，因为产生 BAL 字节的操作在其执行成本和带宽成本方面已经有了正确的价格。混合区块仅仅利用了 calldata 的双费率结构，因此移除该结构是直接修复，根本不需要触及 BAL 字节。

如果传播速度加快会怎样？

定价可以使不同组成的区块达到转账线，但不能低于它。超过这一点，只有传播模型本身可以移动——通过基于 mempool 的有效负载重建（大多数有效负载字节已经存在于对等节点的 mempool 中）、gossip 和拓扑改进，或纠删码分发。将中心交叉点以 $x%$ 更好的斜率重新运行：

模式大致是 每 10% 的斜率改进带来 +14–18M 的 gas 上限，截止时间随之提前；−20% 的斜率在 $D = 6.0$s 时达到 450M 的整数——在推荐的限制下恢复对称的 25% 缓冲——而 −50% 则在 $D \approx 5.3$s 时达到约 501M。将固定开销减半（569 → 285 毫秒）本身大约相当于一个斜率十分位数（约 +19M）。请注意，转账密集型负载是最难压缩的形状（签名是随机字节），因此基于压缩的改进对对抗性尾部比锚定区块本身更有帮助。

整个框架的硬上限是执行：随着 $D$ 接近 $T_1$ 加上固定开销，执行窗口饱和在约 8.2s，即在 100 Mgas/s 的 75% 下为 618M。超过这一点需要提高实际执行吞吐量，这正是关于重新定价高估计算操作的并行分析所解决的问题。该分析在本报告的一个地方有联系：更便宜的执行会将更多交易推至 calldata 下限，因此应针对重新定价后的执行成本评估 $F = 96$ 时的下限发生率。

对其他资源的影响

状态增长：重新推导 CPSB

最新的 EIP-8037 规范将 CPSB 固定为 1,530，这是在 150M 参考限制下为 120 GiB/年的目标推导得出的，并明确推迟到后续分叉重新推导。如果保持在 1,530，在 450M 限制下的目标增长率将约为 360 GiB/年。使用规范自身的推导方法在新的限制下计算，得到：

无论哪种情况，转账都不受影响，因为只有新账户创建才支付状态 gas，且位于带有 reservoir 模型的单独维度中。

还有一个问题是，实际需求将如何响应更高的区块上限和增加的 CPSB。最终值可能会有所不同，具体取决于我们观察用户如何适应 Glamsterdam 分叉。

历史：无需重新定价，但过期变得更重要

在 2024 年 5 月至 2025 年 5 月期间，在 36M 限制下，测得的 geth 历史数据（区块头、区块体和收据）以约 525 MiB/天的速度增长——大约 180 GiB/年（更多信息在此）。将其线性缩放到 450M 得到约 2.2 TiB/年。这已经包含了日志（它们位于收据中），但测量窗口早于 BAL，因此该数字省略了 BAL。BAL（EIP-7928）是第二个历史通道，大小相当——约占转账区块字节的 41%，并且在状态访问密集型组成中占主导地位——但 EIP-7928 允许将存储的 BAL 修剪为哈希根，因此它们的持久贡献取决于保留窗口。

在这些历史增长率下，滚动历史过期（EIP-4444 系列）对验证者来说变得更加重要。然而，这个增长率仍然是可管理的，因此不需要重新定价。

内存：无需操作

最坏情况下的 EVM 内存是按交易计量的：二次扩展成本加上 EIP-7825 上限将单个帧限制在约 3–4 MB，并且内存会在顺序执行的交易之间释放。更高的区块上限会增加每区块的交易数量，而不是并发内存。这只有在 7825 上限被提高或线性内存定价（EIP-7923/7686）在没有补偿限制的情况下交付时才会改变。

计算：向下重新定价

冻结 100 Mgas/s 锚定的另一面是，大多数操作相对于它现在定价过高：它们的最坏情况客户运行时间低于当前的 gas 成本，因此它们消耗的区块 gas 预算超过了它们实际花费的时间。根据当前的客户端性能结果，我们可以重新定价约 62 个 EVM 操作和预编译，其中 36 个在锚定费率下低于 1 gas。这些是廉价的、高频的算术、位、栈和内存操作。

这种高定价是未利用的吞吐量。在主网流量上，目前约有 12.4% 的区块 gas 被有效浪费 在收费高于其公平运行成本的操作上。使用整数舍入（max(⌈精确值⌉, 1)）进行向下重新定价可以将这一比例降至 约 2.6%。

10% 的收益不错，但很可能无法弥补重新定价 62 个操作的成本。因此，这里的建议是在 Hegota 中不改变计算成本。

Hegota 实际交付的内容

局限性

• 所有传播数字继承自 Toni 的 p90 MEV-boost 拟合（$569 + 0.443 \cdot \mathrm{KB}$ 毫秒，snappy 压缩后大小，在释放后测量为 $p_{90} - \min$）以及 $T_1 = 3$s 假设；两者都是选择，而非给定条件。Toni 的保守 $\sqrt{n\cdot\text{size}}$ 权重给出更陡的斜率（并且本地/更高百分位拟合更陡），每个都会将最优值拉低；交叉点每秒 $T_1$ 移动约 51M，并与斜率成比例。

• 每笔转账的字节数是基于确认的 RLP 最小长度编码推导得出的，因此框架开销已解决；但 Toni 的传播模型是基于snappy 压缩后的字节校准的，我们假设转账区块是不可压缩的（snappy 后 ≈ 原始的 221 字节）。实际的线上压缩以及 block_access_index 宽度随交易数量的增长尚未建模，并会改变每个基准数字——特别是压缩只会放宽约束并提高 $L^*$。

• 交叉点模型将传播和执行视为严格串行，并带有硬性的 25% 缓冲；流水线或重叠验证会将最优值向外推移。

• 8037 数字遵循实时规范（CPSB = 1530）；本地的 EIP 仓库仍带有旧的自动缩放草案，其数字不适用。

• 历史预测将今天测得的 30M→36M 接近线性的历史增长（区块头、区块体、收据）按 gas 上限线性缩放；但组成变化（blob 采用、实际 BAL 大小）会改变它们。

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