以太坊推迟Hoodi测试网Glamsterdam升级，审查合约风险

10月26日的Hoodi测试已被取消，包括其原计划的2亿gas上限。开发者正在针对已部署在主网上的合约审查一项重新定价提案。

以太坊已取消原定于下周一进行的测试。以太坊基金会10月22日的通知称，Glamsterdam将不会于10月26日UTC 17:42:48在Hoodi上激活，且尚未设定新的epoch。随之而来的gas上限提升至2亿的安排也已从测试网日程中移除。这是对未来配置的推迟，而非对Hoodi已记录区块的逆转。

开发者做出这一决定，是为了调查EIP-8037——一项改变创建新以太坊状态价格的变更——如何与主网上的合约交互。基金会并未表示该升级已破坏主网。它也没有为生产分叉设定日期。眼前的运营风险在于Hoodi：仍带有旧激活时间的客户端或自定义配置可能与修订后的日程不一致。更深层的问题是，如何在不扰乱那些将旧数值嵌入代码的应用程序的情况下，改变交易内部工作的成本。

Hoodi的10月26日分叉已从日程中移除

10月16日的Hoodi公告指定了epoch 132,352和slot 4,235,264。它将执行层的Amsterdam变更与共识层的Gloas变更以及2亿gas上限配对。新通知完全取代了那些指示。运营者应阅读两类客户端的最新发布说明；一个被描述为兼容Glamsterdam的较早版本可能仍包含现已取消的Hoodi激活。

这不仅仅是一个日程脚注。验证者需要遵循与其对等节点相同的网络规则。如果其部分软件期望在旧epoch执行新的执行规则或共识职责，而网络并不如此，它就可能失去跟随规范链的能力。构建者和验证者基础设施可能有自己的配置。因此，基金会告知运营者在10月26日之前核实修订后的客户端版本并移除过时的自定义设置，而不是因为分叉被推迟就认为什么都不做是安全的。

Sepolia已于10月6日激活Glamsterdam并测试了2亿gas上限，正如对该次激活的报道所记录的那样。一个测试网的成功激活是有用的，但对另一个测试网并不具有决定性。Hoodi剩余的演练之所以被推迟，正是因为合约调查需要时间。目前没有已公布的替代时间戳可供推断出主网日期。

Glamsterdam 已于10月6日在Sepolia上激活，开发者在那里测试了2亿gas上限。成功的测试并不能解决EIP-8037将如何影响已在主网上运行的合约的问题。Hoodi的演练在开发者调查这些交互期间被推迟，且尚未宣布替代日期。

今年该时间表已不止一次发生变化。9月关于Sepolia计划的报道描述了在公开测试进行之前的开发网问题和EIP-8037实现问题。这些早先的问题并不能证明与10月22日合约问询是同一原因。它们说明了为什么随着客户端团队从私有试验转向公共网络，这些日期一直是有条件的。关于测试网上构建者行为的另一项担忧涉及Glamsterdam的另一部分，不应与重新定价混为一谈。最新通知给出了Hoodi暂停的一个具体原因：进一步调查EIP-8037与主网合约的交互。

为什么该提案中创建状态的费用更高

一笔交易可以执行计算，也可以留下网络必须保留并稍后访问的数据。创建新账户、打开新的存储槽或部署合约字节码都会增加这种持久状态。EIP-8037提议对这些操作收取更高费用，并将状态创建部分单独计量。其目的是让价格更接近节点承担的长期负担，尤其是在允许区块承载更多工作的情况下。

该提案的示例表格将新账户的状态创建部分定为183,600 gas，而目前为25,000；新存储槽为97,920，而目前为20,000；24千字节的部署为37,784,880，而目前为4,947,200。该表格并非对用户将支付的ETH费用的普遍预测。它在拟议常数下单独列出一个组成部分，其他执行费用另计，最终货币成本取决于当时的gas价格。这一变化的幅度解释了为什么具有严格限制的合约值得更仔细地审视。

一项相关的状态访问提案，EIP-8038，对部分读取和写入重新定价。基金会的开发者影响指南表示，这些gas成本上一次大幅调整是在2021年的柏林分叉中，而状态已经增长。计划中的重新定价是与提高吞吐量的工作一同设计的；在不考虑昂贵状态操作的情况下扩大区块，可能会使节点运营者的验证更加困难。因此，暂停既涉及应用兼容性，也涉及扩容计划，尽管其宣布的触发因素是EIP-8037的交互。

一次外部调用说明了为什么这很难事先察觉。调用方可能故意只传递足够接收方执行有限操作的gas，并假设任何进一步的工作都会安全失败。如果重新定价后的账户或存储访问现在消耗了该额度，接收方可能会在常规支付期间失败，即使用户为外层交易提供了充足的gas。更改钱包的估算并不会重写内部额度。开发者需要检查代码路径及其周围的失败处理，因为一些应用将外部调用失败视为回滚的理由，而另一些则继续执行并记录不同的结果。

