回顾FIL链上中断事件解决及后续|狸猫云算

[复制链接]
7160 |0
发表于 2021-1-26 16:01:52 | 显示全部楼层 |阅读模式

2020年12月19日,FIL网络发生了链上间断,这代表着在一个时间窗口内可以创建新的区块,但矿工们没法就新块达成共识,因为每个人计算的数值都有所不同。得益于整个社区组员、矿工和开发者的快速响应——在4个小时内发布了一个修复方案,之后网络在7小时内实现了恢复正常。本文简单介绍了本次事件遇到的问题、间断带来不良影响、快速响应以及下一步的工作。


故障原因


故障发生的根本问题是对存储矿工参与者实施方案中的对象映射进行潜在非确定性的迭代。参与者是在Go中进行的。对Go的映射进行遍历是已知具有不确定性的,参与者使用一种模式,即在进行迭代对迭代结果总是进行排序。不幸的是,在对2个这样的映射进行排序时使用的比较函数发生了错误,造成 排序无效。因此,不同的网络节点以不同的顺序处理映射条目,造成 了不同的结果和Gas消耗量。


这一代码路径事实上只有根据下列方式才能够实现:


(a)单个矿工声明同时终止多个扇区;


(b)单个矿工同时恢复多个分区的故障。


在这一点之前,这两种路径都没有在主网中实践过以多个扇区/分区作为数据来暴露非确定性。间断是由多个扇区同时终止引发的。


带来的不良影响


最重要的是,在间断期间没有丢失任何数据。虽说没法挖出新块且暂时中止了网络上的交易,但一旦网络恢复运行,所有存放在存储提供者处的数据都是安全的且可以随时使用。此外,要注意到的是FIL协议的规范规定,即使在链上间断的情况下也是可以检索数据。因此,虽说在事件发生期间没法进行链上交易,但FIL网络的核心功能仍然完好。此外,所采取的修复措施保证了挖矿业务本身不会因间断而受到惩罚;相反,惩罚被暂时中止以优先考虑并鼓励网络恢复。


快速响应


发现问题、确认问题、修复故障和重新部署的速度十分迅速:


事件发生15分钟内,自动监测触发警报;


30分钟内,矿工和实施方案开发者应声汇合开始解决问题


4个小时内,开发者确认并发布故障修复方案


7小时内,足够多的网络节点采用了该修复方案并根据多数共识算力使网络恢复正常


相对于一个年轻的分布式网络而言,这是一个让人不敢相信的快速响应。即便 是成熟的区块链也常常会遇到链上中断和分叉的状况,FIL处理此次事件的时间与已经运行了几年的链差不了多少。整个社区应该为此次事件的响应速度感到骄傲。


只有通过全球各地的多个团队协同工作和共同努力,才有可能完成故障的修复。整个生态中的各方合作共同完成了这一目标:矿工们发现并报告了这一问题,并提请开发者注意;工程团队协调开发并发布了一个经过同行评审的补丁包,以处理根本问题,另外通过社区渠道沟通这一修复的情况;全球各地的网络参与者开始应用该补丁包,并尽早使网络重新上线。虽然希望此类紧急的事件不会反复发生,但FIL生态内参与和关注度给人们带来了深刻的印象。


接下来的工作


构建区块链就像构建火箭一样,是非常复杂的技术,很难在第一次尝试时就把所有事情都做得完美。就像真正的火箭一样,事情可能会以意想不到的方式出错;当这种状况发生时,重要的是要有基础设施来尽早处理这个问题,将其影响降到最低,并减少再次发生的可能性。


为此,多个团队已着手编写和执行事后分析,以确定对参与者/lotus的测试覆盖率以及对网络基础设施/通信的警报和问题升级的额外改进,来帮助减少未来的这种状况的发生。


感谢FIL社区的耐心、辛勤工作和投入,使这一项新技术中的问题不断被处理。随着每一个问题的发现和处理,网络进一步成熟并成为稳定、可靠和经受过考验的平台。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表