【英文】Sepolia 硬分叉故障原因分析与修复纪实

Chainfeeds 导读：

Sepolia 硬分叉原定于 3 月 5 日 7:30 UTC 激活。硬分叉后不久，Jim McDonald 发送了一笔存款以测试 Pectra 新增的执行触发的提款（execution-triggered withdrawal）功能。然而，在短时间内，Geth 节点开始报告错误，同时区块链上出现大量空区块（empty blocks）。

文章来源：

https://mariusvanderwijden.github.io/blog/2025/03/08/Sepolia/

文章作者：

MariusVanDerWijden

观点：

MariusVanDerWijden：错误消息显示：「无法解析存款数据：存款数据长度错误：期望 576，实际 32（unable to parse deposit data: deposit wrong length: want 576, have 32）。」这表明存款合约（deposit contract）在处理存款时，触发了一个意外的事件，而不是客户端所预期的 Deposited 事件。经过调查，我们发现这是因为存款合约受到代币门控（token-gated），在存款处理时，它实际上触发了一个 ERC-20 代币转账事件（ERC-20 transfer event）。EIP-6110 规范要求所有存款合约的日志（logs）必须按照相同的方式处理，并且如果事件格式不正确，客户端应报错。所有客户端都遵循了这一行为，因此当存款交易包含在区块中时，该区块会因错误而作废。这导致网络仅能生产空区块，因为每当验证者尝试包含存款交易时，就会触发错误，导致区块生产失败。 Geth 开发团队的 Felix 提出了一个修复方案，该方案可以忽略存款合约中不符合预期的日志，从而防止错误触发。由于这个修复涉及共识规则的更改，如果部分节点升级、部分节点未升级，可能导致区块链分裂。因此，我们决定在 10:30 UTC 确定统一在 14:00 UTC 进行协调升级，以确保所有团队有足够时间准备新版本并更新节点。在这 3.5 小时的等待期内，Sepolia 仍然只能生产空区块。为了临时缓解问题，我们决定移除触发问题的存款交易，通过替换高额 Gas 费交易来覆盖这些存款交易。这样，网络开始恢复正常，重新生成包含交易的区块。我们检查了存款合约，并确认普通用户无法触发存款功能（因为该功能受到代币门控，只有受信方才能获得代币）。然而，我们忽略了 ERC-20 标准的一个边缘情况，导致问题再次出现。 在网络上开始出现大量空区块后，我们再次检查交易池，发现又有一笔交易触发了相同的错误。起初，我们以为是某位受信验证者误操作，但很快发现这是一笔由水龙头（faucet）新资助的账户发出的交易。这意味着，有人发现了 ERC-20 标准的一个漏洞并加以利用。攻击者利用这个漏洞，发送了一笔 0 代币转账到存款合约，再次触发了问题。为了阻止攻击，我们采取了私有修复（private fix），仅在部分开发者运维节点（devops nodes）上进行部署。修复方案是直接过滤掉所有与存款合约交互的交易。由于我们怀疑攻击者正在监视我们在公共聊天中的讨论，因此没有公开修复细节，而是悄悄更新了一些控制节点，以便让区块链继续生成完整区块。当我们更新了所有 ef_devops 节点（约占网络的 10%），这些节点开始重新生成完整区块，允许用户继续使用链上的服务，直到正式修复部署完成。在 14:00 UTC，所有节点统一升级到包含正式修复的新版本。几分钟后，我们观察到攻击者的交易成功被包含在区块中，证明所有节点已经完成升级，网络恢复正常。【原文为英文】