Solana停机的完整历史：原因与解决方案

Solana故障的完整历史：原因、修复和获得的教训

阅读时间：24分钟

2025年2月23日

嘟，嘟，嘟。嘟，嘟，嘟。

斯蒂文的睡眠被手机的刺耳铃声打断，猛地把他从梦中拉回现实。在黑暗中，屏幕亮起，剧烈振动着放在床头柜上的手机。嘟，嘟，嘟。 他呻吟着，昏昏欲睡地搓着眼睛，伸手去拿手机。眯着眼看着消息，他的心沉了下来——节点宕机了。毫不犹豫，他从床上弹起，半夜穿着衣服，手忙脚乱地解锁手机，更多的消息接踵而至。然后他意识到——整个集群宕机了。

此时此刻，全球不同城市和时区的数百个节点运营商也同样看着手机，意识到同样的事实：他们最不想面对的时刻已经到来了——宕机。

引言

和所有分布式系统一样，Solana在运行中面临单一实现缺陷或模糊边缘情况导致网络整体失败的现实。虽然宕机会带来干扰，但它是维护复杂分布式基础设施不可避免的一部分——无论是在去中心化区块链、中心化交易所，还是在像亚马逊或微软这样的大型云服务提供商中。

问题不在于故障会否发生，而在于何时发生——以及网络如何演变以适应和增强自身，以抵御未来的事件。尽管进行严谨的模拟测试、激励测试网，以及主动的漏洞悬赏计划，但没有任何系统——无论设计多么精良——可以预见到所有可能的故障模式。最宝贵的教训往往源于现实世界的操作。

在过去五年中，Solana经历了七次单独的故障事件，其中五次是由于客户端bug引起的，另外两次是由于网络无法处理大量的交易垃圾。早期版本的Solana缺乏关键的拥塞管理机制，例如优先费用和本地费用市场，这些后来的机制被证明在缓解网络压力方面至关重要。这种机制的缺失导致2022年长时间的性能下降和拥塞，因网络基本激励了垃圾交易。

本文将详细分析每一次Solana故障，检查根本原因、触发事件，以及为解决这些问题所采取的措施。此外，我们还将讨论网络重启、漏洞报告的关键方面，以及活跃性和安全性失败的基本概念。尽管这些部分最好按顺序阅读，但每部分均可独立成篇，使读者能够跳到最感兴趣的话题或故障事件。

活跃性与安全性

根据CAP定理，也称为布鲁尔定理，分布式系统只能达到三种属性中的两种：

• 一致性 – 每次读取都能看到所有先前的写入。
• 可用性 – 每个请求都能获得响应。
• 分区容忍性 – 系统在网络分区的情况下仍能继续运作。

对于区块链来说，分区容忍性是关键——网络中断是不可避免的。这迫使在AP（可用性 + 分区容忍性）和CP（一致性 + 分区容忍性）之间做出选择。像大多数快速最终确定的PoS链，Solana优先考虑一致性而非可用性，使其成为一个CP系统。它在关键故障期间会停止运行，而不是提供过时数据或允许不安全的写入。虽然这意味着节点软件可能进入需要手动干预的不可恢复状态，但它确保用户资金的安全。

活跃性失败：发生在区块链停止进展时，防止交易得到确认和区块的生产，这可能由于验证者的停机、网络分区或共识停滞而导致。在CAP定理中，这对应于可用性丧失。

安全性失败：发生在区块链的最终状态被不当修改或错误分叉时。这可能导致冲突的历史或双重开支，通常由共识bug或恶意攻击引起。在CAP定理中，这对应于一致性丧失。

Solana优先考虑安全性而非活跃性。因此，在极端网络压力或共识失败的情况下，网络将停止运行，而不是冒着状态损坏的风险。虽然宕机会带来干扰并可能影响应用、用户和验证者，但它们比一致性或数据损坏引发的灾难性后果更加可取。

网络重启

重启Solana网络涉及识别最后一个乐观确认的区块槽，并从一个可靠的本地状态快照重启节点。由于重启槽不是在链上确定的，验证者运营商必须离线达成一致，以同意安全回滚点。这种协调在Solana Tech Discord的#mb-validators频道以公开的方式进行，专业的验证者运营商实时沟通。大多数运营商都有自动化警报系统，当区块生产停止时会立即通知他们，确保快速响应。

一旦达成一致的正确重启槽，运营商使用账本工具生成新的本地快照，重启他们的验证者，并等待至少80%的总权益返回在线。只有在这种情况下，网络才能恢复区块生产和验证。确保集群重启时最多返回20%的离线权益，为节点出现分叉或立即再次离线后保持在线提供了足够的安全边际。

