嘟，嘟，嘟。嘟，嘟，嘟。
史蒂文的睡眠被手机刺耳的铃声打断，将他从梦境中猛然拉回现实。黑暗中，手机屏幕亮得刺眼，在床头柜上剧烈震动。嘟，嘟，嘟。
他呻吟一声，迷迷糊糊地揉了揉眼睛，伸手拿起手机。眯着眼看向消息，心中一沉——节点宕机了。
他毫不犹豫地跳下床，衣衫不整地摸索着解锁手机，而更多的消息不断涌入。就在这时，他猛然意识到——整个集群都宕机了。
就在此刻，地球另一端的不同城市和时区，数百名节点运营者也正盯着手机，意识到他们最害怕的时刻已经到来——一次停机。
引言与所有分布式系统一样，Solana 也面临着这样一个现实：单个实现缺陷或模糊的边缘情况都可能导致全网故障。尽管停机会带来干扰，但这是维护复杂分布式基础设施的必然过程——无论是在去中心化区块链、中心化交易所，还是亚马逊或微软等大型云服务提供商中。
问题不在于故障是否会发生，而在于何时发生，以及网络将如何演变以适应并增强其应对未来事件的能力。尽管进行了严格的模拟测试、激励性测试网以及活跃的漏洞赏金计划，但即使是设计再完善的系统也无法预见每一种可能的故障模式。最宝贵的经验往往来自实际运行中的事件。
在过去五年里，Solana 共经历了七次独立的停机事件，其中五次由客户端漏洞引发，另外两次则是由于网络无法应对大规模交易垃圾邮件。Solana 的早期版本缺乏关键的拥堵管理机制，例如优先费用和本地费用市场，而这些机制后来被证明在缓解网络压力方面至关重要。由于缺乏这些机制，2022 年期间网络频繁出现性能下降和拥堵现象，因为其机制实际上激励了垃圾交易的产生。
Solana 停机与性能下降的历史实例
本文将详细分析每次 Solana 停机事件，探讨根本原因、触发事件以及为解决问题所采取的措施。此外，我们还将讨论网络重启、漏洞报告以及活性与安全性故障等核心概念。尽管这些部分按顺序阅读效果最佳，但每一部分都可以独立阅读，方便读者直接跳转到感兴趣的主题或具体的停机事件。
活性与安全性根据 CAP 定理（亦称 Brewer 定理），分布式系统只能在以下三个特性中实现两个：
一致性 - 每次读取都能看到之前的所有写入。可用性 - 每个请求都会收到响应。分区容错性 - 系统在网络分区的情况下仍能继续运行。
对于区块链而言，分区容错性至关重要，因为网络中断是不可避免的。这迫使系统在 AP（可用性 + 分区容错性）和 CP（一致性 + 分区容错性）之间做出选择。与大多数快速最终性 PoS 链一样，Solana 优先考虑一致性而非可用性，因此属于 CP 系统。在关键故障期间，Solana 会选择暂停运行，而不是提供过期数据或允许不安全的写入。虽然这意味着节点软件可能会进入需要人工干预的不可恢复状态，但它确保了用户资金的安全。
Solana 在 CAP 定理权衡中的定位
活性故障：指区块链停止推进，导致由于验证者宕机、网络分区或共识停滞而无法确认交易或生产区块。在 CAP 定理中，这对应于可用性的丧失。
安全性故障：指区块链的最终状态被篡改或出现不正确的分叉，可能导致历史记录冲突或双花，通常由共识漏洞或恶意攻击引发。在 CAP 定理中，这对应于一致性的丧失。
Solana 优先考虑安全性而非活性。因此，在网络压力过大或共识故障的情况下，Solana 会选择暂停运行，而不是冒着状态被破坏的风险。尽管停机会对应用程序、用户和验证者造成干扰，但相比账本出现不一致或被篡改带来的灾难性后果，这种权衡更为可取。
网络重启重启 Solana 网络涉及识别最后一个经过乐观确认的区块槽位，并从该槽位的受信本地状态快照重新启动节点。由于重启槽位并非通过链上确定，验证者运营者必须在链下达成共识，以确定安全的回滚点。这一协调过程公开进行，地点是在 Solana Tech Discord 的 #mb-validators 频道，专业验证者运营者会在此进行实时沟通。大多数运营者都配备了自动警报系统，可在区块生产停止的瞬间发出通知，确保快速响应。
一旦就正确的重启槽位达成共识，运营者会使用 ledger 工具生成新的本地快照，重新启动验证者，并等待至少 80% 的总质押重新上线。只有在达到这一比例后，网络才会恢复区块生产与验证。在集群重启时，确保离线质押不超过 20%，可为节点在重启后因分叉或再次下线时提供足够的安全余量。
漏洞报告漏洞赏金计划通过奖励安全研究人员来鼓励他们识别并报告软件漏洞。这是一道关键的防线，可主动激励在漏洞被利用之前将其发现。发现 Agave 客户端潜在漏洞的安全研究人员和开发者应通过适当的安全渠道进行报告。详细的披露指南可在 Agave 的 GitHub 仓库中找到。
针对有效的关键漏洞报告，将根据严重程度提供奖励：
资金损失：最高 25,000 SOL共识或安全性违规：最高 12,500 SOL活性或可用性丧失：最高 5,000 SOL
此外，FireDancer 客户端在 Immunefi 平台上设有单独的漏洞赏金计划，对于关键发现，最高奖励为 500,000 USDC。
停机实例以下部分将提供一个详细的时间顺序分析，涵盖自 2020 年 3 月 16 日 Mainnet Beta 启动以来 Solana 的停机事件和性能下降期。此分析将突出关键事件、根本原因以及网络随后的改进，洞察 Solana 如何随着时间的推移不断增强稳定性和韧性。
Turbine 漏洞：2020 年 12 月停机时间：大约六小时
根本问题：区块传播漏洞
修复措施：
通过哈希跟踪区块，而非槽位号修复 Turbine 中可更早进行故障检测的地方通过 gossip 将首次检测到的故障传播给所有验证者
这次停机由一个之前已知的区块修复和代码处理问题引发，该问题是由 Turbine 中未被识别的漏洞触发的。Turbine 是 Solana 的区块传播机制。故障发生时，一个验证者为同一槽位传播了两个不同的区块，并将它们分别传播到两个独立的分区（A 和 B），而第三个分区独立检测到了不一致性。
由于每个分区只持有少数股份，因此没有任何分区能达成超大多数共识来推进链。根本问题源于 Solana 内部数据结构如何跟踪区块及其计算状态。系统使用历史证明（PoH）槽位号（一个 u64 标识符）来引用该槽位的状态和区块。一旦网络分裂为多个分区，节点误将区块 A 和 B 视为相同，从而阻止了区块的正确修复和同步。
每个分区都认为另一个分区持有相同的区块，从而导致了一个根本性的冲突：
持有区块 A 的节点拒绝从区块 B 派生的分叉持有区块 B 的节点拒绝从区块 A 派生的分叉
由于各分区之间的状态转变不同，验证者无法修复或调和这些分叉，进而阻止了最终确定。
解决该问题的修复方案是允许服务通过哈希跟踪区块，而非通过槽位号。如果同一槽位的多个区块创建了分区，它们将与占据不同槽位的区块分区一样处理。这样，节点将能够修复所有可能的分叉，并且共识可以解决这些分区问题。
尽管漏洞是停机的初始原因，但大部分停机时间来自于等待足够的质押权重重新上线，因为 Solana 需要至少 80% 的质押参与才能恢复区块生产。
Grape 协议 IDO：2021 年 9 月停机时间：十七小时
根本问题：由机器人交易引起的内存溢出
修复措施：
忽略程序上的写锁对交易转发进行速率限制可配置的 RPC 重试行为TPU 投票交易优先级
2021 年 9 月 14 日，Solana 在 Grape 协议在众筹平台 Raydium AcceleRaytor 上启动其链上首次 DEX 发行（IDO）后，遭遇了严重的网络停滞。在 IDO 开始后的 12 分钟内，网络被前所未有的机器人驱动交易洪流压垮，导致无法生产根槽。这些机器人有效地发起了分布式拒绝服务（DDoS）攻击，将交易负载推超出网络的承载能力。
在高峰拥堵时：
部分验证者接收到了超过 300,000 笔交易每秒。原始交易数据超过了 1 Gbps，且每秒 120,000 个数据包。流量有时超过了网络接口的物理限制，导致在数据包甚至到达验证者之前，交换机端口就发生了数据包丢失。
2021 年 9 月 14 日 Grape 协议 IDO 停机期间的 Solana 每秒槽数（数据来源：Jump Crypto）
其中一个机器人将其交易结构化为写锁定 18 个关键账户，包括全球 SPL 代币协议和现已停用的 Serum DEX 协议。这导致所有与这些账户交互的交易被阻塞，严重降低了 Solana 的并行处理能力。网络无法独立执行交易，而是必须按顺序处理交易，从而加剧了拥堵。
一种忽略程序写锁的修复方法已开发完成并计划发布。网络重启后，该升级被启用，从而永久消除了这一攻击向量。
在 IDO 期间，验证者接收了大量由机器人驱动的交易，并将多余的交易转发给下一任领导者，进一步加剧了拥堵。网络重启后，引入了交易转发速率限制，以防止未来的交易风暴压垮领导者。
Solana 的 RPC 节点会自动重试失败的交易，这一功能旨在提高可靠性。然而，在极端拥堵情况下，这一重试机制加剧了交易洪流，使旧交易持续循环，阻碍网络恢复。Solana 1.8 版本引入了可配置的 RPC 重试行为，使应用程序能够通过缩短交易过期时间和采用指数退避策略来优化重试。
在严重拥堵情况下，Solana 的领导者未能包含投票交易，而投票交易对维持共识至关重要。由于缺乏已确认的投票，导致共识停滞，阻止了新根块的生成。Solana 客户端的后续版本引入了一种机制，优先处理投票交易，防止其在未来事件中被常规交易淹没。
第二个错误：整数溢出在网络重启过程中，出现了第二个问题。验证者报告活跃质押数量大幅波动。问题源于一个错误：质押百分比被错误地乘以 100，导致数值超出最大允许值。通胀机制生成了过多的 SOL 代币，导致 64 位无符号整数溢出。该错误被迅速识别并在第二次重启前修复。
高拥堵：2022 年 1 月停机时间：无
根本原因：过多重复交易
部分修复措施：
Solana 1.8.12 和 1.8.14 版本发布优化 SigVerify 重复数据消除提升执行器缓存性能
2022 年 1 月 6 日至 1 月 12 日，Solana 主网经历了严重的网络拥堵，导致性能下降和部分故障。此次中断由机器人大量发送重复交易引发，显著降低了网络容量。区块处理时间延长，导致下一个领导者分叉，进一步降低吞吐量。高峰时，交易成功率下降多达 70%。客户端难以处理复杂且高计算量的交易，暴露出其在高需求情况下的性能瓶颈。
1 月 21 日至 23 日，网络出现额外的不稳定性，拥堵持续存在。1 月 22 日，由于被滥用的批量 RPC 调用导致系统过载，公共 RPC 端点 (https://api.mainnet-beta.solana.com) 下线。
为解决这些问题，Solana 1.8.12 版本针对程序缓存耗尽进行了优化，而 1.8.14 版本则提升了 Sysvar 缓存、SigVerify 丢弃机制和 SigVerify 重复数据消除功能。
Candy Machine 垃圾交易：2022 年 4 月/5 月停机时间：8 小时
根本原因：机器人账户发送的垃圾交易
修复措施：
Candy Machine 程序引入机器人税Solana v1.10 内存性能优化
2022 年 4 月 30 日，Solana 遭遇前所未有的交易请求激增。部分节点报告其请求量高达每秒 600 万次，生成的网络流量超过每个节点 100 Gbps。这一激增是由机器人试图通过 Metaplex Candy Machine 程序抢购新铸造的 NFT 导致的。该铸造机制采用先到先得的方式，促使机器人大量发送交易以提高抢购成功率。
2022 年 4 月 30 日/5 月 1 日 Candy Machine 停机事件，每秒数据包输入量（数据来源：Jump Crypto）
随着交易量飙升，验证者内存耗尽并崩溃，最终导致共识停滞。由于投票吞吐量不足，早期区块无法最终确定，导致废弃的分叉无法被清理。因此，验证者因需评估的大量分叉而不堪重负，即使重新启动后仍无法恢复，最终需要人工干预才能恢复网络。
尽管此次停机与 2021 年 9 月的事件有相似之处，但 Solana 展现出更强的抗压能力。尽管交易请求量比上次激增了 10,000%，网络仍能运行更长时间，体现了验证者社区在应对过去扩容挑战后取得的改进成果。
2022 年 4 月 30 日/5 月 1 日 Candy Machine 停机事件，活跃验证者数量（数据来源：Jump Crypto）
在确定规范快照后，网络重启耗时不到 1.5 小时。Solana v1.10 提供了内存使用优化，使节点在共识缓慢或停滞时能维持更长时间。
然而，根本问题仍未解决。Leader 依旧按照“先到先得”原则处理争夺相同账户数据的交易，且缺乏有效的垃圾交易防护，导致用户无法根据交易紧急程度进行优先处理。为此，提出了三种长期机制作为解决方案。
QUIC 协议的采用：Solana 先前使用 UDP（用户数据报协议）通过 Gulf Stream 将 RPC 节点的交易发送至当前 Leader。尽管 UDP 速度快、效率高，但它是无连接协议，缺乏流量控制和接收确认，无法有效防范或减轻滥用行为。为此，验证者的交易接收协议（即 TPU 的 Fetch Stage）被重新设计，采用 QUIC 协议。
QUIC 结合了 TCP 和 UDP 的优点，既能实现类似 UDP 的快速异步通信，又具备 TCP 的安全会话和高级流量控制策略，从而限制单一流量来源，使网络更专注于处理真实交易。此外，QUIC 支持独立的数据流概念，即使一个交易丢失，也不会阻塞其他交易。QUIC 最终集成至 Solana Labs 客户端，并在 1.13.4 版本中发布。
Stake-Weighted Quality of Service (SWQoS)：引入了基于验证者质押权重的网络流量优先机制，确保质押比例更高的验证者能更高效地发送交易。在此机制下，持有总质押量 3% 的验证者可向 Leader 发送最多占总数据包量 3% 的交易。SWQoS 作为一种 Sybil 攻击防护措施，使恶意攻击者更难用低质量交易淹没网络。这一方法取代了此前“先到先得”的模式，后者在接收交易时不区分来源。
引入优先费用：在交易被接收后，仍需竞争访问共享账户数据。此前，这一争夺通过“先到先得”机制解决，用户无法表达交易的紧急性。由于任何人都可提交交易，质押权重并不适用于此阶段的优先排序。为此，Compute Budget 程序新增了一条指令，允许用户指定在交易执行和区块包含时收取的额外费用。交易的执行优先级取决于“费用与计算单位的比率”，从而实现更具动态性和市场驱动的交易排序方式。
Candy Machine 机器人税Metaplex 迅速在 Candy Machine 程序的铸造交易中引入了 0.01 SOL 的硬编码机器人税，以打击由机器人驱动的垃圾交易。这一反垃圾机制通过收取最低费用来阻止恶意活动，同时不会惩罚因操作失误而产生的正常用户。该税收适用于以下特定情况：
尝试在 Candy Machine 尚未开放时进行铸造尝试在库存为空时进行铸造交易中铸造或设置集合指令未作为最终指令使用了错误的集合 ID设置集合指令不匹配集合设置与铸造指令之间的签名者支付者不匹配涉及禁止程序的可疑交易尝试从受 AllowList 保护的 Candy Machine 进行铸造，但未持有所需的 AllowList 代币
这一经济性威慑措施非常有效。Mint 机器人迅速被耗尽，垃圾交易活动停止。在最初几天内，机器人操作者共损失超过 426 SOL。
Durable Nonce 错误：2022年6月停机时间：四个半小时
根本原因：Durable nonce 错误导致共识失败
修复措施：
暂时禁用 durable nonce 交易Solana 1.10.23 更新
一个运行时错误导致某些 durable nonce 交易被处理了两次——一次作为常规交易，另一次作为 nonce 交易——如果它们在 recent_blockhash 字段中使用的是最近的区块哈希，而不是 durable nonce。这导致验证者之间出现非确定性行为，因为有些节点拒绝了第二次执行，而其他节点接受了它。关键的是，由于超过三分之一的验证者接受了该区块，它阻止了所需的三分之二多数达成共识。
与标准交易不同，durable nonce 交易不会过期，需要一个独特的机制来防止双重执行。它们是串行处理的，使用与每个账户绑定的链上 nonce 值，每次处理 durable nonce 交易时都会旋转。一旦旋转，相同的 nonce 交易不应再次有效。
为了解决这一问题，durable nonce 交易被暂时禁用。之后，Solana 1.10.23 更新实施了修复，防止了重复执行，通过将 nonce 和区块哈希域分开来解决此问题。该更新确保在推进 nonce 账户时，区块哈希与固定字符串一起进行哈希，使得区块哈希不能作为 nonce 值。因此，作为常规交易执行的交易不能作为 durable 交易重新执行，反之亦然。此外，新的 DurableNonce 类型替代了 nonce 账户状态中的先前区块哈希值，增加了类型安全性，并防止了类似问题的发生。
阅读我们之前的 Helius 博客文章，了解更多关于 durable nonce 的内容及其用途。
重复区块错误：2022年9月停机时间：八个半小时
根本原因：分叉选择规则中的错误导致共识失败
修复措施：
客户端补丁
此次故障是由于某个验证者错误地在相同区块高度生成了重复区块。原因是该验证者的主节点和备用节点同时激活，使用相同的节点身份但提议了不同的区块。这种情况持续了至少24小时，在此期间，网络能够正确处理验证者的重复领导者槽位。
当网络因分叉选择逻辑中的错误而遇到不可恢复的分叉时，集群最终停止运行。此错误导致区块生产者无法在前一个区块的基础上构建，从而导致共识失败。
在 Solana 网络中，分叉是常见现象，验证者通常通过选择获得大多数投票的分叉（即最重分叉）来解决分叉问题。当验证者选择了错误的分叉时，它必须切换到最重分叉以与网络保持同步。然而，在此次事件中，如果验证者的最后投票槽位与最重银行的槽位一致，则无法恢复到最重银行。此缺陷导致验证者陷入死循环，阻止了共识的推进，并最终导致网络停机。
重复区块错误导致的分叉选择，2022年9月（来源：Laine，Michael Hubbard）
在上述示例中，故障验证者 C 在其领导槽位 5 至 8 生成了重复区块。当验证者 G 接任为下一个领导者时，它仅观察到其中一个重复区块，并相应地扩展其分叉。然而，接下来的领导者验证者 D 检测到来自验证者 C 的两个重复区块，并决定将其丢弃，而是在槽位 4 之上构建自己的分叉。
随着网络运行，验证者 G 构建的分叉获得了大多数质押的投票，确立了其作为规范链的地位。由于意识到自己的分叉正在失败，验证者 D 尝试切换到验证者 G 的分叉。然而，由于分叉选择逻辑中的错误，该切换未能成功。问题的根源在于两个分叉的共同祖先——槽位 5 的重复区块——未被正确处理，导致验证者 D 无法识别大多数分叉。结果，验证者 D 被困在自己的分叉上，无法重新加入主链。
该问题在核心团队的审查后得到解决。修复补丁已合并至主分支，并回溯应用于所有发布分支。
大型区块导致 Turbine 超载，2023年2月停机时间：近19小时
根本原因：分片转发服务中的去重逻辑失效
修复措施：
改进 Turbine 的去重逻辑与过滤机制添加客户端补丁，强制区块生产者在生成大区块时中止
某验证者的自定义分片转发服务发生故障，在其领导槽位期间传输了一个异常庞大的区块（接近15万片分片），其规模远超标准区块。这导致验证者的去重过滤器超载，数据被持续重复转发。随着新区块不断生成，问题进一步加剧，最终导致协议饱和。
大型区块故障，每个区块的分片数量，2023年2月（来源：Laine，Michael Hubbard）
异常的网络流量激增导致 Turbine 超载，被迫通过速度明显较慢的备用 Block Repair 协议传输区块数据。尽管 Turbine 设计用于通过过滤大区块来承受其影响，但分片转发服务位于此过滤逻辑的上游，削弱了其效果。在性能受损期间，区块领导者自动切换至仅投票模式，这是一种安全机制，要求领导者排除经济类的非投票交易。
问题的根本原因是分片转发服务中的去重逻辑失效，未能阻止分片的冗余重传。此外，重传流水线中的去重过滤器最初并未设计用于防止 Turbine 树内部的循环，进一步加剧了问题。
网络通过手动重启并降级至最后已知的稳定验证者软件版本恢复运行。为解决这些问题，Solana v1.13.7 和 v1.14.17 引入了去重逻辑增强，提升了防止过滤器饱和的能力，从而确保网络性能更加稳健。
无限重新编译循环，2024年2月停机时间：近 5 小时
根本原因：JIT 缓存中的错误导致无限重新编译循环
修复措施：
禁用传统加载器 v1.17.20
Agave 验证者在执行引用程序的交易前，会对所有程序进行即时编译 (JIT)。为了优化性能，JIT 会将常用程序的输出缓存，减少不必要的重复编译。作为 Agave v1.16 的一部分，原有的 LoadedPrograms 缓存机制被替换为新的 ExecutorsCache，实现了多项效率提升。
LoadedPrograms 提供了一个全局、支持分叉的程序缓存视图，减少了账务数据的重复，并允许交易执行线程协同加载新程序，防止编译冲突。其关键功能是跟踪程序生效的插槽高度（即有效插槽高度），以便在链上程序数据更新时检测缓存失效。
大多数程序的有效插槽高度来自其部署插槽，并存储在链上账户中。然而，使用传统加载器部署的程序未在其账户中保留部署插槽。为此，LoadedPrograms 将这些程序的有效插槽高度设置为零。
当检测到部署指令，表明程序字节码已被替换时，会触发一个例外情况。此时，LoadedPrograms 会临时插入一个具有正确有效插槽高度的条目。然而，由于交易从未引用过此条目，导致其很容易被驱逐。当条目被驱逐时，JIT 输出被丢弃，程序被标记为卸载，但有效插槽高度仍被保留。
如果随后有交易引用此已卸载程序，LoadedPrograms 会重新编译它并在其有效插槽高度下重新插入条目。通常，这会使程序在下次迭代时可供执行。然而，对于传统加载器程序，新的 JIT 输出会被分配为零这一哨兵插槽高度，导致其排列在先前已卸载条目的后面。结果是，LoadedPrograms 无法识别该程序已被加载，从而在每次迭代时触发持续的重新编译循环。
在 Agave v1.16 中，LoadedPrograms 不支持协作加载，因此触发交易会被打包到一个区块中。此区块随后在整个网络上传播，导致所有验证者重放该区块并陷入相同的无限重新编译循环。由于在故障期间，超过 95% 的网络质押节点运行的是 Agave v1.17，大多数验证者在此区块上陷入停滞，导致网络中断。
该错误在前一周的一次 Devnet 集群故障调查中已被发现，并计划进行修复。@jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">最终的缓解措施是将更改回溯至 Agave v1.17，并在网络重启时立即移除功能门控，从而禁用导致该错误的传统加载器，防止问题再次发生。
协调漏洞补丁，2024年8月停机时间：无
根本问题：ELF 地址对齐假设不正确
修复：
补丁更新
8 月 5 日，Anza 核心工程师收到一名外部研究人员报告的 Agave 客户端漏洞。攻击者可能利用此漏洞导致领导验证者崩溃，从而引发全网停机。对此，Anza 工程师迅速开发了补丁，并经多家第三方安全公司审计。
Solana 程序使用 LLVM 编译为可执行与可链接格式 (ELF)。漏洞源于这些 ELF 文件中地址对齐假设的错误。尽管 ELF 检查通常会强制执行各种完整性验证，但未对 .text 段的对齐进行验证。这一疏忽可能允许恶意构造的 ELF 文件定义错位的 .text 段，导致虚拟机跳转至无效地址，从而引发主机段错误并使验证者崩溃。
攻击者可通过以下方式利用该漏洞：
创建使用 CALL_REG 操作码的恶意 Solana 程序。操纵 ELF 文件使其 .text 段错位。将程序部署并调用于网络上，从而触发验证者崩溃。
补丁更新流程任何公开发布的补丁更新都会立即暴露漏洞，从而可能让攻击者有时间对漏洞进行逆向工程，并在足够数量的验证者完成升级之前导致网络停机。为了避免这种情况，必须尽快让大多数验证者采用补丁版本。
截至 8 月 7 日，Solana 基金会的多名成员已通过各种通信平台的私信联系验证者，告知即将发布的重要补丁，并分享了一条经过哈希处理的信息，以确认事件的日期和唯一标识符。Anza、Jito 和 Solana 基金会的多位知名成员随后在 X、GitHub 和 LinkedIn 上发布了此哈希值，以验证信息的准确性。示例哈希值共享如下：
在接下来的一天里，核心成员继续联系验证者，强调紧迫性和保密性的重要性。按照预定时间，即 8 月 8 日 14:00 UTC，验证者运营商收到了进一步的通知，包含了下载、验证和应用补丁的指令。该补丁托管在一位知名 Anza 工程师的 GitHub 仓库中，而非主 Agave 仓库。指令中还包括了将下载的补丁文件与提供的 shasum 哈希值进行验证的要求。
截至 8 月 8 日 20:00 UTC，持有超级多数权益的验证者已完成补丁更新，确保了网络安全。随后，漏洞及其相关补丁被公开披露，并呼吁所有剩余验证者尽快进行升级。
此次补丁的私下分发以及验证者之间的幕后协调引发了关于 Solana 去中心化性质的担忧。事件发生后不久，Solana 基金会执行董事 Dan Albert 在一次媒体采访中回应了这些批评。
“我认为不能将协调能力与中心化混为一谈。全球有大约 1,500 个区块生产节点，由几乎同样多的个人运营……能够与他们，或部分验证者，自愿地进行沟通，并不等同于中心化。”
2024 年韩国区块链周 (KBW)
“我认为不能将协调能力与中心化混为一谈。全球有大约 1,500 个区块生产节点，由几乎同样多的个人运营……能够与他们，或部分验证者，自愿地进行沟通，并不等同于中心化。”
结论截至目前，Solana 已经超过一年没有发生停机事件，达成了移除“beta”标签并正式从 mainnet-beta 中移除的重要里程碑。随着网络的成熟，停机事件的频率似乎有所下降，而 Firedancer 的引入预计将提升客户端多样性，减少尚未发现的漏洞或边缘情况导致整个集群停机的风险。然而，包括 Helius 创始人 Mert Mumtaz 在内的一些社区领袖预测，停机事件仍将继续发生，时间将证明一切。
感谢 Zantetsu（Shinobi Systems）和 OxIchigo 对本文早期版本的审阅。
声明：
本文转载自[Helius]。所有版权归原作者所有[Lostin]。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。