• 阿卡什·科斯拉 (evmos.org)

• Federico Kunze Küllmer (evmos.org)

• 乔修道院 (jabbey.io)

• Marko Barcevic（二元持股）

• Prajjwol Gautam (evmos.org)

2022-03-09

注意：所有时间都在 UTC

15:19 - Interchain GmbH 的 IBC 核心团队通知 Evmos 核心团队潜在的安全漏洞

15:25 - Evmos 团队响应通知并要求提供有关受影响组件、攻击场景等的其他信息。

10:58-11:38 - IBC 团队回复了攻击场景，并建议避免在 Osmosis 链上创建 LP 池并执行升级以修复漏洞。

11:55 - 团队之间讨论潜在的解决方法。

12:50 - Evmos 联合创始人分析了漏洞评分的全部范围，并起草了一份新的关键安全公告。

16:03 - 创建了一个电报组以协调 Evmos 安全升级

17:26 - 验证者开始收集可用性，以评估在 46,000 高度手动紧急升级的可行性。

20:17 - 升级计划重申，v1.1.2由于测试等待发布

21:27 - 网络意识不足，确定最佳行动方案是在 56,300 高度延迟 20 小时。

21:42（3 月 5 日）- 10:36（3 月 6 日） - 核心团队与其他 Tendermint 和 Cosmos SDK 核心团队和专家就没有治理升级的升级逻辑进行协商，以跳过 5 天的紧急升级时间表。确定最安全的方法是让 Cosmos SDK 分叉ScheduleUpgradeNoHeightCheck在升级高度BeginBlocker同时调用v1.1.2，v2.0.0以便遵循Cosmovisor gov 提案升级路径，而无需在 Evmos 代码库中完全重建它。进行了测试，升级工作。

12:35 - 升级逻辑完成v1.1.2

12:44 - 升级逻辑合并，发布正在形成

12:52 -v1.1.2根据需要立即宣布升级

14:02 - 升级逻辑完成并修改为支持模块内的店内迁移逻辑，而不是在升级处理程序中更改模块外的参数。在与其他 Cosmos 和 Tendermint 专家讨论后，很明显迁移是设置新参数和提升模块共识版本的更安全的方式。v2.0.0

14:54 - 代码经过同行评审以了解 v2 升级逻辑

14:58 - 为 v2 升级逻辑合并代码

15:00 - 17:37 - 在与 v2 版本合并之前重新设置基准并审查安全咨询补丁

17:37 - 安全咨询补丁合并到release/v2.0.x分支中

17:42 -v2.0.0发布

17:46 -v2.0.0升级宣布，升级延迟至 58,700

21:01 - Evmos 核心团队再次进行测试，发现测试升级失败，开发人员立即开始调查并准备v2.0.1

21:11 - 正如预期的那样，人们对 58,700 人的共识失败开始升级过程

21:12 -v2.0.0升级错误报告开始，核心团队在21:01发现相同的错误：

21:21 - 团队向 Discord 宣布开发人员正在开发补丁版本

21:27 - 核心团队和 Cosmos 开发人员了解这GetParams破坏了迁移，并合并了一个修补程序 PR

21:33 -v2.0.1发布，修复错误

21:35 -v2.0.1升级开始

21:40 - 58700 似乎已经达成了 67% 的共识，但 58701 陷入了共识轮次……

21:41 - 对等阻塞/丢失的报告开始，可能是由于版本差异和人们重新启动他们的节点

21:47 -v2.0.0被意外部署在某些验证器上的报告

不，问题不是 git fetch，目录中有一个现有的构建，它没有被新的替换

21:50 -consensus_state挂起报告

我跑的时候会挂curl -s localhost:26657/consensus_state

21:50 - 参与者指出排名第一的验证者缺少预提交/预投票并且网络没有前进，因为没有足够的人正确升级并且现在正在参与 58701 的轮次。建议排名第一和其他人比如#7和#8升级。

21:50 - 失去同行的进一步报告

