EIP-7999 中 EVM gas 记账的设计——执行层研究

引言

多维费用市场能够对资源消耗进行精细控制。它允许市场根据开发者认为安全的目标和上限，对资源进行合理定价，并让资源在这些上限内以最大容量被消耗。EIP-8037 引入了状态创建作为一种单独计量的资源。其资源定价设计刻意保持简单，以免延误 Glamsterdam，但缺少独立的基础费可能会导致多种故障模式。为缓解这一问题，有必要在未来让状态成为一种完全独立的资源，拥有自己的基础费，从而更精确地控制状态和执行 Gas，而不是像现有设计那样把两者耦合定价。

EIP-7999 为统一的多维费用市场提供了一个通用框架，其中包含单一的聚合 max_fee。一个开放的包含拟议修改的 PR 探讨了将状态和数据作为单独计价的资源加入其中。数据资源涵盖交易内容字节和区块访问列表（BAL）字节。本文比较了四种设计范式，探讨如何协调独立资源价格与交易上限、GAS 以及传统调用的标量 Gas 参数。

核心难点在于，多维定价天然地让每种资源拥有自己的计量器和基础费，而 EVM 目前只对外暴露一个标量 Gas 预算。我们可以通过几种不同的方式来保留这一标量接口，或者决定新合约应直接与资源维度交互。每种选择都会把复杂性转移到协议的不同部分。

设计范式概览

后续章节将详细阐述四种范式，分别是：

• 聚合 EVM Gas： EVM 继续对执行、状态和数据使用一个共享的 Gas 计量器。协议会分别记录各资源消耗的 Gas，并让每种资源拥有自己的基础费、目标和区块核算。这与当今的标量 EVM 最为接近，但交易必须按共享 Gas 全部花在最昂贵资源上的方式来准备资金。
• 多维子费用市场： 交易为普通 Gas、状态字节和数据字节分别设置上限，但 EVM 仍运行在单个标量 Gas 计量器上。区块开始时，相对基础费会被转换为状态和数据操作的固定标量 Gas 成本。这样既避免了聚合 EVM Gas 所需的保守资金检查，也允许合约像今天一样继续使用 GAS 和 CALL(g)。不过，为状态或数据预留 Gas 的合约需要先行读取当前转换率。
• 通用溢出： 交易为每种资源设置一个专用上限，并额外设置一个标量溢出额度；任何 EVM 资源在其自身上限耗尽后，都可以消耗该溢出额度。传统 CALL(g) 控制转发的溢出额度数量，而专用上限则单独转发。这样既保留了标量的调用后储备，又不让整个 EVM 额度变得可互换。
• 采用更新 EVM 的多维费用市场： 独立的资源预算在 EVM 内部保持可见。新的调用可以直接转发或预留执行、状态和数据容量，新的内省（introspection）机制可以报告剩余的资源向量。传统合约将获得一个尽力而为的兼容规则，并可能辅以通用溢出。

这些方案各自以不同方式保留了当前的标量 EVM。聚合 EVM Gas 保留了现有的 Gas 调度和共享计量器，但在资金检查上为这种简单性付出了代价。子费用市场则允许状态和数据操作的 Gas 成本浮动，从而保留标量调用，将复杂性转移到了操作码定价，以及那些为特定工作预留容量的合约身上。通用溢出保留了可供调用方保留的标量缓冲，但削弱了 GAS 作为总剩余容量度量的作用，也削弱了在不将更多容量置于最高价格资金检查前提下限制被调用方的能力。更新后的 EVM 让新合约能直接控制每种资源，但需要更大的兼容性和工具链迁移成本。

关于 EIP-8037 储备池的说明

在下文几种范式中，会涉及 EIP-8037 的 Gas 储备池。这里先向不熟悉的读者做个介绍。EIP-7825 将交易声明的 Gas 上限设为 $2^{24}$。EIP-8037 则只将这一上限应用于执行 Gas，并允许额外的状态 Gas，同时把交易扣除内在 Gas 后的剩余部分划分为两个池：

gas_left             = 普通执行可用的 Gas
state_gas_reservoir  = 仅可用于状态创建的额外 Gas

执行操作只消耗 gas_left。状态 Gas 费用首先消耗储备池，然后回退到 gas_left。GAS 操作码只报告 gas_left，因此交易仍可能拥有 GAS 看不到的状态容量。