Solidity的transfer和send模式历来会转发2,300 gas的津贴。许多团队已经不再依赖该津贴，但已部署的合约可能会继续使用多年。基金会将固定津贴列为一类风险；它并未表示使用它们的每次调用都会失败。执行少量工作的接收方可能仍在额度之内，而触及新重新定价状态的合约则可能超出额度。测试实际对手方比仅仅将函数名的存在视为损坏的证据更为重要。

第二类问题在于自动化。钱包、中继者和托管方可能会为常规任务存储默认gas限制。一项多年来成功运行的操作可能会开始耗尽gas，即使应用合约本身是健全的。在前端提高估算可以修复该路径，但定时代理或使用旧钱包的客户可能会继续提交先前的限制。因此，开发者不仅必须识别受影响的代码，还必须识别为其构建交易的服务。

哪些合约可能遇到问题？

基金会在拟议的时间表下重放了历史主网交易。大多数没有出现实质性问题。在被标记的案例中，许多在提高 gas 上限后完成了交易；较小一部分即使提供大幅增加的 gas 也可能失败。固定津贴、发送到另一个合约的硬编码 gas 数量，或基于 gasleft() 结果的分支，都可能改变交易走的路径。早前的合约警告在 Hoodi 获得其十月日期之前就描述了这些类别。当前的推迟使未解决的案例变得紧迫，但这并不表明所有以太坊合约都存在漏洞。

设想一个应用在向另一个合约发送资金时提供固定的 gas 配额。在新时间表下，接收合约可能需要更多 gas 才能访问存储。如果调用方的配额被嵌入在已部署的代码中，仅仅提高顶层交易上限可能不会给接收调用更多空间。此时失败可能需要合约层面的修复或为用户提供不同的路径。相比之下，如果唯一的问题是钱包使用旧价格估算了一笔交易，那么更新估算并提供更高的上限可能就足够了。这两种情况在操作上是不同的。

一个特别不寻常的 EIP-8037 问题涉及通过减去两次剩余 gas 读数来衡量工作量的代码。该提案解释说，在某些情况下，状态 gas 储库可能使 gasleft() 上升。一个预期非负减少量的计算可能会表现不同，而不可变的已部署合约无法就地修补。确切影响取决于代码和交易路径，这就是为什么重放实际历史交易比关于更高费用的通用警告更重要。

基金会的搜索工具让构建者可以检查受影响的合约地址以及被标记差异的原因。它建议在使用新时间表的开发网上进行测试，并检查那些假定固定上限的代码，即使合约未出现在列表中。历史重放是一种筛查，而不是未来行为的完整清单：在样本期间没有用户调用的路径仍可能包含有漏洞的假设。团队需要针对他们运营的分支进行自己的测试。

重放的结果还取决于交易样本。一个合约可能在一个很少被调用的函数中包含固定 gas 配额；如果该路径不在重放的历史中，工具就无法证明其失败。基金会建议维护者即使其地址未出现在受影响列表中也要检查代码。一个大型应用可能有多个合约、可升级的前端和自动化代理，每个都提供不同的 gas 上限。团队需要按照用户实际调用操作的方式来测试，包括可能将旧估算值保存在缓存中的钱包或机器人。

对于行为发生变化的合约，修复提交交易的接口并不总是足够。如果内部调用的 gas 配额被编译进不可变代码中，其所有者可能需要迁移到新合约。这种迁移可能涉及转移余额、授权或用户权限，并传达新地址。难度取决于产品的设计；没有证据表明每个被标记的合约都需要这项工作。这正是为什么可修复上限的失败与可能损坏的合约之间的区别对团队及其客户都很重要。

测试指南对使用账户抽象或多次合约调用来完成一个用户操作的应用尤其相关。一次结账可能在一个序列中批准资产、路由交换并结算商家。如果某个内部步骤使用硬编码配额，客户可能会看到支付失败，却不知道是哪个合约触及了上限。在拟议规则下重放整个序列比孤立地检查每个合约的公共方法更有信息量。维护者应记录第一个失败的步骤，以及更大的外部 gas 上限是否真的改变了结果。

合约在调用失败后也可能表现出不同的行为，而不是简单地停止。一个记录事件、增加内部余额或尝试第二条路径的回退机制，可能会在其原始作者从未预料到的条件下继续执行。这种差异正是为什么仅描述为“交易成功”的测试结果可能不够充分。输出状态和事件需要与旧执行结果进行比较。基金会的“成功执行但状态改变”类别捕捉了这种可能性，而没有自动将其声明为有害。

钱包、RPC 和工厂面临不同的工作

