Solana 宕机完整历史：原因、修复与经验教训

引言

与所有分布式系统一样，Solana 也必须面对这样的现实：一个实现缺陷或罕见的边缘情况，就可能导致整个网络故障。宕机虽然会造成干扰，却是维护复杂分布式基础设施时不可避免的一部分——无论是去中心化区块链、中心化交易所，还是 Amazon 或 Microsoft 这样的大型云服务提供商。

问题不在于故障是否会发生，而在于何时发生，以及网络将如何演进、适应并增强自身抵御未来事件的能力。即使经过严格的模拟测试、激励测试网和活跃的漏洞赏金计划，也没有任何系统——无论设计多么完善——能够预见所有可能的故障模式。最宝贵的经验来自真实环境中的运行。

过去五年间，Solana 共经历了七次独立的宕机事件，其中五次由客户端漏洞引起，另两次则源于网络无法承受海量垃圾交易。Solana 的早期版本缺少优先费和本地费用市场等关键拥塞管理机制，而这些机制后来被证明对缓解网络压力至关重要。由于缺少这些机制，网络实际上会激励垃圾交易，导致 2022 年长时间处于性能下降和拥塞状态。

本文将详细分析 Solana 的每次宕机，探讨其根本原因、触发事件以及所采取的解决措施。此外，我们还会讨论网络重启、漏洞报告，以及活性故障和安全性故障的基本概念。虽然按顺序阅读效果最佳，但每个章节也可独立阅读，方便读者直接跳转到自己最感兴趣的主题或宕机事件。

活性与安全性

根据 CAP 定理（也称 Brewer 定理），一个分布式系统只能同时实现以下三项特性中的两项：

• 一致性 - 每次读取都能看到此前的所有写入。
• 可用性 - 每个请求都能收到响应。
• 分区容错性 - 即使发生网络分区，系统仍能继续运行。

对于区块链而言，分区容错性必不可少，因为网络中断不可避免。因此，系统必须在 AP（可用性 + 分区容错性）与 CP（一致性 + 分区容错性）之间做出选择。与大多数快速终局的 PoS 链一样，Solana 优先保证一致性而非可用性，因此属于 CP 系统。发生严重故障时，它会停止运行，而不是提供过时数据或允许不安全的写入。虽然这意味着节点软件可能进入无法自行恢复、需要人工干预的状态，但它能确保用户资金安全。

**活性故障：**区块链停止推进，交易无法确认、区块无法生成。原因可能是验证者停机、网络分区或共识停滞。在 CAP 定理的语境下，这对应可用性的丧失。

**安全性故障：**区块链的最终状态被不当修改或分叉。这可能导致历史记录冲突或双花，通常由共识漏洞或恶意攻击造成。在 CAP 定理的语境下，这对应一致性的丧失。 

Solana 将安全性置于活性之上。因此，在网络压力极大或共识失败时，网络会停止运行，而不会冒状态损坏的风险。宕机会干扰应用、用户和验证者，但相比账本不一致或损坏带来的灾难性后果，这仍是更可接受的选择。

网络重启

重启 Solana 网络需要先确定最后一个获得乐观确认的区块 slot，再从该 slot 可信的本地状态快照重启节点。由于重启 slot 并非在链上确定，验证者运营者必须在链下达成共识，选定安全的回滚点。这项协调工作会在 Solana Tech Discord 的 #mb-validators 频道中公开进行，专业验证者运营者会在其中实时沟通。大多数运营者都配置了自动告警系统，区块一停止生成便会立即收到通知，从而快速响应。

就正确的重启 slot 达成共识后，运营者会使用账本工具生成新的本地快照、重启验证者，并等待至少 80% 的总质押重新上线。只有到那时，网络才会恢复区块生成和验证。确保集群重启时离线质押不超过 20%，可以留出足够的安全余量，以防节点在重启后立即分叉或再次离线。

漏洞报告

漏洞赏金计划会奖励发现并报告软件漏洞的安全研究人员。这是一道关键防线，因为它主动激励研究人员在漏洞被利用前发现它们。如果安全研究人员和开发者在 Agave 客户端中发现潜在漏洞，应通过适当的安全渠道进行报告。详细披露准则可在 Agave GitHub 仓库中查看。 

有效的严重漏洞报告可获得奖励，金额取决于严重程度：

• **资金损失：**最高 25,000 SOL
• **共识或安全性违规：**最高 12,500 SOL
• **活性或可用性丧失：**最高 5,000 SOL