因此，储备池在提供额外状态容量的同时，也保留了每笔交易的执行 Gas 上限。这是一个针对更普遍问题的状态专用解决方案：如果交易再获得额外的 BAL 数据容量，这部分容量绝不能变成可执行 Gas。聚合 EVM Gas 和子费用市场可以通过受保护的资源专属池，或通过显式计数器独立强制执行执行 Gas 上限来解决这个问题。通用溢出和更新的 EVM 则分别跟踪执行用量，可以直接对执行用量应用 EIP-7825。

聚合 EVM Gas

设计

聚合 EVM Gas 为非确定性 EVM 执行保留了一个标量 Gas 计量器。执行、状态创建和 BAL 数据费用在固定 Gas 调度下消耗共享的 Gas 预算。与此同时，协议会分别记录执行 Gas、状态 Gas 和数据 Gas 的消耗量，使每种资源都能有自己的基础费、目标和区块核算。

共享标量计量器控制执行，而实际实现的资源向量决定费用。如果一笔交易消耗了 $g_e$ 执行 Gas、$g_s$ 状态 Gas 和 $g_d$ 数据 Gas，其基础费支付为

$$b_e,g_e + b_s,g_s + b_d,g_d.$$

难点在于，协议事先并不知道聚合的 EVM Gas 会被哪种资源消耗。若用 $G_a$ 表示这种可以在执行、状态或数据 Gas 之间互换的聚合 Gas，那么严格的资金检查必须覆盖

$$\max(b_e,b_s,b_d) , G_a.$$

确定性的资源组件则可以按各自适用的基础费单独提供资金。同样的不确定性也影响执行前的区块容量检查：共享上限必须针对其可能消耗的每一个硬限制区块维度做保守计算。一种更宽松的变体允许发送方放弃完整资金保证。此时，以 ETH 计价的 fee_left 计量器会随资源消耗递减；一旦已提供资金的额度耗尽，执行即停止。这能降低前置资金要求，但会引入新的用户失败条件，也需要为传播和结算制定更细致的规则。

EIP-7999 中讨论的其他变体，则是把执行后的资金风险转移给区块生产者，使费用充足性问题在执行前（例如在内存池中）得不到解决。因此，探索能让聚合 EVM Gas 与可接受的资金检查兼容的方案仍是有价值的。

优点

聚合 EVM Gas 保留了现有交易格式，对当前 EVM 接口的改动也最小。EVM 工作仍使用标量 Gas 上限，传统 GAS 和 CALL(g) 继续运行在熟悉的共享计量器上。现有合约无需在调用前读取不断变化的状态 Gas 或数据 Gas 转换率。

操作码 Gas 成本也保持稳定。单独的基础费会改变交易为每种资源支付的费用，但不会改变操作消耗的标量 Gas 数量。EIP-8037 储备池提供了一种直接方式，可以在允许更大状态创建交易的同时保留 EIP-7825 执行上限。因此，当最小化 EVM 改动是主要目标、且预计不会出现较大基础费分化时，聚合 EVM Gas 是一种可行的过渡设计。

缺点

保守的资金检查是主要缺点。一笔交易即使几乎不使用某种资源，也可能需要托管足够的 ETH，以最高 EVM 基础费覆盖整个可互换共享上限。随着基础费分化，一些按实际资源组合本可负担的交易，可能在前置余额检查中失败，或需要大得多的临时余额。Blob 基础费有时会与执行基础费显著分化，EVM 基础费也可能出现一定程度的分化。EIP-7918 中部署的保留价格机制虽然能维持可行的资金检查，但会把资源价格耦合在一起。

储备池还削弱了 GAS 的含义。子调用可以消耗整个交易范围的储备池中的状态容量，而该容量并不包含在 gas_left 中，因此不会反映在 GAS 里，也不完全受标量调用参数控制。EIP-8037 已指出，通过 gasleft() 差值来归因子调用 Gas 用量的系统，无法看到由储备池提供资金的状态 Gas。在采用独立基础费的情况下，标量差值同样无法揭示子调用的费用相关资源组合，这会影响到任何使用 Gas 差值做内部费用归因的合约。如果未来资源也获得类似的受保护容量，交易中可能完成的工作就会有更大份额落在传统合约所观察到的标量值之外。

该设计难以优雅地扩展到大量独立定价的运行时资源。每增加一种资源，某个基础费远高于其他基础费的可能性就会增大，资金检查也随之恶化。同时，可能还需要额外的特殊回退规则来保留资源特定的交易上限。构建者因此必须考虑更广泛的区块打包组合，而保守的执行前检查仍可能排除一些实际资源使用本可容纳的交易集合。

