2020年12月19日，Filecoin网络经历了链上中断，这意味着可以在一段时间内创建新的区块，但矿工无法就产生的状态达成共识，每个区块计算出不同的价值。由于社区成员，矿工和开发人员之间的快速响应——修复程序在四个小时内发布，并且网络在七个小时内实现了完全恢复。
潜在的问题是对存储矿工参与者实现中的对象映射进行潜在的不确定性迭代。参与者在Go中实现。众所周知，对Go映射的迭代是不确定的。
参与者在使用迭代之前总是对迭代的结果进行排序（强制执行静态分析）。不幸的是，在对两个这样的映射进行排序时使用的比较函数中若出现错误，将导致排序无效（请参阅＃1335）。因此，不同节点处理map条目的顺序不同，从而导致结果和Gas消耗的不同。
该代码路径实际上只有通过（a）一个矿工声明多个扇区立即终止，或（b）一个矿工立即恢复跨越多个分区的故障，才能到达此代码路径。（其他两个代码路径到了这一点，但实际上极不可能）。在此之前，主网中都没有使用这两种路径，没有将多个扇区/分区作为暴露非确定性的数据。多个部门的同时终止引发了这一停顿。
最重要的是，应该强调的是，在中断期间没有丢失任何数据。虽然无法创建新的区块，暂时抑制了网络上的交易，但存储供应商提供的所有数据都是安全的，并且一旦网络恢复运行，就可以使用。此外，值得注意的是，即使在链中断的情况下，Filecoin协议的规范也提供了数据检索。换句话说也就是：在事件持续时间内不可能进行链上交易，但Filecoin网络的核心功能仍保持不变。
首次发现，识别，修复和部署基本问题的速度也很明显：
1、事件发生后十五分钟内，自动监控触发了警报
2、在三十分钟内，矿工和实施开发人员聚集一起进行响应
3、在四个小时内，开发人员确定并发布了此问题的修复程序
4、在七个小时之内，足够多的节点采用了此修复程序，以超过多数共识的功率阈值，使网络处于恢复的道路上
对于年轻的去中心化网络而言，这是一个令人难以置信的快速反应。即使建立的区块链经历链暂停和分叉，Filecoin解决这一事件的时间可以与已经运行多年的区块链相媲美。整个社会应该为这一事件处理的速度感到骄傲。
建立区块链就像建造火箭一样，将融合着许多复杂的技术，因此很难在第一次尝试中就将所有事情都做好。就像真正的火箭一样，突发事件很难预料。当发生这种情况时，重要的是要有适当的基础架构以尽快解决问题，最大程度地减少影响并减少再次发生问题的可能性。
为了达到这个目的，多个团队进行了事后验收的编写和执行，确定了对参与者/角色的测试覆盖范围以及网络基础设施/通信的警报和问题升级的其他改进，以帮助减轻未来的事件。
在Filecoin整个社区的协同努力下，不断完善这种新的技术，我们相信，在整个网络将会在发现问题与解决问题中不断提升，最终将形成一个稳定、可靠的“可发射升空”的平台。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