21:50 - 22:31 - 几个验证者在尝试更新对等设置或尝试获取对等时，由于对等问题而重新启动其节点

22:03 - 联系排名第一的验证者和其他节点，以便上线 58701 并参与共识轮次

22:31 - 出现关于对等设置的建议，Evmos 团队在#validators-active 开始了对等收集工作

22:44 - 重新同步的报告

神秘人，我认为我们的 db 损坏了2.0.0，他不想投票给下一个区块。重新同步区块链并升级它的工作

22:44 - 关闭挂起的报告，以解决对等问题

有人注意到v2.0.1需要很长时间才能关闭吗？

22:49 - 另一个验证者开始重新同步（@jabbey）链

试图重新同步链......获得大约 100 个块 / 秒（这感觉是个坏主意......但我们在这里）

23:00 - 建议使用快照让节点再次参与共识过程，如果他们没有看到 prevotes

23:32 - 节点在启动节点后报告他们正在积极地放弃对等节点，只有 5/10 在预投票阶段在线

23:41 - 建议人们将种子作为旧addrbook.json文件删除，并且它们可能不会更新的事实可能会导致节点的对等点损坏

23:46 - 逐步建议人们应该更新对等点，增加入站和出站的对等计数并删除他们现有的addrbook.json，并重新启动节点（注意重新启动节点可能意味着需要重新同步，不知道在时间）

23:41 - 建议人们将种子作为旧addrbook.json文件删除，并且它们可能不会更新的事实可能会导致节点的对等点损坏

23:46 - 逐步建议人们应该更新对等点，增加入站和出站的对等计数并删除他们现有的addrbook.json，并重新启动节点（注意重新启动节点可能意味着需要重新同步，不知道在时间）

00:12 -由于担心 GitHub存储库存在转储，新的对等点列表可确保升级对等点并使其更加健壮。tharsis/mainnetaddrbook.json

00:39 -重新同步流程指南发布。

00:30 - 01:40 - 很多双重签名的不确定性。核心团队保证，只要priv_validator_state.json文件不被删除，人们就会没事的，不会双重签名。

01:17 - 01:50 - 与排名第一的验证者协调，以确保他们启动他们的节点，因为他们不在最新的共识轮次中。由于担心双重签名，他们最初不愿意恢复，但在 Evmos 团队成员完成避免双重签名的步骤后，他们就在线了。

01:50 - 生产区块 58,701

01:52 - 5 个节点上的拜占庭行为证据报告（双符号）：

投票权7.62%3.86%3.03%1.95%0.57%16.97% 总计

在这件事发生之后，我们仍然没有获得 67% 的网络投票权，在斗争结束时，看到 5 个拥有约 17% 投票权的双标，每个人似乎都同意停止该链。

02:00 - 参与者出现疲劳迹象（已经有一段时间了）

02:25 - 验证者同意关闭节点，因为我们必须再次等待网络继续（在双重签名后它没有继续）

02:52 - 发布决定将官方回复延迟 24 - 48 小时

使用根本原因识别技术。从影响开始，询问为什么会发生以及为什么会产生影响。继续问为什么，直到找到根本原因。将您的“为什么”记录为此处的列表或问题所附的图表。

为什么链条会停止？

• 核心团队在主网上发布部分测试升级程序代码

• 共识错误后的升级协调太高，团队安排得太早，只有几个小时可用于管理升级到新版本

• 升级复杂性达到了极端（重启、对等点、重新同步/人们移动到不同的机器）

• 5 个验证者双重签名，导致它们被墓碑化

  • 当验证者被墓碑化时，他们不能被释放

  • 这是一个严重的错误。墓碑本质上是永久监禁。您的验证器将永远被淘汰。所有的委托都需要手动解除绑定，这对委托人来说也是一个可怕的场景。

  • 考虑到受影响的验证者和用户，不继续这条链是有道理的。

• 在尝试恢复网络数小时后，我们目睹了多个验证者被墓碑化。验证者社区和核心团队认为这是不对的，并决定停止网络，直到升级测试并准备好用于生产

