Basilisk 宕机事故回顾

最近一周，Basilisk 升级时发生了严重的宕机事故：已在 Rococo 网络测试成功的v12.0.1版本，在与主网合并时，出现了区块停顿（11月7日停止于#2145599区块）。事故发生后，团队随即向Kusama 议会发起了升级申请。Kusama议会立刻发起了关于升级的动议，并在一天多时间内完成了议会成员投票。在各方强烈呼吁下，Kusama议会同意Basilisk升级提案投票，走快速通道，具体请看：https://kusama.polkassembly.io/referendum/245。

今天凌晨3点，在宕机8天后恢复，Basilisk网络开始重新生成区块。现在，除了交易和添加流动性功能在24小时后恢复外，Basilisk网络的其余功能均已正常。

这次事故，波哥认为主要源于Rococo网络和Kusama主网的不同步升级（可能理解不准确）。也就是说，当Basilisk-v12.0.1在尚未升级的Rococo网络上测试时，Kusama主网刚好完成了升级，而经Rococo测试成功的Basilisk升级版本与Kusama主网合并时，就出现了参数冲突，从而引发区块中断（事故发生具体过程请查阅JakubPanik 的博客：https://jakpan.hashnode.dev/snek-stall-post-mortem）。

更让人头疼的是，一旦平行链升级失败，按照目前的治理流程，重启升级需经过Kusama投票程序后方能进行。这个过程通常是比较漫长的，据说提案完全通过，一般需要数周时间。尽管在各方努力下，这次宕机仅持续了8天时间，但即便如此，对于像Basilisk这样的区块链项目，仍然非常不幸的。

万事皆有两面性。本次事故发生在市场普遍低迷时，并未造成非常严重的后果（已为流动性提供者预留了24小时撤出流动的时间），这也算是不幸中的万幸。

Basilisk这次宕机，也在Kusama议会产生了较大震动。目前的治理结构，各个平行链如同一个个“藩属国”，平时可就一些事项，通过小打小闹地投票自行决定。可是，一旦出现“决定生死”的关键事项（比如这次升级失败的重启），仍需Kusama这个“宗主国”发话。这显然是一种非常不合理的治理方式。据说Kusama已开始着手改进流程，这也算Snek对完善Kusama生态功能的一个贡献。

对于Snek团队而言，这次升级，尽管也按照常规进行了程序测试和验证，但做得显然还不够，团队需进一步完善预警机制。据了解，团队已开始着手研究新的预警程序，以避免类似事件再次发生。好在万能池Omnipool尚未发布，本次宕机事故，无疑会对其日后稳定运行提供了一次很好的警示，团队应该从中吸取了足够的教训，从这个角度看，又不失为另外一种幸运。若如此，这或许是从Snek本次宕机事故中得到的最大收获吧！

个人观点，仅供参考！