漏洞报告

漏洞悬赏计划奖励那些识别和报告软件漏洞的安全研究人员。这是防御的重要一环，因为它主动激励在漏洞被利用之前捕获它们。识别到Agave客户端的潜在漏洞的安全研究人员和开发者被鼓励通过适当的安全渠道进行报告。详细的披露指南可以在Agave GitHub库中找到。

对于有效的关键漏洞报告提供奖励，支付基于其严重性：

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

此外，FireDancer客户端有一个单独的漏洞悬赏计划，通过Immunefi主持，提供最高50万美元USDC的奖励用于关键发现。

故障实例

以下部分提供了对Solana故障和性能下降期间的详细时间顺序分析，从2020年3月16日主网公测版的启动开始。这项审查将突出关键事件、根本原因，以及网络后续改善的情况，提供对Solana在增强稳定性和韧性方面如何发展的深入了解。

Turbine Bug：2020年12月

停机时间：大约六小时

根本问题：区块传播bug

修复：

• 根据哈希跟踪区块，而不是槽号
• 修复Turbine中可以提前进行故障检测的地方
• 通过gossip将首次检测到的故障传播给所有验证者

这次宕机是由之前已知的区块修复和代码处理问题引发的，触发该问题的是Turbine中未识别出的bug，Turbine是Solana的区块传播机制。在一个验证者由于同一个槽传输了两个不同的区块，并将它们传播到两个不同的分区（A和B）的同时，第三个分区独立检测到了不一致，导致了故障的发生。

由于每个分区仅持有少数权益，因此都无法达到超级多数共识来推动链的进展。根本问题源于Solana内部数据结构如何追踪区块及其计算状态。该系统使用历史证明（Proof of History，PoH）槽号（一个u64标识符）来引用该槽的状态和区块。当网络分割成分区后，节点错误地将区块A和B视为相同，从而阻止了正确的修复和区块同步。

每个分区都假设其他分区持有相同的区块，导致了根本冲突：

• 持有区块A的节点拒绝来自区块B的分叉
• 持有区块B的节点拒绝来自区块A的分叉

由于分区之间的状态转换不同，验证者无法修复或调和这些分叉，导致了最终性无法达成。

对此问题的修复措施是允许服务根据哈希跟踪区块，而不是槽号。如果同一个槽的任何数量的区块创建了分区，它们将被视为与占据不同槽的区块没有区别。节点将能够修复所有可能的分叉，并能通过共识解决这些分区。

虽然该bug是导致宕机的直接原因，但大部分停机时间是由于等待足够的权益权重重新上线，因为Solana需要至少80%的权益参与才能恢复区块生产。

The Grape Protocol IDO：2021年9月

停机时间：十七小时

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

修复：

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

2021年9月14日，Solana在Grape Protocol于众筹平台Raydium AcceleRaytor上推出其链上首次DEX发行（IDO）后经历了一次重大网络停滞。在IDO后的12分钟内，网络被前所未有的机器人驱动交易洪流淹没，停止了生成根区块。这些机器人实际上执行了一场分布式拒绝服务（DDoS）攻击，推动交易负载超出网络容量。

在峰值拥塞时：

• 一些验证者每秒接收超过300,000笔交易。
• 原始交易数据超过1 Gbps，每秒达120,000个数据包。
• 流量有时超过网络接口的物理限制，在到达验证者之前就导致了交换机端口的丢包。

其中一个机器人将其交易结构设置为对18个关键账户进行写锁，包括全球SPL代币程序和已经停止服务的Serum DEX程序。这阻止了所有与这些账户交互的交易，严重降低了Solana的并行处理能力。网络没有独立执行交易，反而陷入瓶颈，以顺序处理交易——加剧了拥塞。

修复已开发并计划推出，忽略程序上的写锁。随后，网络重启使此升级得以启用，永久消除了此攻击向量。

在IDO事件中，验证者收到一波波机器人驱动的交易，并进一步将超额交易转发给下一个领导者，甚至加剧了拥塞。网络重启引入了交易转发速率限制，以防止未来的交易风暴使领导者不堪重负。

Solana的RPC节点自动重试失败的交易，这是为了提高可靠性而设计的功能。然而，这一重试机制在极端拥塞情况下加重了交易洪水，使旧交易持续存在，而不是让网络恢复。Solana 1.8引入了可配置的RPC重试行为，使应用能够优化重试，设置更短的过期时间和指数回退策略。