此外，FireDancer 客户端还有一个通过 Immunefi 托管的独立漏洞赏金计划，严重漏洞的最高奖励为 500,000 USDC。

宕机事件

以下章节将按时间顺序详细分析 Solana 自 2020 年 3 月 16 日 Mainnet Beta 上线以来的宕机和性能下降时期。我们会重点介绍关键事件、根本原因及网络后续改进，展示 Solana 如何持续演进，逐步提升稳定性和韧性。

Turbine 漏洞：2020 年 12 月

**停机时间：**约六小时

**根本问题：**区块传播漏洞

修复措施： 

• 按哈希而非 slot 编号跟踪区块
• 修复 Turbine 中可提前检测故障的位置
• 通过 gossip 将首个检测到的故障传播给所有验证者

此次宕机源于一个此前已知的区块修复和代码处理问题，触发因素是 Turbine（Solana 的区块传播机制）中一个尚未识别的漏洞。当一个验证者为同一 slot 传输两个不同区块，并分别将其传播到两个独立分区（A 和 B），而第三个分区又独立检测到不一致时，故障随之发生。

由于每个分区都只持有少数质押，任何分区都无法达成超级多数共识来推进区块链。根本问题在于 Solana 内部数据结构跟踪区块及其计算状态的方式。系统使用历史证明（PoH）的 slot 编号（一个 u64 标识符）引用该 slot 的状态和区块。网络分裂为多个分区后，节点误将区块 A 和 B 视为相同区块，导致无法正确修复和同步区块。

每个分区都以为其他分区持有相同的区块，由此产生根本冲突：

• 持有区块 A 的节点拒绝由区块 B 衍生的分叉
• 持有区块 B 的节点拒绝由区块 A 衍生的分叉

由于各分区的状态转换不同，验证者无法修复或协调这些分叉，因而无法实现终局性。

该问题的修复方案是允许服务按哈希而不是 slot 编号跟踪区块。如果同一 slot 中出现任意数量的区块并形成分区，处理方式将与区块位于不同 slot 的分区相同。节点将能修复所有可能的分叉，而共识机制也能解决这些分区。

虽然该漏洞是宕机的最初原因，但大部分停机时间都耗在等待足够的质押权重重新上线，因为 Solana 至少需要 80% 的质押参与才能恢复区块生成。

Grape Protocol IDO：2021 年 9 月

**停机时间：**十七小时 

**根本问题：**机器人交易导致内存溢出

修复措施： 

• 忽略程序上的写锁
• 限制交易转发速率
• 支持配置 RPC 重试行为
• 优先处理 TPU 投票交易

2021 年 9 月 14 日，Grape Protocol 在众筹平台 Raydium AcceleRaytor 上启动链上首次 DEX 发行（IDO）后，Solana 网络发生严重停滞。IDO 开始后不到 12 分钟，前所未有的机器人交易洪流便压垮网络，导致网络停止生成已扎根 slot。这些机器人实际上发起了分布式拒绝服务（DDoS）攻击，使交易负载超出网络容量。

拥塞达到峰值时：

• 部分验证者每秒收到超过 300,000 笔交易。
• 原始交易数据超过 1 Gbps，每秒达到 120,000 个数据包。
• 流量有时会超出网络接口的物理极限，甚至在抵达验证者之前便已在交换机端口发生丢包。

其中一个机器人构造交易，对 18 个关键账户加写锁，包括全局 SPL 代币程序和现已停止运行的 Serum DEX 程序。这阻止了所有与这些账户交互的交易，严重削弱了 Solana 的并行处理能力。网络无法再独立执行交易，而是遇到瓶颈，只能按顺序处理交易，进一步加剧拥塞。

忽略程序写锁的修复方案当时已经开发完成并计划发布。之后的网络重启启用了这项升级，永久消除了这一攻击途径。

IDO 期间，验证者收到大量机器人交易，并将多余交易转发给下一任 leader，进一步放大拥塞。网络重启时加入了交易转发速率限制，防止未来的交易风暴压垮 leader。

Solana 的 RPC 节点会自动重试失败的交易，这项功能原本旨在提高可靠性。然而，在极端拥塞下，这种重试机制加剧了交易洪流，使旧交易持续在网络中流转，阻碍网络恢复。Solana 1.8 引入了可配置的 RPC 重试行为，让应用能够通过更短的过期时间和指数退避策略优化重试。