钱包和远程过程调用提供商在用户签名之前估算交易所需的 gas。EIP-8037 规定 eth_estimateGas 和节点软件必须同时考虑执行 gas 和新的状态 gas 维度。一个旧的缓存常量可能会低估一个状态密集型的交易。用户随后可能会看到失败的交易，即使合约在正确估算的限制下可以正常工作。因此，基础设施更新是兼容性的一部分，而不仅仅是叠加在协议之上的便利措施。

确定性部署工厂提出了另一个狭窄的案例。EIP-8037 讨论了最初使用预签名交易和硬编码 gas 限制放置在标准地址上的工厂。在一个采用新调度方案的全新网络上，如果工厂尚不存在，旧的预签名部署可能会耗尽 gas。该提案明确指出，现有主网和二层网络上已部署的实例不受该特定创世场景的影响。报告这一注意事项很重要：暗示以太坊上已经使用的每个工厂都将消失是具有误导性的。

构建者还需要区分合约未改变和成本未改变。一笔交易可能成功，但消耗不同数量的 gas。一个批量部署或创建许多存储槽的业务，即使没有函数失败，也可能面临显著不同的成本结构。其产品可能需要不同的费用报价、修订的补贴政策或改变其存储信息的方式。基金会的重放类别正是出于这个原因，将完全相同的执行、改变但成功的执行、可通过限制修复的失败以及可能损坏的合约区分开来。

EIP-8037 中的数字值得另一个限定说明。其示例使用假设的 0.08 gwei 基础费用将提议的 gas 转换为 ETH。如果基础费用发生变化，为相同 gas 支付的 ETH 也会变化。开发者在将表格与现有账单进行比较时，必须加上执行费用和实际交易条件，而不是将七倍的状态成本变化呈现为用户完整支付的七倍增长。该提案的目的是将成本分配给资源；一个人的最终费用取决于交易中这些资源的组合。

提议的重新定价规模应与容量目标一起解读。区块中更多的交易空间可能会使网络验证变得昂贵，如果这些交易不成比例地创建持久状态。EIP-8037 为这种增长分配了一个单独的计量器，以便成本不会消失在更大的标题 gas 限制中。EIP-8038 处理对现有状态的访问。它们解决资源问题的不同部分，而一个可工作的区块构建器本身无法确定应用程序是否正确处理了重新定价。

以太坊的区块访问列表有一个单独的任务。它们告诉客户端一个区块触及哪些账户和存储位置，帮助并行组织一些验证工作。在有利条件下，这可能允许更大的吞吐量，但它不会消除新账户和槽位添加的持久存储。测试网需要在真实活动下运行组合升级，因为一个维度的改进可能会暴露另一个维度的约束。推迟使得该组合 Hoodi 演练目前尚未完成。

许多用户将首先间接遇到这些变化，通过其钱包报价的 gas 限制或应用程序的费用估算。一笔不创建新状态的交易可能会与一笔部署大型合约的交易产生不同的效果。一个承诺固定交易成本的交易界面需要检查其承诺是否仍然涵盖其执行的操作。在没有最终主网调度、观察到的需求和最终参数的情况下，关于所有以太坊费用朝一个方向变化的概括性说法为时过早。

2 亿这个数字是测试网设置

Glamsterdam 结合了重新定价之外的更多内容。内嵌的提议者-构建者分离改变了区块负载的交接，而区块级访问列表帮助客户端识别区块将触及的账户和存储。开发者计划使用 2 亿的 Hoodi gas 限制来测试这些变化，与 Sepolia 匹配。该数字是一个测试网参数。它从来不是承诺以太坊主网会立即采用相同的限制，或用户费用会下降某个百分比。

移除 Hoodi 的 gas 上限时间表，使被推迟的分叉的各个组成部分保持在一起。运营方将不会在下周一于该网络上测试 Glamsterdam 下预期更高的容量。开发者仍可使用 Sepolia 和专门构建的 devnet 来研究重新定价的影响。缺失的 Hoodi 演练影响了客户端团队在选择主网时间之前逐步建立信心的顺序，但基金会尚未公布修订后的生产时间表。

其经济账并不像一句关于更便宜 gas 的口号那样简单直接。对创建持久状态收取更高费用，可能使某一笔交易在相同 gas 价格下变得更昂贵。更大的安全容量，如果日后被采纳并使用，可能在其他条件下缓解拥堵。需求决定了用户为区块空间出价多少，而最终的协议设置决定了哪些操作变得更贵或更便宜。无论是暂停还是一次成功的测试，本身都无法解决这些市场变量。

