Hegota 中的扩展：利用ETH转账来锚定执行和带宽

Ethereum Research

本文为机器翻译

展示原文

我要感谢 Toni Wahrstaetter、Marius Vanderwijden 和 Parithosh Jayanthi，感谢他们参与讨论并最终促成了这份报告的撰写。

本文探讨了Hegota在Glamsterdam事件后需要做出哪些改变才能继续扩展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 B）的不可降低的字节密度，任何定价工具都无法低于此密度。锚定区块的传播速度约为 214 Mgas/s，因此其执行速度受限。在对称的 25% 缓冲区下解决两个上限问题，在 PTC 截止时间约为 6.4 秒时，可得到约 4.22 亿个区块。我们将 25% 的缓冲区视为指导原则，而非硬性下限，并略微放宽以取整数：我们建议在 $D = 6$s 时使用 4.5 亿个区块，这样锚定区块的执行缓冲区约为 25%，传播缓冲区约为 11%。
Hegota 的重新定价任务是将所有定价组合的容量都降至转账线。由于我们无法在不触及 21k 上限的情况下重新定价转账，因此目标是通过构建机制使其达到最坏情况。Glamsterdam 定价未能实现这一点：混合调用数据 + SLOAD块的容量约为转账线的 2.2 倍，并将系统容量限制在约 302M，比锚定最优值低约 120M。解决方案是再次提高调用数据的最低容量（64 → 96），并增加 BAL 字节的覆盖范围，或者引入单一的统一调用数据速率（约 94）——在机制复杂性和事件广度之间进行权衡。
在传输线以下，只有进一步的优化才能移动最优解。定价可以平衡传输线上的各种组合，但无法突破传输线。每 KB 的传播时间每提高 10%，gas 上限大约增加 1400 万至 1800 万，最高可达 6.18 亿。同时，ETH 转账执行时间的改进将允许更高的执行锚点，从而在不改变 PTC 截止时间的情况下提高 gas 上限。

背景

Glamsterdam 发布了 ePBS（ EIP-7732 ）、BAL（ EIP-7928 ）以及重新定价包，其中包括数据定价 EIP 7976 （调用数据最低 64/64，标准 4/16）和7981 （访问列表字节按最低费率计费）。重新定价的目标是实现最坏情况下 100 Mgas/s 的执行性能。该目标无法进一步提高：否则需要将 ETH 转账的 gas 成本重新定价到超过 21,000，这将导致某些硬件钱包的功能失效。因此，对于 Hegota 而言，100 Mgas/s 的执行性能基准被冻结，额外的扩展必须通过优化（包括执行和传播方面的优化）、调整 PTC 截止时间以及（单独地）降低过高的计算操作成本来实现。最后一个选项将并行分析，并且仅通过稍后提到的一个交互项纳入本报告。

本文所依据的假设：

范围	价值	笔记
执行锚点R R	100兆气体/秒	受21k转会上限的限制
槽端T_3 T 3	12秒
信标块认证截止日期T_1 T 1	3秒	ePBS下最早的有效载荷传播开始时间；2秒与3秒的比较仍待定。
安全缓冲区	执行窗口和传播窗口均为 25%。	指导原则，并非硬性规定；建议的 450M/6s 点运行率约为 25% / 传播率约为 11%。
传播模型	t = 569 + 0.443 \cdot \text{KB} t = 569 + 0.443 ⋅ KB ms (p90, MEV-boost)	根据 Toni 的最坏情况块大小分析；snappy 压缩后的大小，在发布后测量（ p_{90} - \min p 90 − min ）。传输块被视为不可压缩（snappy 压缩后 ≈ 原始大小）。
冷`SLOAD`	3,000	EIP-8038初步编号；Hegota 中未更改
冷账户访问（ `BALANCE` ）	3,000	EIP-8038初步编号；Hegota 中未更改
冷藏`SSTORE`	13,000	EIP-8038初步编号；Hegota 中未更改
Calldata 定价	64/64 地板，4/16 标准	EIP-7976/7981
国家创建	`CPSB = 1530` ，固定	最新EIP-8037规范（150M 参考，120 GiB/年）

资源分布图

按资源所受约束的类型对资源进行分类很有帮助，因为这决定了每种资源如何应对更高的气体限制：

