以太坊 Glamsterdam 升级的讨论出现一项具体建议：Ethlabs 主张先等待外部审计发现，再决定是否修改规范及安排 Hoodi 测试网分叉。需要区分的是，这是一项关于决策顺序的建议，并不代表升级已经被正式暂停。
审计结果关系到哪些升级决定
Ethlabs 已持续两周以上监测和分析 EIP-8037、EIP-8038 对已部署智能合约可能产生的影响。以太坊基金会委托 Chain Security 与 Dedaub 开展外部审计，结果预计于2026年11月16日公布。
Ethlabs 建议，在审计发现公布并形成明确立场之前，暂不推进规范修改，也不安排 Hoodi 测试网分叉。这把两个不同层面的动作放在了同一道评估关口：规范修改涉及升级规则如何确定，测试网分叉则涉及如何将相关规则放入测试环境验证。审计结论可能成为判断下一步安排的重要依据，但预计公布日期本身并不等于升级获准推进的日期。
兼容性评估应落到已部署合约
这次评估的重点是已部署智能合约可能受到的影响。协议升级需要考虑新规则与既有应用之间的关系；即使提案的目标明确，也仍需检查现有合约在规则变化后能否按预期运行。对应用开发者而言，关键问题因此落在自身合约的具体行为，而不只是升级是否进入下一阶段。
现有信息并未给出具体受影响合约、影响范围或审计结论，因此不能据此认定 EIP-8037、EIP-8038 已造成兼容性故障。持续监测与外部审计说明相关影响正在被评估，风险是否成立、涉及哪些使用场景，仍需由审计发现和具体测试结果支撑。
外部审计与开发者自检形成互补
Ethlabs 同时呼吁应用开发者运行以太坊基金会提供的自检工具，并通过 glamsterdam@ethereum.org 披露潜在问题。这意味着等待审计期间，应用侧仍有明确的参与方式：检查自身合约，并将发现的问题提交给相关团队。
从机制上看，外部审计提供独立检查，开发者自检则有助于把评估落实到实际应用。两者关注的范围可能不同：审计可以检查规则及其影响，应用团队更了解自身合约的使用方式和依赖关系。如果自检发现异常，具体反馈能够为后续判断提供线索；但运行工具本身并不能替代完整审计，也不能自动构成所有使用场景均安全的证明。
判断重点是证据能否支持下一步
我们的判断是，这项建议值得关注之处，在于将既有合约的兼容性证据放到规范修改和测试网安排之前。其依据是两个提案仍在接受影响分析，外部审计尚待公布；在这一条件下，先补充证据有助于减少后续安排建立在不完整判断上的风险。这一判断不意味着提案必然存在问题，也不足以推导升级会被取消或延期多久。
后续应观察三项具体进展：审计是否按预计时间公布、发现是否明确涉及已部署合约，以及相关团队如何据此形成对规范修改和 Hoodi 分叉的立场。若审计提出问题，还需关注其适用范围与处理安排；若未发现问题，也应结合开发者反馈理解结论的覆盖边界。当前最需要避免的误读，是把审计等待期当作已经确定的故障事件，或把一次结果公布当作升级安排自动落定。