为什么有 5 个验证者双重签名？

• 他们unsafe-reset-all在共识停止期间运行，导致他们破坏了他们的priv_validator_state.json文件。

  • 或者，一些节点在此过程中将其验证者节点迁移到另一台机器上，而忘记带上他们的priv_validator_state.json

• 他们不知道他们必须备份并带上他们的priv_validator_state.json，因为当链正常运行时这通常不是问题，因为大多数块将在一轮内达成共识，并且在说明手册中没有明确说明这样做直到为时已晚。

为什么有这么多验证者运行unsafe-reset-all而不保留他们的priv_validator_state.json?

• 验证者必须从快照中恢复，因为如果他们在升级期间重新启动节点，他们将不再参与共识轮次，因此在这样做时，他们要么$EVMOSD_HOME/data完全删除，要么运行unsafe-reset-all. 在共识停止期间执行此操作时，它是不安全的（正如命令在其标题中指出的那样），并且如果没有备份priv_validator_state.json，则不完全了解如何恢复。

• 周围有很多误解priv_validator_state.json

• 关于重新同步时此文件的影响，没有明确的答案

  • 缺乏对同一个区块达成共识的每一轮都意味着提议者更改的理解，如果提议者回来并重新进行轮次，就像 5 个双重签名者所做的那样，他们将抛出两个区块。

为什么验证者必须从快照中恢复？

• 当链停止并且人们在停止期间重新启动他们的节点时，节点将不会恢复参与共识

  • 当验证器启动时v2.0.1，许多人认为存在对等问题，因为这在 cosmos 生态系统中很常见。在停止他们的节点以修改对等点列表和/或增加连接对等点的数量后，他们重新启动了他们的节点。我们认为这导致了Tendermint陷入困境。正如我们所说的，这种“边缘”状态是 Tendermint 不知道它应该处于块同步模式还是共识模式的状态，从而导致节点处于空闲状态。

• 因此，解决方案是使用快照从新数据库开始

• 在此期间，许多人淹没了 Polkachu 端点，但运营商在从头下载或同步节点后设法争抢并制作 Polkachu 快照的镜像

• 双重签名的人和区块中的提议者之间有很强的相关性

  • 在 58701中针对拜占庭行为检查每一轮的提议者。

为什么验证者要重启他们的节点？

• 一些运营商重新启动，因为它“看起来卡住了”

• 其他运营商重新启动，因为没有人可以保留一组可靠的同行

• 升级比大多数验证器习惯的任何升级都复杂

为什么没有人能保持一组稳定的同龄人？

• 我们怀疑网络上的许多完整节点（我们有数千个）尚未升级，并且在某些节点最初重新启动后，人们在升级期间查询无效对等节点。许多节点的addrbook.json文件可能包含不再兼容且无法对等的旧版本节点。

• 人们很可能与没有升级的种子相关联，并且可能正在广播他们大量的无效addrbook.json对等节点。

• 当人们在升级过程中关闭时，对等情况的脆弱性会变得更糟。

• 几个关键节点后来也没有升级，这意味着很多关键节点运营商都在运行旧版本。

• 我们去了，我们最终创建了一个新的同行列表

为什么我们需要在v1.1.2发布之前进行紧急发布v2.0.1？

• 它需要一个升级处理程序来紧急升级高度为 58,700 的链条。

  • 我们不想对升级进行治理，因为这是一个等待发生的安全漏洞，而且 5 天的时间对于等待修补一个可发现的安全漏洞来说太长了，该漏洞会破坏声明过程并允许恶意行为者窃取声明。

为什么我们没有发现v2.0.0早期升级失败的问题？

• 没有自动化的测试套件来捕捉故障，因此测试要么从头开始构建，要么手动完成。

  • 手动测试一直进行到最后一分钟的更改 - 但是并非所有团队成员都了解迁移期间手动测试的需求或能力。