资源	约束类型	更高的限额会发生什么（Glamsterdam定价）	赫戈塔行动
执行	每个槽位，在D D之后	最坏情况下的执行时间随G G 的增加而增加；与通过D D进行的传播进行权衡	（假设）不会上调价格
带宽	每个槽位，在D D之前	最坏情况下的有效载荷随G G增长；BAL 字节未定价。	分叉变更（本报告的核心）
州增长	累计（磁盘）	增长率随G增长，因为`CPSB`是固定的。	重新导出`CPSB` （分支项）
历史	累计（磁盘+服务）	随着G G 的生长	到期前提条件； `LOGDATA`审核
记忆	按事务处理（RAM）	不随G G增长（受EIP-7825限制，每次交易）	没有任何

接下来的章节将介绍每个槽位的权衡（这决定了 gas 限制），最后我们将回到累积资源。

传递块作为锚块

一次传输携带多少字节？

传输不会写入存储，也不会运行任何操作码，但它仍然会发送字节：它的信封和签名，以及 EIP-7928 在 BAL 中为其保留的记录。

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

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

设想	建造	每笔转账	\beta_t β t (字节/gas)
最坏情况会计	130个信封 + 91 BAL	221	0.01052

传播模型基于经过 snappy 压缩后的字节进行校准，因此我们将这 221 字节的原始数据映射到网络传输中，并将传输块视为不可压缩数据（经过 snappy 压缩后的数据 ≈ 原始数据）。这在最坏情况下是安全的——签名是 snappy 无法触及的随机字节——并且是该报告中最重要的假设：任何实际的压缩都只会放宽限制并提高可达的 gas 上限。测量实际编码块的压缩边缘字节斜率是该报告中指出的最重要的数据任务。

PTC截止日期应该放在哪里？

截止时间D将时隙分为传播窗口（从 $T_1 = 3$ 秒到D ）和执行窗口（从D秒到 12 秒）。在两个窗口都保持 25% 的缓冲准则的情况下，当锚区块能够及时传播和执行时，gas 限制L是可行的：

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

L ≤ 0.75 ⋅ R ⋅ ( 12 − D ) （执行）

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

0.443 ⋅ β t ⋅ L 1000 +569 ≤ 0.75 ⋅ ( D − T 1 ) ⋅ 1000 （传播）

第一个上限随着DD的移动而下降；第二个上限上升。最优解是交叉点：

设想	D^* D ∗ (s)	L^* L ∗	L^* L ∗处的有效载荷
最坏情况会计处理（221 B）	6.38	422M	4.44 MB

在两个窗口都保持 25% 指导原则的情况下，以转移为锚定的最优值约为 422M，时间约为 6.4 秒。25% 的缓冲只是一个指导原则，而非硬性规定，因此我们略微放宽它，建议采用整数操作值——450M，时间约为 6 秒，并将截止时间略微提前，以牺牲传播空间为代价来换取更高的限制。执行缓冲保持在约 25%；传播缓冲吸收了这一变化，从 25% 降至约 11%——此时锚定块使用传播窗口的约 89%，而不是 75%。

工作点	执行缓冲区	传播缓冲区
422M @ 6.38秒（对称最优）	25%	25%
450米@6秒（推荐）	约25%	约11%

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

对抗块

传输阻塞并非最糟糕的情况。

转移区块锚定了槽位，但它并非我们能够构建的最密集区块——其密度 \beta_t \approx 0.0105 β t ≈ 0.0105 B/gas 是一个下限，而非上限。由于我们无法在不触及 21k 上限的情况下对转移区块进行定价，因此我们的目标是通过构建使其达到最坏情况：协议定价的每个组合都应最多携带\beta_t β t字节/gas 。任何定价高于\beta_t β t的区块都会在转移区块之前锁定槽位，并将L^* L ∗拉低至 422M 以下，因此我们需要检查每个区块。

单资源块的字节密度是指其每次操作的字节占用量与其 gas 成本之比， \beta = b/c β = b / c :

1/F 1 / F用于楼层呼叫数据
32/c 32 / c用于冷启动SLOAD （32 字节 BAL 密钥）
20/c 20 / c用于访问冷账户，例如BALANCE （20 字节地址）
64/c 64 / c用于冷SSTORE （BAL 中的 32 字节键 + 32 字节值）

