事后报告：以太坊主网最终确认性 (2023年5月11日)

日期： 2023/05/12 作者： Nishant Das, Terence Tsao, Preston Van Loon, Potuz, Kasey Kirkham, James He

状态： 已缓解。调查完成。Prysm v4.0.4 发布，包含修复。

网络： Mainnet

概要

在 2023 年 5 月 11 日星期四大约 20:19 UTC，以太坊主网 (Mainnet) 网络遭受了严重的区块生产不足，导致最终确定 (finalization) 暂时延迟（4 个 epoch）。第二天发生了同样的事件，时间稍长（9 个 epoch），并产生了非活跃惩罚 (inactivity penalty)。在这两个事件中，区块链都在没有任何干预的情况下恢复了。

影响

在第一次事件中，大约有 47 个区块丢失，这可以归因于根本原因。在第二次事件中，大约有 149 个区块丢失。当第二次事件中缺少最终性 (finality) 超过 5 个 epoch 时，非活跃惩罚开始应用，并且每个 epoch 呈二次方增加。每个区块平均应该奖励生产者至少 0.025 ETH，丢失的区块代表受影响的区块生产者总收入损失 5 ETH。然而，如果考虑到构建者捆绑奖励 (builder bundle rewards)，真正的收入损失可能要高得多。如果我们假设 65% 的验证者在 8 个 epoch 内处于离线状态并存在非活跃泄漏 (inactivity leak)，我们估计除了因缺少证明 (attestation) 而损失大约 50 ETH 的收入外，还损失了 28 ETH。

总的来说，我们估计应用了 28 ETH 的惩罚，验证者错过了 55 ETH 或更多的潜在收入。这低于每个验证者 0.00015 ETH。

没有验证者因这些事件而被罚没 (slash)，尽管验证者 48607、48608 和 48609 在第二次事件前后不久被罚没。这些罚没可能是由于操作员在切换客户端或尝试复杂的非安全故障转移 (unsafe failover) 时出错造成的。

最终用户的交易受到的影响最小。虽然可用区块空间大幅下降，但 gas 价格并没有高于每日最高 gas 价格。

根本原因

一些共识客户端 (consensus clients)，包括 Prysm，无法以最佳方式处理具有旧目标检查点 (old target checkpoint) 的有效证明 (valid attestations)。这些特定的证明导致客户端重新计算先前的信标状态 (beacon states)，以便验证证明是否属于适当的验证者委员会 (validator committees)。当收到许多这些证明时，Prysm 会因这些昂贵的操作而耗尽资源，并且无法及时满足验证者客户端的请求。

触发因素

广播了许多投票给旧信标区块 (beacon block) 的证明（即 epoch N 期间来自 epoch N-2 的区块），既作为 head block 又作为 target root。当它们的执行客户端 (Execution Client) 没有响应时，这是某些 CL 客户端的标准行为（例如，Lighthouse 就是这样做的）。这些证明虽然有效，但需要重新生成信标状态 (Beacon state) 才能对其进行验证。Prysm 有一个缓存来避免重复这些验证，但这个缓存很快就被填满了，这迫使 Prysm 多次重新生成相同的状态。

检测

在 epoch 200,551 中观察到网络参与度显着下降，并且链暂时停止最终确定，直到 epoch 200,555。

在 epoch 200,750 中观察到网络参与度的另一次显着下降，并且链暂时停止最终确定，直到 epoch 200,759。

哪里出了问题

• 由于缺少区块和证明，网络未能最终确定。
• 信标链客户端 (Beacon chain clients) 因正在处理的最大存款 (max deposits) 而承受了额外的网络压力。
• 在 Prysm 中，发生了太多的重放（replayBlocks 函数），因为我们没有用于重放的缓存。这也是创建所有 go 协程和 CPU 使用的原因。有时相同的数据会被重放多次。有时重放甚至在第一次完成之前就发生了。应该忽略前一个 epoch 的证明，并且应该使用 head state。
• Prysm 中存在一个错误：连接到所有子网的节点可以被这些证明进行 DOS 攻击（似乎所有节点都容易受到攻击，可能除了 Lighthouse），因为它可以弹性地处理分叉网络。当信标状态 (beacon state) 较小时，Prysm 将能够处理这些证明并适当地恢复。然而，由于存款的大量涌入和不断增长的验证者注册表大小，Prysm 这次无法恢复。