• 因为我们在最后一分钟更改了迁移逻辑以尝试通过模块迁移进行升级（因为这比在升级处理程序中进行更安全），所以我们在升级前测试了这大约 300 个块。

  • 我们没有足够的时间在几个小时前召集可用人员并准备好进行测试，因为这是手动测试，需要对升级有深入的了解。

• 当我们使用旧的升级处理程序逻辑（在升级处理程序中设置新参数）时，在指定块高度使用 cosmovisor 升级时已经过测试并可以正常工作，但它不符合最佳实践，因为设置新参数应该在模块本身的迁移处理程序。在编写迁移处理程序时，我们试图获取现有参数并设置它，但是GetParams当您运行迁移时，将返回空字节。

  • 所以解决方法是在迁移中设置所有新参数，而不从存储中检索旧参数。

• 当我们确实测试了迁移逻辑并发现了故障时，它落后了 300 个街区，因为其他 Evmo 工程师重新上线。到那时，已经来不及了，Evmos不得不接受58700的升级命运。

为什么这次升级对验证者来说变得如此复杂？

• Evmos 团队在协调紧急升级时犯了几个错误

  • 发布前未测试v2.0.0，导致第二次更新

    • 如果未经测试，升级应该已延迟/不会被推出

  • 由于漏洞的严重性，发布时间紧迫

    • 至少提前 24 小时发出通知，区块高度有所推迟，但在升级前几个小时发布被削减，这意味着验证者必须在线交换二进制文件

    • 升级非常激进。

    • 时间线是在修复之前选择的，这不是安全事件的处理方式

      • 即使用户资金存在风险，也应该在公开之前找到解决方案，甚至是更广泛的验证者组

  • 在不可行的时间线上为此使用 cosmovisor，当原始设计使状态机兼容直到分叉高度时，需要手动升级

    • 团队在节点运营商中过度估计了 cosmovisor 的重要性

为什么要花这么多轮来尝试升级？

• 因为升级版本是最后一分钟，升级失败，恢复不是立即的。

• 投票权不存在，我们在某些轮次中获得了 66% 的投票权，持续了 10 轮，这意味着数小时和数小时。

为什么人们需要依赖快照和重新同步v1.1.2来重新应用升级v2.0.1？

• 当验证器启动时v2.0.1，许多人认为存在对等问题，因为这在 cosmos 生态系统中很常见。在停止他们的节点以修改对等点列表和/或增加连接对等点的数量后，他们重新启动了他们的节点。我们认为这导致了嫩薄荷的一种不确定状态。正如我们所说的，这种“边缘”状态是 Tendermint 不知道它应该处于块同步模式还是共识模式的状态，从而导致节点处于空闲状态。要从这种不稳定状态中恢复，用户需要删除他们的数据库并从升级前的快照中恢复并同步到升级高度，然后更改为v2.0.1.

• 为验证者创建文档以部署和运行 Tendermint ( ) 的密钥管理服务 (KMS)tmkms或节点 ( ) 的多方计算签名服务horcrux。

• 在不保存 的本地副本的情况下清除NEVER 的说明，说明此文件的重要性。一个新的命令被添加到了做安全重置的招标。 unsafe-reset-allpriv_validator_state.json

  • 将验证器密钥迁移指南制作到新机器上，因为这也没有很好的记录。

• 验证器的手动升级和紧急升级文档，以防自动升级无法防止 FUD。

• 确保种子/对等运营商知道在此过程中升级其完整节点

  • 弄清楚如何拥有一个由 CI 或 Discord 机器人针对工作对等点进行测试的对等点列表。

• Genesis JSON 文件在高度 58,699 处导出（即在验证者双重签名之前）或在高度 0 处重新启动链。

• 使用包含附加修复 (TBA) 的新版本重新启动链。

• 创建 Cosmos SDK 链升级操作指南

• 创建内部安全策略

• 为自动升级 (Cosmovisor) 和手动升级创建升级集成和 E2E 测试。

• 在 Tendermint Core 上打开一个改进PR以仅重置数据库，而不是priv_validator_state.json在运行时擦除数据库unsafe-reset-all。

• 事件的验尸文件和补救措施