混合区块会添加尽可能密集的廉价调用数据——16 gas/字节的标准费率，直到达到仍低于 7976 的份额——其余部分则填充冷SLOAD调用：

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

β ( F , c ) = 1 − 512 / cF +32摄氏度

根据假设的 Glamsterdam 价格（冷SLOAD 3,000，冷账户访问 3,000，冷SSTORE 13,000，呼叫数据下限F = 64 F = 64 ）评估菜单，我们得到：

堵塞	建造	β β (B/气体)	× 传输线
ETH 转账（锚定）	221 B / 21,000 气体	0.01052	1.00倍
冷藏`SSTORE`	640亿/13000	0.00492	0.47×
冷`BALANCE`	20 B 地址 / 3,000	0.00667	0.63倍
冷`SLOAD`	32 B 键 / 3,000	0.01067	1.01×
楼层呼叫数据	1/F 1 / F ， F = 64 F = 64	0.01563	1.49倍
混合 25% calldata@16 + 75% `SLOAD`	β(64, 3000) β ( 64 , 3000 )	0.02363	2.25倍

主要观察结果：

只有冷SLOAD能与传输线相媲美。冷BALANCE操作仅需消耗 3,000 gas（0.63 倍）即可将其 20 字节的地址写入 BAL 库，而冷SSTORE操作则需消耗 13,000 gas（0.47 倍）即可写入一个 64 字节的键值对——两者都远低于传输线。冷SLOAD操作消耗的 3,000 gas 所支持的 32 字节存储键是状态访问操作每消耗一个 gas 所能增加的最大字节密度数据，这也是为什么攻击块都是用冷SLOAD构建的原因。
Cold SLOAD基本上位于这条线上。在 3,000 gas 时，其 32 字节密钥提供 0.01067 B/gas，比\beta_t β t高 1%；这条线恰好在c = 3{,}041 c = 3,041处达到。
有两个定价区块超过了阈值：纯看涨期权数据区块（1.49倍）和混合区块（2.25倍）。两者的超限原因相同——看涨期权数据的定价低于转移阈值——但正如我们接下来将要展示的，它们需要不同的解决方案。

最小的杠杆：重新提高呼叫数据底线

纯调用数据块超出限制的原因很简单：EIP-7976 规定的 64 gas/byte 的下限意味着1/64 = 0.0156 1 / 64 = 0.0156 B/gas，比\beta_t β t高出 49%。解决方法很简单——将下限提高到

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

F ∗ = ⌈ 1 / β t ⌉ = ⌈ 1 / 0.01052 ⌉ = ⌈ 95.06 ⌉ = 96气体/字节

这是 Hegota 最简单的数据定价调整。然而，这仍然无法解决混合区块的问题。提高F值会缩小廉价调用数据的份额（从16/64 = 25%降至16/96 = 16.7 % ），但冷SLOAD剩余部分会持续向 BAL 中添加字节，导致整体字节密度为β(96, 3000) = 0.0193 B / gas 。这仍然比基准线高出1.84倍。

事实上，当F → ∞时，字节密度趋近于32/ c ，这正是SLOAD块本身的密度。这意味着，即使设置有限的调用数据下限，也无法将混合块的密度降低到足够低的程度。

驯服混合块的三种方法

剩余的瓶颈是混合块，其价格是线路价格的 1.84 倍。我们有三种选择。前两种选择对看涨期权数据层看不到的 BAL 字节进行定价，并叠加在刚刚推导出的 64 到 96 的平台价格上涨之上；第三种选择不对 BAL 进行定价，而是移除混合块所利用的双速率看涨期权数据结构。

方案一：将 BAL 字节纳入最低收费。显而易见的解决方案是将 BAL 字节纳入最低收费计算。Toni的这项提议将 7623 式的最低收费标准扩展到每个有效载荷字节，包括 BAL 字节。这样，每个收费字节最多产生1/96字节的gas ，且完全不需要更改SLOAD 。其代价是引入一种新的 gas 计费机制，该机制会维护一个运行时最低收费累加器，并跟踪每个冷访问路径。此机制仅作用于最低收费端，因此不会影响普通用户和 21k 流量传输。