在重度拥塞下，Solana的领导者未能包括投票交易，而投票交易对于维护共识至关重要。结果，缺乏确认的投票导致了共识停滞，停止了新的根区块的生产。Solana客户端的后续版本引入了一种机制来优先处理投票交易，防止它们在未来事件中被常规交易淹没。

第二个bug：整数溢出

在网络重启期间，出现了第二个问题。验证者报告活跃权益数量波动剧烈。该问题源于一个bug，其中权益百分比错误地乘以100，超过了最大可能值。通货膨胀机制创建了如此多的新SOL代币，以至于它溢出了一个64位无符号整数。这个bug在第二次重启之前迅速被识别并修复。

高拥塞：2022年1月

停机时间：无

根本原因：过多的重复交易

部分修复：

• Solana 1.8.12和1.8.14版本
• SigVerify去重优化
• 执行缓存性能改进

在2022年1月6日至1月12日期间，Solana主网经历了严重的网络拥塞，导致性能下降和部分宕机。扰动的驱动因素是机器人频繁发送大量重复交易，显著降低了网络能力。区块的处理时间比预期更长，导致下一个领导者分叉并进一步降低吞吐量。在其峰值时，交易成功率下降了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程序来获取新铸造的NFTs。这个铸造机制是基于先到先得的原则，创造了强烈的经济激励来以交易淹没网络，确保铸造。

随着交易量飙升，验证者的内存耗尽并崩溃，最终导致共识停滞。投票吞吐量不足，阻止了早期区块的最终确认，导致被遗弃的分叉无法清理。结果，验证者被须评估的分叉数淹没，超出其能力范围，即便是在重启后也仍然需要手动干预来恢复网络。

虽然这次宕机与2021年9月的事件相似，但Solana展现了更好的韧性。尽管经历了比上一次宕机多10,000%的交易请求，但网络仍能更长时间地保持运行，反映出验证者社区在应对前一轮扩展挑战上所做的改善。

网络重启后，经过公识快照的达成，重启时间不到1.5小时。Solana v1.10包括内存使用的改进，从而延长节点能够忍受缓慢或停滞共识的时间。

然而，根本性的问题仍未解决。领导者仍然以先到先得的原则处理争夺相同账户数据的交易，没有有效的垃圾交易防范措施，用户无法优先处理交易的紧急性。为此，提出了三种长期机制作为实际解决方案。

采用QUIC ：以前，Solana依赖UDP（用户数据报协议）网络协议通过Gulf Stream将交易从RPC节点发送到当前领导者。虽然速度快且高效，但UDP是无连接的，缺乏流量控制和接收确认。因此，没有有效的方法来阻止或减轻滥用行为。为了控制网络流量，对验证者的交易摄取协议（即TPU的获取阶段）进行了QUIC的重新实现。

QUIC试图提供TCP和UDP的最佳组合。它促进快速异步通信，类似于UDP，但具有TCP的安全会话和高级流控制策略。这使得可以对个别流量来源施加限制，从而允许网络专注于处理真实交易。QUIC还有独立流的概念，因此如果丢失一个交易，它不会阻塞剩余的交易。QUIC最终在1.13.4版本中集成到Solana Labs客户端。

权益加权服务质量（SWQoS） ：这个新系统根据验证者持有的权益优先处理网络流量，确保拥有更高权益的验证者能够更高效地发送交易。在此机制下，持有3%总权益的验证者可以向领导者发送最多3%的总数据包。SWQoS作为一种Sybil抗性措施，使恶意行为者更难通过低质量交易淹没网络。该方法取代了以往完全不区分来源的先到先得模型。

引入优先费用： 交易被引入后，仍然在争夺共享账户数据。以往，这种争夺是在一个简单的先到先得的基础上解决的，用户没有方式来显现自己交易的紧急情况。由于任何人都可以提交交易，因此在这一阶段，权益加权并不适合用于优先处理。为此，计算预算程序中添加了一个新指令，允许用户在执行及区块包含时指定额外收费。费用与计算单位的比例确立了交易的执行优先级，确保更动态，更市场驱动的交易排序方法。

Candy Machine机器人税

Metaplex迅速对与Candy Machine程序交互的铸造交易引入了强制性机器人税0.01 SOL以打击机器人驱动的垃圾交易。这一反垃圾机制施加了最小费用，以威慑恶意活动，而不会惩罚那些意外犯错的合法用户。该税收适用于特定情况，包括：