Lighthouse 选择删除证明以保持运行，我们选择能够同时保留许多分叉，以便能够在网络分叉非常严重的情况下正确选择规范链。Lighthouse 的技术在这里更好，因为网络没有分叉。他们只是删除了证明并遵循了链。如果网络已经分叉，我们将陷入困境，因为 Lighthouse 将会助长不传播证明。

• 当执行客户端 (execution client) 出现问题或离线时，某些客户端的默认证明行为是使用旧证明生成有效区块。其他客户端可能会以不同的方式处理这种情况，例如将这种情况视为乐观同步 (optimistic sync)。这可能会创建带有旧证明的区块，从而触发 Prysm 和 Teku 中的问题。

我们在哪里幸运

• 在第一次事件中，停机时间仅为 2 个 epoch，在 25 分钟后达到最终确定。第二次事件也相对较短，只有 8 个 epoch 的症状。在任何一次事件中都没有报告大规模的罚没 (slashings)。
• 客户端多样性 (Client diversity) 帮助链恢复，一些客户端仍然能够提出区块并创建证明。
• Lighthouse 删除了有问题的证明并保持活跃。
• 无需手动干预或紧急发布即可解决直接的最终性问题。

经验教训

• 测试网 (Testnets) 不能代表主网 (Mainnet) 环境。Goerli/Prater 只有 45.7 万个验证者，而 Mainnet 有超过 56 万个，并且由于验证者奖励重新质押 (restaking)，Mainnet 中正在发生大规模存款。
• 非活跃泄漏惩罚 (Inactivity leak penalties) 在主网 (Mainnet) 中有效！🎉

已实施的修复

• 当验证最近的规范区块 (canonical block) 作为目标根 (target root) 的证明时，请使用 head state。这是主要的错误！如果在 epoch 1 中用作 slot 33 上的目标根，Prysm 正在为规范槽 25 重新生成状态。
• 当验证前一个 epoch 中边界槽 (boundary slots) 的证明时，请使用下一个槽缓存 (next slot cache)。
• 丢弃任何未被前两条规则验证的证明，并且这些证明的目标根 (target root) 不是我们当前知道的任何链中的检查点 (checkpoint)，也不是我们当前知道的任何链的顶端 (tip)（如果包含在区块中，它们将被处理）。
• 通过上述规则，在正常情况下，主网 (Mainnet) 上基本上不需要进行状态重放 (state replays)，并且这些旧区块的证明（对网络来说大多毫无价值）只是被忽略了。

时间线（大约）

2023/05/11 星期四 (UTC)

20:06:47 — Epoch 200,551 开始，存在一个丢失/孤立的区块和一些丢失的槽，网络参与度降至 88.4%

20:13:11 — Epoch 200,552 开始，并且此 epoch 中有更多丢失的槽，网络参与度降至 69%

20:19:35 — Epoch 200553 开始。逐渐地，越来越多的连续槽丢失，导致总共 18/32 个槽丢失并且未最终确定区块。槽 6417716 ~ 6417709 之间连续丢失最多。网络参与度低至 40%。很明显，这不仅仅是一个 Prysm 问题，因为 Prysm 仅占网络的 33%。

20:29:00 — Prysm 团队正在全力以赴地调查正在发生的问题。

20:32:23 — Epoch 200555 开始，网络开始在没有干预的情况下恢复。

2023/05/12 星期五 (UTC)

17:20:23 — Epoch 200750 开始。区块正以越来越快的速度丢失，参与度降至 66.3%。

17:26:47— Epoch 200751 开始。仅生成了 32 个区块中的 13 个。参与度降至 42.4%。

17:30:00— “主网再次停止最终确定”。全员待命。

17:33:11— Epoch 200752 开始。仅生成了 14 个区块。参与度进一步降至 30.7%。这是主网 (Mainnet) 中任何 epoch 的最低参与度。

18:17:59— Epoch 200759 开始。生成了 32 个区块中的 24 个，参与度为 81.7%。这个 epoch 是恢复的开始。

18:24:23— Epoch 200760 开始。生成了 32 个区块中的 27 个，参与度为 86.2%。此 epoch 恢复了最终确定。

• 原文链接： medium.com/offchainlabs/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～