• 阿卡什·科斯拉 (evmos.org)

• Federico Kunze Küllmer (evmos.org)

• 乔修道院 (jabbey.io)

• Marko Barcevic（二元持股）

• Prajjwol Gautam (evmos.org)

2022-03-09

注意：所有时间都在 UTC

15:19 - Interchain GmbH 的 IBC 核心团队通知 Evmos 核心团队潜在的安全漏洞

15:25 - Evmos 团队响应通知并要求提供有关受影响组件、攻击场景等的其他信息。

10:58-11:38 - IBC 团队回复了攻击场景，并建议避免在 Osmosis 链上创建 LP 池并执行升级以修复漏洞。

11:55 - 团队之间讨论潜在的解决方法。

12:50 - Evmos 联合创始人分析了漏洞评分的全部范围，并起草了一份新的关键安全公告。

16:03 - 创建了一个电报组以协调 Evmos 安全升级

17:26 - 验证者开始收集可用性，以评估在 46,000 高度手动紧急升级的可行性。

20:17 - 升级计划重申，v1.1.2由于测试等待发布

21:27 - 网络意识不足，确定最佳行动方案是在 56,300 高度延迟 20 小时。

21:42（3 月 5 日）- 10:36（3 月 6 日） - 核心团队与其他 Tendermint 和 Cosmos SDK 核心团队和专家就没有治理升级的升级逻辑进行协商，以跳过 5 天的紧急升级时间表。确定最安全的方法是让 Cosmos SDK 分叉ScheduleUpgradeNoHeightCheck在升级高度BeginBlocker同时调用v1.1.2，v2.0.0以便遵循Cosmovisor gov 提案升级路径，而无需在 Evmos 代码库中完全重建它。进行了测试，升级工作。

12:35 - 升级逻辑完成v1.1.2

12:44 - 升级逻辑合并，发布正在形成

12:52 -v1.1.2根据需要立即宣布升级

14:02 - 升级逻辑完成并修改为支持模块内的店内迁移逻辑，而不是在升级处理程序中更改模块外的参数。在与其他 Cosmos 和 Tendermint 专家讨论后，很明显迁移是设置新参数和提升模块共识版本的更安全的方式。v2.0.0

14:54 - 代码经过同行评审以了解 v2 升级逻辑

14:58 - 为 v2 升级逻辑合并代码

15:00 - 17:37 - 在与 v2 版本合并之前重新设置基准并审查安全咨询补丁

17:37 - 安全咨询补丁合并到release/v2.0.x分支中

17:42 -v2.0.0发布

17:46 -v2.0.0升级宣布，升级延迟至 58,700

21:01 - Evmos 核心团队再次进行测试，发现测试升级失败，开发人员立即开始调查并准备v2.0.1

21:11 - 正如预期的那样，人们对 58,700 人的共识失败开始升级过程

21:12 -v2.0.0升级错误报告开始，核心团队在21:01发现相同的错误：

21:21 - 团队向 Discord 宣布开发人员正在开发补丁版本

21:27 - 核心团队和 Cosmos 开发人员了解这GetParams破坏了迁移，并合并了一个修补程序 PR

21:33 -v2.0.1发布，修复错误

21:35 -v2.0.1升级开始

21:40 - 58700 似乎已经达成了 67% 的共识，但 58701 陷入了共识轮次……

21:41 - 对等阻塞/丢失的报告开始，可能是由于版本差异和人们重新启动他们的节点

21:47 -v2.0.0被意外部署在某些验证器上的报告

不，问题不是 git fetch，目录中有一个现有的构建，它没有被新的替换

21:50 -consensus_state挂起报告

我跑的时候会挂curl -s localhost:26657/consensus_state

21:50 - 参与者指出排名第一的验证者缺少预提交/预投票并且网络没有前进，因为没有足够的人正确升级并且现在正在参与 58701 的轮次。建议排名第一和其他人比如#7和#8升级。

21:50 - 失去同行的进一步报告