多维子费用市场

设计

EIP-8075 中提出的多维子费用市场，可以通过为状态和数据分配浮动的 Gas 价格来保留标量 EVM。执行、状态和数据各自保留独立基础费，而 EVM 内部使用的标量 Gas 成本则由这些基础费的比率推导得出。

交易为普通 Gas、状态字节和数据字节分别设置上限。每个区块开始时，协议会计算状态字节和数据字节的有效标量 Gas 成本，并在该区块的每一笔交易和子调用中保持不变。以执行基础费作为标量 EVM 基础费，令 $c_s$ 为每字节的基准状态 Gas，则每字节的有效状态成本（在不考虑整数表示的情况下）可以写为

$$C_s = c_s \frac{b_s}{b_e},$$

其中 $b_e$ 是执行基础费，$b_s$ 是状态基础费。因此，创建 $x$ 字节的操作，其状态组件会消耗 $xC_s$ 标量 Gas。按 $b_e$ 收取这笔标量 Gas 所产生的费用，与按 $b_s$ 收取基准状态 Gas 完全相同。

同样的转换也适用于数据资源。交易内容字节和 BAL 字节都以数据基础费结算，只是交易内容的使用量在执行前已经确定。若给定上限分别为 $L_e$ 普通 Gas、$L_s$ 状态字节和 $L_d$ 数据字节，协议则计算

$$G = L_e + C_s L_s + C_d L_d.$$

执行可以只针对 $G$ 进行，因此资源上限不会单独生效。此时，需要显式的执行 Gas 计数器来强制执行 EIP-7825，确保转换后的状态或数据容量不会变成额外的执行容量。也可以出于更精确控制的考虑，单独强制执行这些上限，并采用通用溢出和完整多维费用市场所共同需要的按资源跟踪方式。第二种方案还允许为 BAL 数据制定专门的抗审查策略，具体内容将在另一篇研究文章中描述。

使用 Gas 参数为后续状态或数据工作预留容量的合约，必须读取当前区块的确切有效成本，然后才能计算所需标量数量，并像今天一样使用 GAS 和 CALL(g)。不过，那些硬编码了 Gas 假设的现有合约仍可能失效。转换率在整个区块内固定，因此交易过程中或调用帧之间不会再作调整。

优点

子费用市场在保留单个标量 EVM 计量器的同时，消除了最高价格资金问题。一旦状态和数据额度转换为执行等价 Gas，共享计量器的每个单位便具有相同的基础费价值。因此，在构造标量上限时，各独立上限可以按各自的基础费定价。

GAS 和 CALL(g) 接口仍保持标量。合约只需读取当前有效的状态或数据成本，就能计算出为指定工作量预留或转发多少 Gas，而无需修改调用签名，也无需把资源向量引入每个调用帧。

交易格式还避免了从提交到包含之间因转换率漂移带来的问题：标量额度会根据提供的上限、按包含区块的费率重新计算，尽管统一的 max_fee 仍须覆盖这些费率。转换完成后，执行使用一套固定 Gas 调度和一个标量上限。

该设计保留了独立的资源目标和基础费，因此无需引入多维调用，也能保持对区块级资源使用的独立控制。

缺点

主要缺点在于操作码价格会波动。状态和数据操作所收取的标量 Gas，会随着其基础费相对执行基础费的变化而变动。依赖硬编码补贴、精确 gasleft() 阈值，或对状态/数据工作成本有固定假设的合约，通常需要先改为读取当前费率，才能预留正确的 Gas 量。协议因此必须暴露共识所使用的确切有效费率，并定义精确的定点表示和舍入规则。

如果转换后的标量容量可以互换，构建者仍须将其保守地映射到任何具有硬区块限制的原始资源维度。gas_left 之外的任何受保护资源专用容量，同样会削弱 GAS 的含义。

通用溢出

设计

通用溢出 为交易的每种 EVM 资源各提供一个单独上限，并额外提供一个标量溢出上限。操作会先消耗自己的专用资源预算；若该预算耗尽，则可以转而消耗通用溢出。

传统 CALL(g) 会完整转发剩余的专用预算，而通用溢出的转发量按现有标量调用规则执行。相应地，传统 GAS 操作码报告的是剩余通用溢出。这样，调用方可以在子调用后保留一个可互换缓冲，用于清理、核算或其他工作，而交易的大部分仍由单独的资源上限提供资金。