• 当Candy Machine未上线时试图铸造
• 当没有剩余物品时试图铸造
• 当铸造或设置集合非法指令时
• 使用错误的集合ID
• 集合设置指令的不匹配
• 集合设置与铸造指令之间签名者支付者的不匹配
• 涉及被禁止程序的可疑交易
• 在持有所需的白名单代币时试图从受到白名单保护的Candy Machine铸造

这一经济威慑措施证明非常有效。铸造狙击手迅速失去了资金，垃圾活动也随之停止。在最初的几天中，机器人交易者共损失超过426 SOL。

耐久Nonce Bug：2022年6月

停机时间：四个半小时

根本问题：耐久nonce bug导致共识失败

修复：

• 临时禁用耐久nonce交易
• Solana 1.10.23更新

一个运行时bug允许某些耐久nonce交易被处理两次——一次作为常规交易，另一次作为nonce交易——如果它们在recent_blockhash字段中使用了最近的区块哈希，而不是耐久nonce。这导致验证者之间发生非确定性行为，因为一些节点拒绝第二次执行，而另一些节点则接受它。关键是，因接受了该区块的验证者超过三分之一，因此阻止了所需三分之二多数达成共识。

与标准交易不同，耐久nonce交易不失效，需要一个独特的机制来防止双重执行。它们自动被序列化使用与每个账户关联的链上nonce值处理，该值在处理每个耐久nonce交易时会轮换。一旦被更改，相同的nonce交易就不应该再有效。

为减轻这一问题，临时禁用了耐久nonce交易。@Solana在1.10.23版本中后来实施了修复，防止通过对nonce和区块哈希域进行分离而造成重复执行。该更新确保在向nonce账户推进时，使用固定字符串对区块哈希进行哈希，这使得区块哈希无法作为nonce值使用。其结果是， 已执行一次的交易不能再次被作为耐久交易执行，反之亦然。此外，一个新的DurableNonce类型替代了nonce账户状态中的先前区块哈希值，增强了类型安全并防止在未来造成类似问题。

阅读我们之前的Helius博文以了解更多关于耐久nonce及其用途的信息。

重复块bug：2022年9月

停机时间：八个半小时

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

修复：

• 客户端补丁

这次宕机是由一个验证者错误地在同一个块高度上生成重复块触发的。这是由于验证者的主节点和备用节点同时变为活跃状态，使用相同的节点身份但提出不同的区块。这一状态持续了至少24小时，在此期间，网络能够正确处理验证者的重复领导者槽。

当网络因为分叉选择逻辑中的bug遇到一个不可恢复的分叉时，集群最终停滞。这个bug阻止了区块生成者在之前的区块上构建，从而导致共识失败。

在Solana上，分叉是常见现象，验证者通常通过与大多数投票（最重的分叉）对齐来解决它们。当验证者错误地选择了不正确的分叉，它必须转向最重的分叉以保持与网络同步。然而，在这种情况下，验证者无法恢复到最重的银行，因其槽与他们上次投票的槽匹配。这一缺陷导致验证者停滞，阻止共识进展，最终导致网络停滞。

在上述例子中，错误的验证者C在其领导槽5到8产生了重复块。当验证者G成为下一个领导者时，它只观察到其中一个重复块并相应地延展它的分叉。然而，接下来的领导者，验证者D，从验证者C那里检测到两个重复块，决定丢弃它们，而是建设其在槽4上的分叉。

随着网络的推进，由验证者G构建的分叉获得了大多数权益的投票，确立了其作为规范链的地位。意识到自己的分叉正在失去优势，验证者D试图切换到验证者G的分叉。然而，这一转变因分叉选择逻辑中的bug而失败。这一问题发生在于两个分叉的共同祖先——在槽5处的重复块——未能正确处理，导致验证者D无法识别大多数分叉。因此，验证者D停留在其分叉上，无法重新加入主链。

这一问题在核心团队审核后得到解决。一个补丁被合并到主干并向所有发布分支进行回传。

大块压垮Turbine：2023年2月

停机时间：几乎19小时

根本问题：切片转发服务中的去重逻辑失败

修复：

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

一个验证者的自定义切片转发服务发生故障，在其领导槽期间传输了一个异常庞大的区块（近150,000个切片），其大小是标准区块的若干个数量级，导致验证者的去重过滤器不堪重负，造成数据不断被转发。随着新区块的产生，这一问题加剧，最终使协议饱和。

来自异常网络流量的激增压垮了Turbine，迫使区块数据通过显著较慢的备份区块修复协议进行传输。尽管Turbine旨在通过过滤大型区块来抵御风险，但切片转发服务的工作在这一过滤逻辑上游，降低了其有效性。在性能下降期间，块领导者自动切换到仅投票模式，这是一种安全机制，其中领导者排除经济不投票的交易。

