升级失败暴露了测试和升级过程以及一些内部流程中的缺陷。在上周与验证人讨论的过程后,Cosmos 将采取 5 个措施以降低出现类似问题的可能性。

原文标题:《对 Cosmos Hub 3 升级失败的复盘反思》(Cosmos Hub 3 Upgrade Post-Mortem)
作者:Jack Zampolin,Cosmos 产品总监

在为准备升级的过程中,验证人在 UTC 时间上午 11:39 停止了 Cosmoshub-2。迁移了大约 25 分钟后,多个验证人发现导出的创世文件存在一个问题,该问题是由迁移命令中的 bug 引起的。

这个 bug 使得 Cosmoshub-3 不能按照升级 提案 1 中提供的说明启动。验证人随后按照提案的恢复计划重新启动 Cosmoshub-2,该链在 UTC 时间下午 1:54 恢复运行。此失败升级的总停机时间为 2 小时 15 分钟。

这个 bug 似乎是在 gaia-13004 (v0.34.7)到 gaia-13005 (v1.0.0-rc3)期间被捕获的,但是在 gaia-13005 到 gaia-13006 (v2.0.0)升级期间,有一些对于迁移 逻辑 3 的附加更改没有经过测试。迁移问题 3 已经被 kwun-yeung 修复,SDK 团队正在开发 gaia 版本(v2.0.2),请继续 关注

Cosmos 产品总监:Cosmos Hub 3 升级失败的复盘与应对措施

升级失败暴露了我们的测试和升级过程以及一些内部流程中的缺陷。在上周与验证人讨论的过程中,应采取以下措施以降低出现类似问题的可能性:

1. 应该优先考虑由 Regen Networks 团队(已经与 ICF 签订合同)进行的「自动升级 7」的相关工作,以缓解后续版本的问题(具体 参考)。这种升级方法实现了去中心化网络的完全升级,停机时间不超过 2.5 分钟。相比之下,Cosmoshub-3 升级预计停机 1 小时。

2. 针对每个版本的模拟器,运行主网的完整导出 / 迁移。这是添加到发布过程中的一个简单步骤,本来可以防止出现此问题。

3. 创建允许验证人从主网的克隆中轻松启动测试网的工具。此工具将替换创世文件中的验证人公钥,并允许少量验证人测试针对主网克隆的任何升级 / 迁移。目前有一个社区正致力于推出一个由主网分叉出的带有补丁的测试网。可以进入 电报 5 群 中交流。

4. 改进应急和回滚文档,以确保验证人能够更好地从任何状态恢复。一些大型验证人或 ICF/AiB 可能会在 S3 bucket 中维护 ~/.gaiad/ directories 的最新副本,以帮助验证人在出现故障时快速启动。

5. 未来的升级应该包括「未能启动 1」标准来消除模糊性,具体 参考

一个积极的方面是,这个问题很快被定位,验证人能够重新启动区块链,而不会发生双重签名事件和宕机惩罚。这展示了 Cosmos 验证人们优秀的运维能力,以及他们作为一个团队在紧急状况下的执行能力。在升级失败的混乱中,也有几个验证人设法编写脚本来修复创世文件。感谢来自 StakeWithUs14 的 Oliver,请 参考

值得注意的是:多个渠道之间的沟通分歧是一个有争议的话题。一些人认为这是去中心化和积极的,而另一些人希望所有的沟通都在一个渠道进行。

来源链接:forum.cosmos.network