在严重拥塞期间，Solana leader 未能纳入维持共识所必需的投票交易。由于缺少已确认投票，共识陷入停滞，新根区块停止生成。后续版本的 Solana 客户端引入了优先处理投票交易的机制，避免它们在未来事件中被普通交易淹没。

第二个漏洞：整数溢出

网络重启期间又出现了第二个问题。验证者报告称，活跃质押量出现剧烈波动。问题源自一个漏洞：质押百分比被错误地乘以 100，超出了最大可能值。通胀机制创建了过多的新 SOL 代币，导致 64 位无符号整数溢出。该漏洞很快被发现，并在第二次重启前完成修复。

严重拥塞：2022 年 1 月

**停机时间：**无

**根本原因：**重复交易过多 部分修复措施：

• 发布 Solana 1.8.12 和 1.8.14
• 优化 SigVerify 去重
• 改进执行器缓存性能

2022 年 1 月 6 日至 12 日，Solana 主网出现严重网络拥塞，导致性能下降和局部宕机。中断的原因是机器人发送大量重复交易，显著降低了网络容量。区块处理时间超出预期，导致下一任 leader 产生分叉，吞吐量进一步下降。高峰时期，交易成功率最多下降了 70%。客户端难以处理网络中日益复杂、计算量庞大的交易，暴露出其满足需求方面的局限。

