2024年2月6日，Solana主网因一个bug导致区块最终确认停止，该bug与之前Devnet中断的原因相同，已在v1.17.20版本中修复。bug源于旧版加载程序的部署、清空、请求周期触发了JIT缓存中的无限循环。
时间线
在2024年2月6日09:53 UTC，Solana主网Beta的区块最终确定停止。来自各生态系统团队的工程师立即开始紧急处理该情况，确定原因与最近Devnet停机调查中识别到的一个bug一致，且该bug的补丁将在不久后部署。这个补丁稍作修改，以便在集群重启时立即生效，并切换到包含此更改的v1.17.20版本。与此同时，验证者运营商协调了重启指令，确定246,464,040是启动集群的最高可用乐观确认槽，并准备从该点开始的适当快照。v1.17.20版本的二进制文件和最终的重启指令在UTC时间12:34左右发布。共识进展于UTC时间14:55重新开始，事件总持续时间约为五小时。
根本原因分析
前言
Solana Labs的验证者实现JIT在执行引用到的交易之前编译所有程序。为避免过多的重新编译，频繁使用的程序的JIT输出会被缓存。
历史上，这个缓存是通过 ExecutorsCache 实现的，其结构是从父区块复制到每个新区块，重复了会计信息并导致在任何分叉事件范围内产生额外的重新编译。在v1.16发布分支中，ExecutorsCache 被一个名为 LoadedPrograms 的新实现所替代。
LoadedPrograms 的相关目标是使缓存的程序视图可全局访问和对分叉敏感，减少会计信息的重复，并允许交易执行线程协同加载新程序，防止JIT编译冲突，导致线程互相阻塞进度。分叉感知实现的一部分是跟踪每个程序部署的 有效槽高度（程序变为活动的槽），以检测何时缓存条目因链上程序数据被替换而失效。协同加载策略维护了由另一个程序引用的每个程序的使用统计信息，包括因驱逐或失效而卸载了其JIT输出的程序，以提高驱逐性能。
Bug
对于使用现代加载器部署的程序，LoadedPrograms 可以利用存储在程序的链上账户中的会计信息来查找其最新的部署槽，并用这个信息计算 有效槽高度。然而，对于通过传统加载器部署的程序，部署槽并未在账户中保留，因此 LoadedPrograms 在遇到传统加载器程序时使用零作为哨兵的有效槽高度。当观察到实际的部署指令时，这一规则有例外，表明程序的字节码已被替换。在这种情况下，LoadedPrograms 将相应的条目插入其会计表，并具有 真实的有效槽高度，无论用于部署程序的加载器是什么。然而，由于这一条目从未被交易引用，因此它非常容易被驱逐。当这种情况发生时，JIT输出被丢弃，程序的会计条目则被替换为描述其状态为 卸载的 条目，并 保留有效槽高度。
下次交易引用此程序时，LoadedPrograms 正确要求重新编译，因为其状态为 卸载。当编译完成后，会在程序的有效槽高度插入一个新会计条目。在 LoadedPrograms 的主循环的下一个迭代中，新加载的程序现在可见并返回进行交易执行。然而，在传统加载器程序的情况下，新JIT输出的 插入位于零的哨兵有效槽高度。 这使得它有效地对 LoadedPrograms 隐藏，因为新条目被放置在 卸载 条目之后。因此，每次进入主循环时都会触发对同一程序的重新编译，因为它总是显示为 卸载。 这导致了经典的无限循环。
单独来看，这只足以使执行引用受影响程序的交易的领导者停滞。相应的区块将永远不会广播，触发的交易将不会传播到集群的其余部分。然而，在v1.16中，LoadedPrograms 并未实现协同加载功能，因此未受此退化情况的影响。这允许触发的交易被打包进一个区块，然后分发给其余的验证者，后者在回放过程中触发了无限循环。由于在停机时，超过95%的集群权益运行的是1.17，几乎所有验证者都在此区块上停滞。由于每个人都陷入在重新编译循环中，没人投票，结果共识不可恢复地停止。
修复
这一bug在上周已被识别为Devnet停机的原因。在可能触发该bug的两个传统加载器中，一个（“v1”）已被禁用部署，另一个（“v2”）已被弃用并计划在v1.18发布周期中禁用部署。选择的缓解措施是将v2禁用部署的更改回移到v1.17，并移除功能门，使“v2”在集群重启时立即禁用部署。此修复消除了创建触发该bug所需的前提条件的能力，这是一个更简单的解决方案。一个更完整的修复将包含在对 LoadedPrograms 的进一步改进中，并依赖于常规发布周期进行稳定。
tl;dr
传统加载器程序的部署驱逐请求周期触发了JIT缓存中的无限重新编译循环。