问题的根本原因是切片转发服务中的去重逻辑故障，防止了切片的冗余重发。此外，重发管道中的去重过滤器最初并未设计为防止在Turbine树内循环，这加剧了问题。

该网络由人为方式重启，并降级到上一个已知的稳定验证者软件版本。为减轻这些问题，Solana v1.13.7和v1.14.17引入了对去重逻辑的增强，提高了其防止过滤器饱和的能力并确保更强健的网络性能。

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

停机时间：几乎五小时

根本问题：导致JIT缓存的bug，引发无限重编译循环

修复：

• 禁用遗留加载器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，这导致大多数验证者在这个区块上停滞，停止了网络。

这个bug在上周的Devnet集群宕机调查中被识别，并计划发布补丁。选择的缓解措施是将更改反向移植到Agave v1.17并在网络重启时立即删除特性门。这禁用了承担bug的遗留加载器，从而防止进一步发生。

协调漏洞修复：2024年8月

停机时间：无

根本问题：不正确的ELF地址对齐假设

修复：

• 补丁更新

在8月5日，Anza的核心工程师被外部研究员警告，发现Agave客户端中的一个漏洞，。攻击者有可能利用这一缺陷使领导验证者崩溃，从而导致网络全面暂停。为此，Anza的工程师迅速开发了一个补丁，随后多家第三方安全公司对此进行了审计。

Solana程序使用LLVM编译为可执行和可链接格式（ELF）。该漏洞源于这些生成的ELF文件中的不正确的地址对齐假设。尽管ELF正规化通常强制执行各种完整性检查，但它未能验证.text部分的对齐。这一疏忽可能允许恶意构造的ELF文件定义不对齐的.text部分，导致虚拟机跳转到无效地址，从而导致验证者崩溃。

攻击者可以通过以下方式利用这种漏洞：

• 创建一个恶意Solana程序，使用CALL_REG操作码。
• 操纵ELF文件以导致.text部分不对齐。
• 在网络上部署并调用该程序，触发验证者崩溃。

补丁更新过程

任何公开发布的补丁更新都会立即使漏洞公诸于众。这可能为攻击者提供足够的时间逆向工程漏洞，并在足够的权益尚未升级之前暂停网络。需要尽快确保大量验证者采用任何补丁发布，以避免这种情况。

到8月7日，Solana Foundation的多位成员通过私信在多个沟通平台上联系验证者，告知他们即将到来的关键补丁，并分享了一条哈希信息，以确认事件的日期和唯一标识符。多个知名的Anza、Jito和Solana Foundation成员在X、GitHub和LinkedIn上分享这一哈希以验证消息的准确性。共享实例的哈希：

在接下来的24小时内，核心成员继续与验证者联系，强调紧急性和保密性的重要性。在预定时间，即8月8日UTC下午2点，验证者操作员收到了一条包含下载、验证和应用补丁说明的进一步消息。补丁托管在一位知名Anza工程师的GitHub库上，而非主Agave库中。说明包括对下载的补丁文件进行提供的shasum的验证。

到8月8日UTC下午8点，超多数权益进行了修补，确保了网络的安全。在此之后，漏洞及其对应的补丁被公开披露，呼吁所有剩余的验证者进行升级。

补丁的安静分发和验证者的幕后协调引发了关于Solana去中心化的担忧。在这一事件后，Solana基金会执行董事Dan Albert在媒体采访中回应了这些批评。

“我认为区分去中心化与协调的能力非常重要。全球有1500个产生区块的节点，几乎由数量相等的个人来操作……与他们进行的一些自愿沟通能力并不是去中心化的表现。”

我认为区分去中心化与协调的能力非常重要。全球有1500个产生区块的节点，几乎由数量相等的个人来操作……与他们进行的一些自愿沟通能力并不是去中心化的表现。

Dan Albert

Solana基金会执行董事

结论

截至本文撰写之时，Solana已超过一年没有发生宕机，这标志着其从主网公测版中去掉“测试”标签的重要里程碑。随着网络的成熟，宕机的频率似乎在减少，而Firedancer的推出预计将增强客户端的多样性，降低未知bug或边缘情况导致全集群停机的风险。然而，包括Helius创始人Mert Mumtaz在内的一些社区领袖预测，宕机将会继续存在。未来将证明一切。

非常感谢Zantetsu（Shinobi Systems）和OxIchigo对早期版本的审阅。

进一步资源

• Solana正常运行时间和状态

• 原文链接： helius.dev/blog/solana-o...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～