方案二：内置数据附加费。或者，我们可以为每个占用 BAL 的操作（冷访问、冷存储等）添加显式数据组件。这仅涉及常量，是目前最简单的机制。但这种 BAL 字节定价方式实际上相当于对状态访问进行重新定价。将混合块纳入定价机制需要大幅提高冷状态访问成本，这与冻结锚点的理念相悖，即使它在执行上是安全的。此外，这还会进一步导致纯操作码块定价错误，而这些块本身就已经被纳入定价机制。

方案 3：统一的 calldata 价格，不采用 BAL 定价。混合区块之所以有效，是因为 calldata 有两种价格——低廉的 16 gas/byte 标准价格（最高可达最低份额）和高于该价格的最低价格。如果我们给 calldata 单一的价格p ，那么这个瓶颈就消失了。每个 calldata 字节的成本为p ，因此 calldata 区块的上限为1/p ，将其混合到状态区块中只会降低密度。最坏的情况会退化到密度最高的未定价状态操作，即成本为32/ c的冷SLOAD 。因此p只需要阻止纯 calldata 的价格超过SLOAD即可。

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

1便士≤ 32摄氏度⇒ p ≥ c 32 ≈ 94 gas/字节（ c = 3,000 ）

这比最低费率 96 略低：降低最低费率只会改变谁付费，而不会改变费率本身。96的最低费率只会对数据量大的交易收取费用，而统一的 94 则对每个调用数据字节都收取最低费率。这比 16 的标准费率高出约 6 倍。作为交换，它是最简单的机制（单一费率，无需 BAL 计费，无需max() ）。

选择在于机制复杂性和影响范围。方案 1 对用户的影响最小——它只影响超过调用数据最低限额的区块——但它引入了一种新的 gas 计费机制。方案 2 和方案 3 都只是对常量进行更改，但它们会影响所有执行影响 BAL 的操作的用户（方案 2）或所有调用数据的用户（方案 3）。方案 3 比方案 2 更简洁、更合理，因为产生 BAL 字节的操作已经包含了执行成本和带宽成本的正确价格。混合区块仅利用了调用数据的双速率结构，因此移除它可以直接解决问题，完全不需要修改 BAL 字节。

如果传播速度加快呢？

定价机制可以平衡传输线上的成分，但不能低于传输线。超过这个点，只有传播模型本身可以改进，例如基于内存池的有效载荷重构（大多数有效载荷字节已经存在于对等节点的内存池中）、Gossip 协议和拓扑结构的改进，或者纠删码分发。重新运行中心交叉算法，斜率提高x % ：

边坡改善	D^* D ∗ (s)	L^* L ∗
— (0.443 毫秒/KB)	6.38	422M
-10%	6.19	436M
-20%	6.00	4.5亿
-30%	5.79	4.66亿
-40%	5.56	4.83亿
-50%	5.32	5.01亿
开销减半（569 毫秒 → 285 毫秒）	6.12	4.41亿

大致而言，斜率每提高 10%，gas 限制就会增加 14-18M ，同时截止时间会提前；-20% 的斜率在 $D = 6.0$s 时达到约 450M，从而恢复到推荐限制的 25% 对称缓冲区；-50% 的斜率在 $D \approx 5.3$s 时达到约 501M。固定开销减半（569 → 285 ms）本身就相当于斜率降低一个十分位（约 +19M）。需要注意的是，传输量大的有效载荷压缩性最差（签名是随机字节），因此基于压缩的改进对攻击尾部的帮助大于对锚块本身的帮助。

整个框架的硬性限制在于执行效率：当D接近T_1加上固定开销时，执行窗口会在约 8.2 秒处饱和，即在 100 Mgas/s 的 75% 下达到618M 。要突破这个限制，就需要提高实际执行吞吐量，而这正是针对高价计算操作重新定价的并行分析所要解决的问题。这项工作与本报告在一点上存在关联：更便宜的执行成本会将更多事务推到调用数据层，因此在F = 96时，调用数据层的发生率应该根据重新定价后的执行成本进行评估。

对其他资源的影响

州增长：重新推导`CPSB`