公开协调是有成本的，但带着已知的不确定性继续推进可能代价更大。运营方已为旧 epoch 准备好软件，现在必须移除该时间表；应用开发者必须继续针对一个最终形态可能改变的提案进行测试。这次重置的成本是可见的。一条导致广泛使用的合约失败的主网规则将更难逆转，其后果可能涉及资金或依赖该合约的应用。10 月 22 日的通知没有量化这种风险，但它明确表明开发者认为这一交互足够重要，以至于要暂停 Hoodi 演练。

修订后的提案可以保留对状态收费的目标，同时改变 gas 储库的运作方式或现有合约的过渡规则。它也可以保留规范不变，而要求对应用进行有针对性的修复。推迟通知中并未出现在这两条路线之间做出的公开决定。读者应避免将一项调查视为最终的设计选择。具体的修订内容（如果有的话）将比 Hoodi 等待多少天更为重要。

开发者为何选择等待

以太坊的流程允许客户端团队在公共测试网激活之前调整计划。10 月 22 日在 All Core Devs Execution call 248 上做出的决定，是在此前的警告以及向受影响构建者进行外联之后作出的。公开通知指出了正在调查的领域，但没有公布面临风险的合约的最终数量、EIP-8037 的新版本，或调查将结束的日期。将此次延迟称为所有已部署合约中已确认的缺陷，会超出该发布内容的范围；将其称为例行的日程调整，则会忽略其所述的原因。

旧配置必须在两个层面都被撤回。执行客户端处理交易和状态，而共识客户端协调验证者和分叉时间表。只有当这些客户端在规则和时机上达成一致时，网络才能测试该升级。专门为 10 月 26 日安装了版本的 Hoodi 运营方必须查找修订后的发布说明。基金会表示，随着新客户端版本得到确认，它将添加指向这些版本的链接，而不是将其最初的兼容性表格视为最新。

证据的顺序也提供了教训。重放历史揭示了一个小范围受影响的群体；公共测试网在实时环境中揭示客户端和应用的行为；主网则将最终规则暴露于大规模的经济使用之中。每个阶段都回答了前一个阶段无法回答的问题。Hoodi 的短暂延迟或许能为合约工作争取时间，但它本身并不能证明最终规则是安全的。继续推进的决定应依据测试结果和明确的运营方指示。

运营方通知的范围值得详细说明。普通的主网持有者无需因为 Hoodi 的时间表被撤回而更换钱包。为分叉做了准备的 Hoodi 节点运营方则确实需要重新查看发布说明。调查该 EIP 的协议工程师需要确定在重放中发现的合约行为是可接受的、可通过工具修复的，还是修改提案的理由。应用团队需要测试自己的执行路径。这些是不同的受众，有着不同的截止期限，而一条单一的“升级延迟”警报并不能为每一方提供正确的指示。

基金会的下一篇帖子还可以解决开发者将如何与受影响团队沟通的问题。其 8 月的指南称直接外联已经开始，但仅凭外联数量并不能证明某个合约已被修复。可测试的证据是更新后的合约、修订后的 gas 配置或针对特定产品记录的备用方案。一些不可变合约可能需要用户迁移，这引发了单独的沟通和安全问题：客户必须知道合法的替代合约位于何处，并避免欺诈性地址。目前尚未宣布大规模迁移，因此对于代码无法就地更改的团队来说，这仍是一种应急情况。

在另一个日期之前会发生什么

修订后的时间表应说明将测试哪些 EIP-8037 规则、如果提案被修订则有哪些变化，以及哪些客户端版本在新的 Hoodi 纪元上达成一致。应用维护者需要时间运行受影响合约的搜索、更新估算器、在足够的情况下提高限制，并在不够的情况下检查硬编码的内部调用限额。如果某个可能已损坏的已部署合约没有直接升级路径，其团队可能需要解释用户将如何在任何主网分叉之前获得替代方案。

公开证据将包括重放方法和更新的受影响合约发现、使用最终 gas 计划的开发网结果、多个客户端达成一致的 Hoodi 激活，以及单独的主网公告。即使是一次干净的 Hoodi 激活也只是一次演练，而不是对特定 ETH 价格或最终交易费用的保证。对用户而言，实际的情况是尚未宣布任何 10 月 26 日的主网行动。当前的行动属于 Hoodi 运营者以及那些其应用对 gas 做出假设的团队。

值得关注的内容

• 客户端发布：执行层和共识层的更新，明确移除旧的 10 月 26 日 Hoodi 激活。
• EIP-8037 的发现：新的重放结果、对拟议 gas 规则的更改，以及对带有硬编码限制或 gasleft() 逻辑的合约的处理方式。
• 替代纪元：一份带日期的 Hoodi 计划，在调查结束后恢复可测试的配置。
• 应用修复：受影响构建者的报告，说明更高的限制是否足够，还是已部署的代码需要另一条路径。
• 主网通知：在测试网序列和客户端协调之后，基金会发布的一份独立的生产时间表。

常见问题