设 $L_i$ 为资源 $i$ 的专用上限，$b_i$ 为其基础费，$O$ 为通用溢出，$b_{\max}$ 为最高的相关 EVM 基础费，则基础费资金检查为

$$\text{所需基础费覆盖}=\sum_i b_i,L_i+b_{\max},O.$$

只有溢出部分必须按最高基础费提供资金，专用上限则按各自价格提供资金。

相当大一类交易可以将溢出设为零，包括简单转账，以及那些执行既不依赖 GAS、也不要求在传统调用后保留有保证标量储备的交易。通用溢出主要是为兼容传统 CALL(g) 而设的机制，同时也作为资源使用不确定交易的回退方案。至于现有交易中有多少需要它，或出于其他目的依赖 GAS，应当通过实证来测量。

默认情况下，CALL(g) 会转发全部剩余专用资源容量，而通用溢出只按 g 转发。另一种替代方案是新增一个严格上限的调用操作码：它保留所有专用预算，只转发 g 所对应的溢出部分。这样，调用方可以限制一个较小型的子调用，同时把大部分容量保留在单独定价的专用预算中，从而避免产生大额的最高价格资金需求。

与 EIP-7825 的交互是直接的，因为执行 Gas 会在整个 EVM 中被显式跟踪。客户端因此会统计所有消耗的执行 Gas（包括来自通用溢出的部分），并防止交易超过上限。

在区块层面，客户端仍会跟踪每种资源的实际消耗。由于通用溢出可能全部花费在任何符合条件的资源上，保守的执行前检查必须在每个符合条件的硬限制维度中预留相应余量。

优点

通用溢出保留了传统标量调用参数最主要的“保留 Gas”用例：调用方可以预留一定数量的可互换 Gas 用于调用后工作，而无需让整个交易都使用聚合 EVM Gas。

交易大部分可以按各资源的实际基础费提供资金，只有显式选择的溢出部分按最高基础费定价。当兼容缓冲相对专用上限较小时，前置资金要求远低于聚合 EVM Gas。

Gas 调度保持稳定。状态创建和数据操作在各自维度内保持固定成本，需求变化影响的是基础费，而不是 EVM 内部消耗的 Gas 量。

该机制也能自然地扩展到更多资源。每种新资源都有自己的专用上限和基础费，而同一个溢出机制可以在确实需要可互换性时提供标量回退。

缺点

传统 CALL(g) 不再必然对被调用方形成完整上限。标量参数限制的是被转发的通用溢出，而专用资源预算会被单独转发。因此，即使调用方给出的 g 很小，被调用方仍可能消耗大量专用的执行、状态或数据容量。对于那些刻意使用 Gas 补贴来隔离或限制不受信任被调用方的合约，这是一个现实中的兼容性问题。

但这并非绝对。交易发送方可以把大部分相关容量放入通用溢出，使 CALL(g) 重新能够限制被调用方的大部分工作，但这也会重现聚合 EVM Gas 中相当一部分最高价格资金需求。因此，通用溢出呈现出一个连续谱：专用容量越多，资金效率越高；溢出越多，越接近保留历史标量上限。同样的权衡也适用于保守的区块容量预留。如前所述，也可以增加一个严格的调用操作码，专门在这种用法下只转发通用溢出。

GAS 操作码只报告通用溢出，而非完整的剩余资源向量。对于仅用它来管理传统调用所控制的标量储备的合约，这已经足够；但真正需要知道剩余执行、状态或数据容量的合约，则需要新的多维内省机制。

采用更新 EVM 的多维费用市场

设计

采用更新 EVM 的多维费用市场 会在每个 EVM 调用帧内保持资源预算分离。例如，一个帧会分别携带执行、状态和数据的剩余预算；当所需资源预算耗尽时，操作失败。

新调用将直接基于这个向量操作。调用方可以指定要转发的资源向量，也可以等价地指定调用后必须保留在调用方的向量。确切的操作码接口仍是开放的，但新合约不再需要把多个资源预算压缩到一个标量 Gas 参数中。另一个可选方向是遵循 EOF 新调用指令的思路：移除新合约对 Gas 的可观测性，让调用自动按协议定义的份额转发每种剩余资源。

传统合约仍需要某种尽力而为的兼容规则。EIP-7999 中提出的一个选项，是根据剩余资源向量计算聚合标量值：传统 GAS 返回该聚合值，传统 CALL(g) 则按相同比例转发每种剩余资源预算。这保留了对旧标量参数的近似比例解释，但无法保留每个精确的 Gas 阈值或带 Gas 上限的子调用。