最新的 EIP-8037 规范修正了CPSB = 1530 ，该值是在 1.5 亿的参考上限下，针对 120 GiB/年的目标值推导出来的，并明确将重新推导推迟到后续分支。如果 CPSB 仍为 1530，则在 4.5 亿的上限下，目标增长率约为 360 GiB/年。使用该规范在新上限下的推导结果，我们得到：

工作点	`CPSB`	新插槽（64 B）	新账户（120 B）	24 KiB 部署
4.5亿	约4600	294k	551k	113M 状态气体
501M（p2p拉伸）	约5110	327k	613k	126M 状态气体

无论如何，转账都不会受到影响，因为只有创建新账户才会支付状态气，这是在具有储层模型的独立维度中发生的。

此外，实际需求将如何响应更高的区块限制和增加的CPSB也是一个问题。最终结果可能会因用户对 Glamsterdam 分叉的适应情况而有所不同。

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

在 2024 年 5 月至 2025 年 5 月期间，以 36M 的容量限制，测得的 geth 历史记录（包括头部、主体和收据）每天增长约 525 MiB，每年约 180 GiB （更多信息请点击此处）。如果按线性比例扩展到 450M，则增长速度约为每年 2.2 TiB 。这已经包含了存储在收据中的日志，但由于测量窗口早于 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 成本，因此它们消耗的 Gas 预算比实际运行时间更多。根据当前的客户端性能测试结果，我们可以重新定价约 62 项 EVM 操作和预编译操作，其中 36 项操作的 Gas 成本将低于锚点价格下的 1。这些操作包括低成本、高频的算术运算、位运算、栈操作和内存操作。

这种过高的定价造成了吞吐量的浪费。在主网流量中，目前约有 12.4% 的区块 gas 被浪费在了收费高于其合理运行成本的操作上。如果采用整数舍入法（ max(⌈exact⌉, 1) ）重新定价，可以将这一比例降低至约 2.6% 。

10% 的收益固然不错，但很可能不足以弥补重新定价 62 项操作的成本。因此，建议 Hegota 中的计算成本保持不变。

Hegota 实际发货的商品

#	物品	类型
1	Gas limit → ~450M, $D = 6$s	验证器协调，门控于 2–5
2	Calldata 楼层 64 → 96	一个常数（7976/7981）
3	混合块定价：BAL 最低对、内在附加费或统一看涨期权数据价格（~94）	单一开放机制决策
4	`CPSB`重新推导：1,530 → ~4,600（p2p 拉伸时约为 5,110）	根据 8037 规范流程，有一个恒定不变的因素。
5	p2p 坡度/架空线路改进	非岔路轨道：每增加 10% 的坡度，轨道高度增加 14–18 米，最高可达约 501 米。

局限性

所有传播数均继承了 Toni 的p90 MEV 增强拟合（ 569 + 0.443 \cdot \text{KB} 569 + 0.443 ⋅ KB ms，快速压缩后的大小，在发布后测量为p_{90} - \min p 90 − min ）和 T_1 = 3$s 的假设；两者都是选择，而非既定条件。Toni 的保守加权\sqrt{n\cdot\text{size}} √ n ⋅ size会产生更陡峭的斜率（局部/高百分位拟合的斜率更陡峭），两者都会拉低最优值；交叉点每秒移动约 51M，并且与斜率成正比。
每次传输的字节数是根据已确认的 RLP 最小长度编码得出的，因此帧开销已得到解决；但 Toni 的传播模型是基于快照后的字节进行校准的，并且我们假设传输块是不可压缩的（快照后 ≈ 原始 221 B）。实际的网络压缩以及block_access_index宽度随交易数量的增长仍然没有建模，并且会影响每个主要数值——特别是压缩只会放宽界限并提高L^* L ∗ 。
交叉模型将传播和执行严格视为串行，并设置了 25% 的硬缓冲区；流水线化或重叠验证会将最优解向外移动。
8037 个数字遵循实时规范（ CPSB = 1530 ）；本地 EIPs 存储库仍然保留着较旧的自动伸缩草案，其中的数字不适用。
历史预测将今天测量的历史增长（标题、主体、收据）与气体限制线性缩放；观察到的 30M→36M 缩放接近线性，但成分变化（blob 采用、实际 BAL 大小）将使其移动。