21:50 - 22:31 - 几个验证者在尝试更新对等设置或尝试获取对等时，由于对等问题而重新启动其节点

22:03 - 联系排名第一的验证者和其他节点，以便上线 58701 并参与共识轮次

22:31 - 出现关于对等设置的建议，Evmos 团队在#validators-active 开始了对等收集工作

22:44 - 重新同步的报告

神秘人，我认为我们的 db 损坏了2.0.0，他不想投票给下一个区块。重新同步区块链并升级它的工作

22:44 - 关闭挂起的报告，以解决对等问题

有人注意到v2.0.1需要很长时间才能关闭吗？

22:49 - 另一个验证者开始重新同步（@jabbey）链

试图重新同步链......获得大约 100 个块 / 秒（这感觉是个坏主意......但我们在这里）

23:00 - 建议使用快照让节点再次参与共识过程，如果他们没有看到 prevotes

23:32 - 节点在启动节点后报告他们正在积极地放弃对等节点，只有 5/10 在预投票阶段在线

23:41 - 建议人们将种子作为旧addrbook.json文件删除，并且它们可能不会更新的事实可能会导致节点的对等点损坏

23:46 - 逐步建议人们应该更新对等点，增加入站和出站的对等计数并删除他们现有的addrbook.json，并重新启动节点（注意重新启动节点可能意味着需要重新同步，不知道在时间）

23:41 - 建议人们将种子作为旧addrbook.json文件删除，并且它们可能不会更新的事实可能会导致节点的对等点损坏

23:46 - 逐步建议人们应该更新对等点，增加入站和出站的对等计数并删除他们现有的addrbook.json，并重新启动节点（注意重新启动节点可能意味着需要重新同步，不知道在时间）

00:12 -由于担心 GitHub存储库存在转储，新的对等点列表可确保升级对等点并使其更加健壮。tharsis/mainnetaddrbook.json

00:39 -重新同步流程指南发布。

00:30 - 01:40 - 很多双重签名的不确定性。核心团队保证，只要priv_validator_state.json文件不被删除，人们就会没事的，不会双重签名。

01:17 - 01:50 - 与排名第一的验证者协调，以确保他们启动他们的节点，因为他们不在最新的共识轮次中。由于担心双重签名，他们最初不愿意恢复，但在 Evmos 团队成员完成避免双重签名的步骤后，他们就在线了。

01:50 - 生产区块 58,701

01:52 - 5 个节点上的拜占庭行为证据报告（双符号）：

投票权7.62%3.86%3.03%1.95%0.57%16.97% 总计

在这件事发生之后，我们仍然没有获得 67% 的网络投票权，在斗争结束时，看到 5 个拥有约 17% 投票权的双标，每个人似乎都同意停止该链。

02:00 - 参与者出现疲劳迹象（已经有一段时间了）

02:25 - 验证者同意关闭节点，因为我们必须再次等待网络继续（在双重签名后它没有继续）

02:52 - 发布决定将官方回复延迟 24 - 48 小时

使用根本原因识别技术。从影响开始，询问为什么会发生以及为什么会产生影响。继续问为什么，直到找到根本原因。将您的“为什么”记录为此处的列表或问题所附的图表。

为什么链条会停止？

• 核心团队在主网上发布部分测试升级程序代码

• 共识错误后的升级协调太高，团队安排得太早，只有几个小时可用于管理升级到新版本

• 升级复杂性达到了极端（重启、对等点、重新同步/人们移动到不同的机器）

• 5 个验证者双重签名，导致它们被墓碑化

  • 当验证者被墓碑化时，他们不能被释放

  • 这是一个严重的错误。墓碑本质上是永久监禁。您的验证器将永远被淘汰。所有的委托都需要手动解除绑定，这对委托人来说也是一个可怕的场景。

  • 考虑到受影响的验证者和用户，不继续这条链是有道理的。

• 在尝试恢复网络数小时后，我们目睹了多个验证者被墓碑化。验证者社区和核心团队认为这是不对的，并决定停止网络，直到升级测试并准备好用于生产