更新后的 EVM 也可以与通用溢出或溢出向量结合使用：新合约可以使用精确的多维调用，传统调用则控制一个较窄的兼容预算。

资金要求也很直接：若交易为每种资源指定上限 $L_i$，基础费为 $b_i$，则基础费要求为

$$\text{所需基础费覆盖}=\sum_i b_i,L_i.$$

无需按最高基础费为任何共享预算提供资金，也没有市场价格比率被嵌入操作码的 Gas 成本中。

优点

这是最清晰、最有长期价值的资源模型。交易上限、区块上限、费用控制器、调用帧预算和内省都可以使用同一套资源维度。新的调用方既能独立限制不受信任被调用方的执行、状态创建和数据产出，又能为后续工作保留精确的资源向量。

资源成本在各自单位内保持稳定。基础费变化影响的是支付金额，不会改变给定额度能购买多少状态或数据。资金要求精确；增加一种稀缺资源只是扩展现有向量，而不是再引入一种标量转换或受保护池。

该设计还让权衡更加显式：新合约获得精确的多维语义，而针对传统合约的兼容机制可以被隔离，不必永久地塑造整个 EVM。

缺点

迁移成本相当大。EVM 和执行客户端需要新的调用与内省语义；合约语言和编译器需要能够表达新的资源预算；Gas 估算、交易模拟和追踪器也需要暴露不止一个运行时计量器。此外，依赖 gasleft() 差值进行工作量归因的基础设施（包括一些捆绑和账户抽象系统）可能也要修订核算方式。

没有任何标量兼容规则能保留传统 GAS 和 CALL(g) 的全部用法。比例转发可以保留近似行为，通用溢出可以保留标量调用后缓冲，但依赖精确补贴、精确阈值或严格标量上限的合约，其行为仍可能发生变化。因此，传统代码与更新代码之间的相互调用需要制定细致的边界规则。

设计范式比较

定性评分表

下表给出粗略的定性评估：++ 表示显著优势，+ 表示中等优势，0 表示结果混合或取决于具体设计，- 表示缺点，-- 表示重大缺点。评分旨在揭示权衡，而不是选出赢家；例如，任何 -- 都可能使设计不可行。

属性	聚合 EVM Gas	多维子费用市场	通用溢出	更新的 EVM
资金效率	--	++	+	++
被调用方上限兼容性	+	+	0	0
传统标量调用后储备	++	++	++	-
传统 GAS 准确性	+	+	--	0
操作码成本稳定性	++	--	++	++
部署便捷性	++	+	+	--
可扩展性	--	+	+	++

“被调用方上限”一行反映的是各范式内部可用的整体兼容性，包括通用溢出下可能新增的严格上限调用，而非仅指传统 CALL(g) 的默认行为。

交易格式

在聚合 EVM Gas 下，单一上限使交易格式变化最小化，但协议也因此无法在执行前区分交易的最坏情况资源组合，这正是保守资金和区块容量检查的来源。

子费用市场使用相互独立的普通 Gas、状态字节和数据字节上限，并在包含时计算单个标量 Gas 上限。这些独立字段可以保护用户免受转换率漂移的影响；如果资源上限被额外强制执行，也会约束相应的运行时使用。

通用溢出和更新的 EVM 同样采用按资源设置上限。通用溢出增加了一个任何 EVM 资源都可消耗的标量兼容缓冲；更新的 EVM 则在整个执行过程中保持上限分离，并允许新调用直接转发或预留这些资源。

状态和数据上限也许更适合以字节为单位来考量。如果协议日后更改固定的每字节 Gas 系数，以字节计价的上限仍然稳定；协议只需在执行前应用相应系数。这种计价选择在多个范式中都有用，并且独立于 EVM 调用语义的选择。

传统交易类型只暴露一个 EVM Gas 上限。确定性的交易内容用量可以在执行前核算，难点在于如何把剩余额度分配到执行、状态创建和 BAL 数据等多个运行时资源。

在聚合 EVM Gas 下，标量上限保留当前含义，即一个共享运行时上限。在子费用市场下，它同样可以作为包含区块转换 Gas 调度下的标量运行时上限。然而，由于发送方不会指定单独的状态和数据字节额度，转换率的变化会改变签名上限内能容纳多少状态或 BAL 工作。这一点支持在子费用市场下，为这些资源采用变动较慢的 Gas 价格。