1 月 21 日至 23 日，网络继续拥塞并再次出现不稳定。1 月 22 日，公共 RPC 端点 (https://api.mainnet-beta.solana.com) 因遭到滥用而离线，大量批量 RPC 调用压垮了系统。

为解决这些问题，Solana 1.8.12 版本专门处理了程序缓存耗尽问题，而版本 1.8.14 则改进了 Sysvar 缓存、SigVerify 丢弃和 SigVerify 去重。

Candy Machine 垃圾交易：2022 年 4 月 / 5 月 

**停机时间：**八小时

**根本问题：**机器人账户发送垃圾交易

修复措施：

• 在 Candy Machine 程序中征收机器人税
• 改进 Solana v1.10 的内存使用

2022 年 4 月 30 日，Solana 的交易请求量出现前所未有的激增。部分节点报告每秒收到 600 万次请求，每个节点产生超过 100 Gbps 的流量。这一激增源于机器人试图通过 Metaplex Candy Machine 程序抢购新铸造的 NFT。该铸造机制遵循先到先得原则，形成了强烈的经济激励，促使机器人用交易淹没网络以抢占铸造机会。

随着交易量急剧上升，验证者耗尽内存并崩溃，最终导致共识停滞。投票吞吐量不足使早期区块无法完成最终确认，也使已放弃的分叉无法清理。结果，验证者需要评估的分叉数量过多，即使重启后也超出其处理能力，必须通过人工干预才能恢复网络。

虽然此次宕机与 2021 年 9 月的事件相似，但 Solana 展现出了更强的韧性。尽管交易请求量比上次宕机高出 10,000%，网络仍维持了更长时间的运行，体现了验证者社区针对以往扩展挑战所做的改进。

在就规范快照达成一致后，网络重启用时不到 1.5 小时。Solana v1.10 改进了内存使用，使节点在共识缓慢或停滞时能够坚持更长时间。 

然而，根本问题仍未解决。leader 仍按先到先得原则处理争用相同账户数据的交易，缺乏有效的垃圾交易防护，用户也无法标示交易的紧急程度。为此，社区提出了三项可行的长期解决机制。

采用 QUIC：此前，Solana 依靠 UDP（用户数据报协议）网络协议，通过 Gulf Stream 将交易从 RPC 节点发送给当前 leader。UDP 速度快、效率高，但它是无连接协议，缺少流量控制和接收确认。因此，网络无法有效阻止或缓解滥用行为。为控制网络流量，验证者的交易摄取协议（即 TPU 的 Fetch Stage）改用 QUIC 重新实现。

QUIC 试图兼具 TCP 和 UDP 的优势。它能像 UDP 一样支持快速异步通信，同时具备 TCP 的安全会话和高级流量控制策略。这样便可限制单一流量来源，让网络专注处理真实交易。QUIC 还支持独立 stream，因此即使一笔交易被丢弃，也不会阻塞其余交易。QUIC 最终随 1.13.4 版本集成到 Solana Labs 客户端中。

质押加权服务质量（SWQoS）：网络引入了一个根据验证者所持质押量确定流量优先级的新系统，确保质押量更高的验证者可以更高效地发送交易。在该机制下，持有总质押量 3% 的验证者最多可向 leader 发送数据包总量的 3%。SWQoS 是一种抗女巫攻击措施，可提高恶意行为者通过低质量交易淹没网络的难度。它取代了此前不考虑来源、无差别接收交易的先到先得模式。

引入优先费：交易被摄取后，仍需争用共享账户数据。此前，这种争用采用简单的先到先得原则解决，用户无法标示交易的紧急程度。由于任何人都能提交交易，质押加权不适合这一阶段的优先级排序。为解决此问题，Compute Budget 程序加入了一条新指令，允许用户指定一笔在交易执行并纳入区块时收取的额外费用。费用与计算单元的比率决定交易的执行优先级，从而以更动态、更市场化的方式对交易排序。

Candy Machine 机器人税

为打击机器人垃圾交易，Metaplex 很快对与 Candy Machine 程序交互的铸造交易设置了 0.01 SOL 的硬编码机器人税。这项反垃圾交易机制收取少量费用，以阻止恶意活动，同时不会惩罚无意出错的正常用户。该税费适用于以下特定场景：

• 在 Candy Machine 尚未上线时尝试铸造
• 在所有项目均已铸造后继续尝试铸造
• 铸造或设置集合并非最后一条指令的交易
• 使用错误的集合 ID
• Set Collection 指令不匹配
• 集合设置指令与铸造指令的签名者和付款者不匹配
• 涉及禁用程序的可疑交易
• 在未持有所需 allowlist 代币的情况下，尝试从受 AllowList 保护的 Candy Machine 铸造

这种经济威慑非常有效。抢铸机器人的资金很快被耗尽，垃圾交易也随之停止。仅在最初几天，机器人操作者合计损失就超过 426 SOL。

持久 nonce 漏洞：2022 年 6 月 

**停机时间：**四个半小时

**根本问题：**持久 nonce 漏洞导致共识失败 

修复措施： 

• 暂时禁用持久 nonce 交易
• 更新至 Solana 1.10.23

一个运行时漏洞会导致某些持久 nonce 交易被处理两次：如果它们在 recent_blockhash 字段中使用近期 blockhash 而非持久 nonce，交易会先作为普通交易处理一次，再作为 nonce 交易处理一次。这导致验证者之间出现非确定性行为：一些节点拒绝第二次执行，另一些则接受。更关键的是，由于超过三分之一的验证者接受了该区块，所需的三分之二多数无法达成共识。

与标准交易不同，持久 nonce 交易不会过期，因此需要一种独特机制防止重复执行。它们使用与各账户关联的链上 nonce 值顺序处理；每处理一笔持久 nonce 交易，该值都会轮换。轮换后，同一笔 nonce 交易不应再次有效。

为缓解该问题，持久 nonce 交易被暂时禁用。Solana 1.10.23 随后实施了修复，通过分离 nonce 和 blockhash 域防止重复执行。此次更新确保在推进 nonce 账户时，blockhash 会与一个固定字符串一起进行哈希运算，使 blockhash 无法作为有效 nonce 值。因此，一笔已作为普通交易执行的交易不能再作为持久交易重新执行，反之亦然。此外，新的 DurableNonce 类型取代了 nonce 账户状态中原有的 blockhash 值，增强了类型安全性，并防止未来出现类似问题。

阅读我们此前的 Helius 博客文章，进一步了解持久 nonce 及其用途。

重复区块漏洞：2022 年 9 月

**停机时间：**八个半小时

**根本问题：**分叉选择规则中的漏洞导致共识失败

修复措施： 

• 客户端补丁

此次宕机由一个验证者在同一区块高度错误生成重复区块触发。发生这种情况是因为该验证者的主节点和备用节点同时激活，二者使用相同的节点身份，却提出了不同的区块。宕机前，这种状态至少持续了 24 小时，在此期间，网络一直正确处理该验证者重复的 leader slot。

最终，网络因分叉选择逻辑中的漏洞遇到无法恢复的分叉，导致集群停止运行。该漏洞使区块生产者无法基于前一个区块继续构建，最终导致共识失败。

分叉在 Solana 上很常见，验证者通常会选择获得多数投票的分叉（即最重分叉）来解决。当验证者选错分叉时，必须切换至最重分叉，才能与网络保持同步。然而在此事件中，如果最重 bank 的 slot 与验证者最后投票的 slot 相同，验证者便无法回退到该 bank。这个缺陷导致验证者卡死，共识无法继续推进，最终使网络停止运行。

在上例中，故障验证者 C 在其担任 leader 的 slot 5 至 8 中生成重复区块。当验证者 G 接任下一任 leader 时，它只观察到其中一个重复区块，并相应扩展其分叉。但接下来的 leader——验证者 D——检测到验证者 C 生成的两个重复区块，决定将其丢弃，转而在 slot 4 之上构建自己的分叉。

随着网络继续推进，验证者 G 构建的分叉获得了多数质押的投票，成为规范链。验证者 D 意识到自己的分叉处于劣势，于是尝试切换至验证者 G 的分叉。然而，由于分叉选择逻辑中的漏洞，切换失败。出现该问题是因为两个分叉的共同祖先——slot 5 的重复区块——未得到正确处理，导致验证者 D 无法识别多数分叉。结果，验证者 D 卡在自己的分叉上，无法重新加入主链。

核心团队审查后解决了该问题。补丁已合并至 master 分支，并向后移植到所有发布分支。

大型区块压垮 Turbine：2023 年 2 月

**停机时间：**近 19 小时

**根本问题：**shred 转发服务中的去重逻辑失效

修复措施：

• 对 Turbine 的去重逻辑和过滤机制进行多项改进
• 添加客户端补丁，强制区块生产者在生成大型区块时中止

一个验证者的自定义 shred 转发服务发生故障，在其 leader slot 期间传输了一个异常庞大的区块（接近 150,000 个 shred），比标准区块大几个数量级。这压垮了验证者的去重过滤器，导致数据被不断重复转发。随着新区块继续生成，问题进一步恶化，最终使协议达到饱和。

异常网络流量激增压垮了 Turbine，迫使区块数据通过速度慢得多的备用 Block Repair 协议传输。虽然 Turbine 原本可通过过滤大型区块来抵御它们，但 shred 转发服务位于该过滤逻辑的上游，削弱了过滤效果。在性能下降期间，区块 leader 自动切换至仅投票模式，这是一种安全机制，leader 会排除具有经济意义的非投票交易。

问题的根本原因是 shred 转发服务中的去重逻辑失效，无法阻止 shred 的冗余重传。此外，重传管线中的去重过滤器最初并非用于防止数据在 Turbine 树中循环，进一步加剧了问题。

网络通过降级到最后一个已知稳定的验证者软件版本进行人工重启。为缓解这些问题，Solana v1.13.7 和 v1.14.17 改进了去重逻辑，增强了防止过滤器饱和的能力，并确保网络性能更加稳健。

无限重新编译循环：2024 年 2 月

**停机时间：**近五小时

**根本问题：**漏洞导致 JIT 缓存陷入无限重新编译循环

修复措施： 

• 在 v1.17.20 中禁用旧版 loader

Agave 验证者会先对所有程序进行即时（JIT）编译，再执行引用这些程序的交易。为优化性能，系统会缓存常用程序的 JIT 输出，减少不必要的重新编译。在 Agave v1.16 中，原有缓存机制 LoadedPrograms 被名为 ExecutorsCache 的新实现取代，带来了多项效率提升。

LoadedPrograms 提供支持分叉感知的全局缓存程序视图，减少记账数据重复，并允许交易执行线程协作加载新程序，避免编译冲突。该系统的一项关键功能是跟踪程序开始生效的 slot（称为有效 slot 高度），以便在链上程序数据更新时检测缓存失效。

大多数程序的有效 slot 高度来自部署 slot，该值存储在程序的链上账户中。然而，使用旧版 loader 部署的程序不会在账户中保留部署 slot。作为变通方案，LoadedPrograms 将这些程序的有效 slot 高度设为零。

检测到 deploy 指令时会出现一种例外情况，它表明程序字节码已被替换。此时，LoadedPrograms 会临时插入一条具有正确有效 slot 高度的记录。然而，由于没有交易引用这条记录，它很容易被逐出。记录被逐出时，JIT 输出会被丢弃，程序会被标记为未加载，但有效 slot 高度仍会保留。

如果后续交易引用这个未加载程序，LoadedPrograms 会重新编译它，并在其有效 slot 高度处重新插入记录。通常，这会使程序在下一次迭代中可供执行。但对于旧版 loader 程序，新的 JIT 输出会被赋予值为零的哨兵 slot 高度，因此排在此前的未加载记录之后。结果，LoadedPrograms 始终无法识别程序已加载，并在每次迭代时触发持续的重新编译循环。

在 Agave v1.16 中，LoadedPrograms 不支持协作加载，因此触发问题的交易可被打包进区块。该区块随后传播至整个网络，导致每个验证者重放它并进入相同的无限重新编译循环。宕机时，超过 95% 集群质押运行的是 Agave v1.17，因此大多数验证者都卡在这个区块上，导致网络停止。

此前一周，团队在调查 Devnet 集群宕机时已经发现该漏洞，并计划部署补丁。最终选择的缓解方案是将变更向后移植至 Agave v1.17，并在网络重启时立即移除一项功能门控。这禁用了触发漏洞的旧版 loader，防止问题再次发生。

协调修复漏洞：2024 年 8 月

**停机时间：**无

**根本问题：**错误的 ELF 地址对齐假设

修复措施： 

• 补丁更新 

8 月 5 日，Anza 的核心工程师收到外部研究人员报告的 Agave 客户端漏洞警报。攻击者可能利用该缺陷使 leader 验证者崩溃，进而导致整个网络停止。Anza 的工程师迅速开发了补丁，随后由多家第三方安全公司进行审计。

Solana 程序使用 LLVM 编译为可执行与可链接格式（ELF）。该漏洞源于对这些生成的 ELF 文件中地址对齐方式的错误假设。ELF 清理通常会执行多项完整性检查，但并未验证 .text 节的对齐方式。这一疏漏可能允许恶意构造的 ELF 文件定义未正确对齐的 .text 节，导致虚拟机跳转到无效地址。由此产生的宿主机段错误会使验证者崩溃。

攻击者可能通过以下方式利用该漏洞：

• 创建使用 CALL_REG 操作码的恶意 Solana 程序。
• 操纵 ELF 文件，使 .text 节错位。
• 在网络上部署并调用该程序，触发验证者崩溃。

补丁更新流程

任何公开发布的补丁更新都会立即暴露漏洞。这可能给攻击者留下足够时间逆向分析漏洞，并在足够多质押完成升级前使网络停止。为避免这种情况，必须让达到临界规模的验证者尽快采用补丁版本。

截至 8 月 7 日，Solana Foundation 的多名成员已通过多个通信平台私下联系验证者，告知他们即将发布关键补丁，并分享了一条经过哈希处理的消息，用于确认事件日期和唯一标识符。Anza、Jito 和 Solana Foundation 的多名知名成员在 X、GitHub 和 LinkedIn 上分享了该哈希，以验证消息的真实性。所分享的哈希示例： 

trent.sol

@trentdotsol

07ff4f17c96a632726e209b4afbbcf4e6ba089989cb485b8abbe85da3f558cd9

2024年8月7日 下午2:35

接下来一天，核心成员继续联系验证者，强调时效性和保密性的重要性。在预先确定的时间，即 8 月 8 日 14:00 UTC，验证者运营者收到了另一条消息，其中包含下载、验证和应用补丁的说明。补丁托管在一名已知 Anza 工程师的 Github 仓库中，而非 Agave 主仓库。说明要求使用提供的 shasum 验证下载的补丁文件。

截至 8 月 8 日 20:00 UTC，持有超级多数质押的验证者均已完成修补，网络安全得到保障。随后，漏洞及相应补丁被公开披露，并要求其余所有验证者升级。

补丁的秘密分发以及验证者之间的幕后协调，引发了人们对 Solana 去中心化程度的担忧。事件发生后不久，Solana Foundation 执行董事 Dan Albert 在一次媒体采访中回应了这些批评。

“我认为，重要的是不要把中心化与协调能力混为一谈。全世界有 1,500 个区块生产节点，其运营者人数几乎同样多……能够自愿地与他们或其中一部分人沟通，并不等同于中心化。”

结论

截至本文撰写时，Solana 已连续一年多未发生宕机，达到了从 mainnet-beta 名称中移除“beta”标签的一项关键里程碑。随着网络逐渐成熟，宕机频率似乎正在下降。Firedancer 的引入预计将增强客户端多样性，降低未知漏洞或边缘情况导致整个集群停止运行的风险。不过，包括 Helius 创始人 Mert Mumtaz 在内的一些社区领袖预测，宕机仍会继续发生。时间会给出答案。

衷心感谢 Zantetsu（Shinobi Systems）和 OxIchigo 审阅本文的早期版本。

更多资源

• Solana 运行时间与状态