为什么有 5 个验证者双重签名？

• 他们unsafe-reset-all在共识停止期间运行，导致他们破坏了他们的priv_validator_state.json文件。

  • 或者，一些节点在此过程中将其验证者节点迁移到另一台机器上，而忘记带上他们的priv_validator_state.json

• 他们不知道他们必须备份并带上他们的priv_validator_state.json，因为当链正常运行时这通常不是问题，因为大多数块将在一轮内达成共识，并且在说明手册中没有明确说明这样做直到为时已晚。

为什么有这么多验证者运行unsafe-reset-all而不保留他们的priv_validator_state.json?

• 验证者必须从快照中恢复，因为如果他们在升级期间重新启动节点，他们将不再参与共识轮次，因此在这样做时，他们要么$EVMOSD_HOME/data完全删除，要么运行unsafe-reset-all. 在共识停止期间执行此操作时，它是不安全的（正如命令在其标题中指出的那样），并且如果没有备份priv_validator_state.json，则不完全了解如何恢复。

• 周围有很多误解priv_validator_state.json

• 关于重新同步时此文件的影响，没有明确的答案

  • 缺乏对同一个区块达成共识的每一轮都意味着提议者更改的理解，如果提议者回来并重新进行轮次，就像 5 个双重签名者所做的那样，他们将抛出两个区块。

为什么验证者必须从快照中恢复？

• 当链停止并且人们在停止期间重新启动他们的节点时，节点将不会恢复参与共识

  • 当验证器启动时v2.0.1，许多人认为存在对等问题，因为这在 cosmos 生态系统中很常见。在停止他们的节点以修改对等点列表和/或增加连接对等点的数量后，他们重新启动了他们的节点。我们认为这导致了Tendermint陷入困境。正如我们所说的，这种“边缘”状态是 Tendermint 不知道它应该处于块同步模式还是共识模式的状态，从而导致节点处于空闲状态。

• 因此，解决方案是使用快照从新数据库开始

• 在此期间，许多人淹没了 Polkachu 端点，但运营商在从头下载或同步节点后设法争抢并制作 Polkachu 快照的镜像

• 双重签名的人和区块中的提议者之间有很强的相关性

  • 在 58701中针对拜占庭行为检查每一轮的提议者。

为什么验证者要重启他们的节点？

• 一些运营商重新启动，因为它“看起来卡住了”

• 其他运营商重新启动，因为没有人可以保留一组可靠的同行

• 升级比大多数验证器习惯的任何升级都复杂

为什么没有人能保持一组稳定的同龄人？

• 我们怀疑网络上的许多完整节点（我们有数千个）尚未升级，并且在某些节点最初重新启动后，人们在升级期间查询无效对等节点。许多节点的addrbook.json文件可能包含不再兼容且无法对等的旧版本节点。

• 人们很可能与没有升级的种子相关联，并且可能正在广播他们大量的无效addrbook.json对等节点。

• 当人们在升级过程中关闭时，对等情况的脆弱性会变得更糟。

• 几个关键节点后来也没有升级，这意味着很多关键节点运营商都在运行旧版本。

• 我们去了，我们最终创建了一个新的同行列表

为什么我们需要在v1.1.2发布之前进行紧急发布v2.0.1？

• 它需要一个升级处理程序来紧急升级高度为 58,700 的链条。

  • 我们不想对升级进行治理，因为这是一个等待发生的安全漏洞，而且 5 天的时间对于等待修补一个可发现的安全漏洞来说太长了，该漏洞会破坏声明过程并允许恶意行为者窃取声明。

为什么我们没有发现v2.0.0早期升级失败的问题？

• 没有自动化的测试套件来捕捉故障，因此测试要么从头开始构建，要么手动完成。

  • 手动测试一直进行到最后一分钟的更改 - 但是并非所有团队成员都了解迁移期间手动测试的需求或能力。