通用溢出和更新的 EVM 则使用独立的运行时预算。传统交易可以通过聚合 EVM Gas 回退来处理：在通用溢出下，这等价于把整个 EVM 额度放入可互换溢出，从而保留标量行为，但会重新引入最高价格资金和保守区块容量检查；更新的 EVM 则可以使用这种通用溢出回退，或使用前面提到的标量到向量映射。

统一的标量 max_fee 仍然与所有四种范式兼容。变化的只是这笔 ETH 预算所对应的资源上限，以及为检查该预算而假定的资源使用情形。

Gas 可观测性与调用功能

这里有三个相互关联但又彼此不同的兼容目标：

1. 保留调用方在子调用后为工作预留容量的能力；
2. 保留对被调用方所做工作施加硬性上限的能力；
3. 保留 GAS 作为全部剩余 EVM 容量的标量度量。

目前，一个标量计量器在很大程度上同时服务于这三个目标，而四种设计各自保留了不同的子集。

聚合 EVM Gas 和子费用市场都保留了 gas_left 中那种熟悉的标量关系：从该容量中扣除的费用走同一个标量计量器，传统 CALL(g) 则控制其中多少被转发。

如果有受保护容量位于 gas_left 之外，两种设计会出现相同的例外：该容量既不包含在 GAS 中，也不完全受标量调用参数限制。如果子费用市场在执行期间另行强制执行资源上限，这些上限同样构成了 GAS 无法表达的约束。使用子费用市场、并希望为特定数量的状态或数据预留 Gas 的合约，还必须读取当前有效成本。

通用溢出主要围绕第一个目标设计。传统调用方可以保留标量溢出缓冲，但同样的标量参数不能限制被调用方的预算，GAS 也不会报告完整资源向量。交易可以通过把更多容量放入溢出来恢复上限，但代价是放弃这部分资金优势。

但这并不能为把 CALL(g) 视为安全边界的传统合约恢复保证，因为合约无法要求发送方按这种方式分配容量。新的或更新的合约，将需要上文讨论的严格上限调用操作码。当溢出为零时，GAS 会报告为零，尽管仍剩余专用容量；因此，仅以 gasleft() 作为运行时保护的合约也可能失效。

更新后的 EVM 与传统合约的兼容性最低，但它为新合约提供了经过优化的多维等价能力。在这些新接口下，调用可以预留或限制资源向量，内省也能精确报告该向量。这一方向有可能与来自其他范式的传统合约功能（例如通用溢出）相结合。

资金检查与区块打包

资金要求的差别可以总结如下：

• 聚合 EVM Gas 以最高 EVM 基础费为可互换的共享额度提供资金，除非协议接受某种形式的执行后资金风险。
• 子费用市场将提供的资源上限转换为标量 Gas，使标量资金检查在经济上等价于对各上限分别定价。
• 通用溢出按各自基础费为专用上限提供资金，只有溢出部分按最高 EVM 基础费定价。
• 更新后的 EVM 直接按各资源上限的基础费分别提供资金。

就区块打包而言，更新后的 EVM 为构建者提供了清晰的最坏情况资源向量；通用溢出对专用预算也是如此，但其溢出部分仍须进行保守估计。在聚合 EVM Gas 下，可互换的共享上限必须被保守地映射到它可能变为的每一个受限资源；未单独强制执行资源上限的子费用市场也存在同样问题。

待解决的问题

1. 哪些传统 Gas 属性最值得保留？ 我们可以尝试区分“调用后预留”、“被调用方上限”和“标量内省”三种用途，并衡量已部署合约分别对它们的依赖程度。因此，一个有价值的实证问题不仅在于合约是否调用 GAS，还在于它们拿 GAS 来做什么。

2. 实践中需要多少通用溢出？ 许多交易可以使用零溢出；但读取 GAS 的传统合约中能观察到哪些使用模式？开发人员又表示会将通用溢出用于什么？

3. 聚合 EVM Gas 能否充分放宽资金检查？ 可选的 fee_left 计量器、执行后的区块有效性规则或区块生产者保证，都能降低前置要求，但每一条路径都会转移风险，并改变失败或包含语义。

4. 资源分离后，EIP-7825 应如何应用？ 若推进这一路径，最好在按资源单独跟踪的前提下实现 EIP-7825，并验证预期功能可以顺畅达成。

5. 更新调用的最佳迁移路径是什么？ 可能的方案包括：传统比例转发、通用溢出、溢出向量、具备精确多维调用的版本化代码，以及这些方案的组合。

• 原文链接： ethresear.ch/t/designs-f...
• 鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～