• 因为我们在最后一分钟更改了迁移逻辑以尝试通过模块迁移进行升级（因为这比在升级处理程序中进行更安全），所以我们在升级前测试了这大约 300 个块。

  • 我们没有足够的时间在几个小时前召集可用人员并准备好进行测试，因为这是手动测试，需要对升级有深入的了解。

• 当我们使用旧的升级处理程序逻辑（在升级处理程序中设置新参数）时，在指定块高度使用 cosmovisor 升级时已经过测试并可以正常工作，但它不符合最佳实践，因为设置新参数应该在模块本身的迁移处理程序。在编写迁移处理程序时，我们试图获取现有参数并设置它，但是GetParams当您运行迁移时，将返回空字节。

  • 所以解决方法是在迁移中设置所有新参数，而不从存储中检索旧参数。

• 当我们确实测试了迁移逻辑并发现了故障时，它落后了 300 个街区，因为其他 Evmo 工程师重新上线。到那时，已经来不及了，Evmos不得不接受58700的升级命运。

为什么这次升级对验证者来说变得如此复杂？

• Evmos 团队在协调紧急升级时犯了几个错误

  • 发布前未测试v2.0.0，导致第二次更新

    • 如果未经测试，升级应该已延迟/不会被推出

  • 由于漏洞的严重性，发布时间紧迫

    • 至少提前 24 小时发出通知，区块高度有所推迟，但在升级前几个小时发布被削减，这意味着验证者必须在线交换二进制文件

    • 升级非常激进。

    • 时间线是在修复之前选择的，这不是安全事件的处理方式

      • 即使用户资金存在风险，也应该在公开之前找到解决方案，甚至是更广泛的验证者组

  • 在不可行的时间线上为此使用 cosmovisor，当原始设计使状态机兼容直到分叉高度时，需要手动升级

    • 团队在节点运营商中过度估计了 cosmovisor 的重要性

为什么要花这么多轮来尝试升级？

• 因为升级版本是最后一分钟，升级失败，恢复不是立即的。

• 投票权不存在，我们在某些轮次中获得了 66% 的投票权，持续了 10 轮，这意味着数小时和数小时。

为什么人们需要依赖快照和重新同步v1.1.2来重新应用升级v2.0.1？

• 当验证器启动时v2.0.1，许多人认为存在对等问题，因为这在 cosmos 生态系统中很常见。在停止他们的节点以修改对等点列表和/或增加连接对等点的数量后，他们重新启动了他们的节点。我们认为这导致了嫩薄荷的一种不确定状态。正如我们所说的，这种“边缘”状态是 Tendermint 不知道它应该处于块同步模式还是共识模式的状态，从而导致节点处于空闲状态。要从这种不稳定状态中恢复，用户需要删除他们的数据库并从升级前的快照中恢复并同步到升级高度，然后更改为v2.0.1.

• 为验证者创建文档以部署和运行 Tendermint ( ) 的密钥管理服务 (KMS)tmkms或节点 ( ) 的多方计算签名服务horcrux。

• 在不保存 的本地副本的情况下清除NEVER 的说明，说明此文件的重要性。一个新的命令被添加到了做安全重置的招标。 unsafe-reset-allpriv_validator_state.json

  • 将验证器密钥迁移指南制作到新机器上，因为这也没有很好的记录。

• 验证器的手动升级和紧急升级文档，以防自动升级无法防止 FUD。

• 确保种子/对等运营商知道在此过程中升级其完整节点

  • 弄清楚如何拥有一个由 CI 或 Discord 机器人针对工作对等点进行测试的对等点列表。

• Genesis JSON 文件在高度 58,699 处导出（即在验证者双重签名之前）或在高度 0 处重新启动链。

• 使用包含附加修复 (TBA) 的新版本重新启动链。

• 创建 Cosmos SDK 链升级操作指南

• 创建内部安全策略

• 为自动升级 (Cosmovisor) 和手动升级创建升级集成和 E2E 测试。

• 在 Tendermint Core 上打开一个改进PR以仅重置数据库，而不是priv_validator_state.json在运行时擦除数据库unsafe-reset-all。

• 事件的验尸文件和补救措施