据 Solana 基金会技术高管 Jacob Creech 称，Solana 在 8 月 12 日经历了一次基础设施故障，该故障暂时中断了其部分验证器网络，但网络仍保持运行。
摘要
- 699 个质押的 Solana 验证器中，有 597 个持续投票，网络继续正常出块。
- 102 个验证器暂时停止投票，受影响的运营商在中断后 40 分钟内恢复。
- 28.83% 的质押 SOL 变为离线状态，接近 33.34% 的阈值，超过该阈值交易最终性将完全停止。
- Teraswitch 表示，一条格式错误的路由中断了欧洲和亚洲的 12 个站点，随后工程师恢复了连接。
- Solana 的状态页面未记录主网事件，并显示 90 天内集群正常运行时间为 100%。
在 699 个质押的 Solana 验证器中，有 597 个继续投票，区块和交易继续处理。受影响的验证器在 40 分钟内恢复。
Creech 表示，Solana 基金会委托计划中的验证器未受影响。Solana 的官方状态页面在 8 月 12 日或 8 月 13 日未记录主网事件，并显示过去 90 天内 Mainnet Beta 集群正常运行时间为 100%。
Solana 验证器保持最终性，尽管大幅下降
虽然主网保持在线，但独立分析显示，该事件对最终性的影响比原始验证器数量所暗示的更接近中断。Marinade Finance 发现，28.83% 的质押 SOL 在约 33 分钟内变为离线状态。Solana 要求超过三分之二的质押参与才能实现交易最终性，因此相关离线阈值为 33.34%。
Marinade 确定了约 90 个受路由故障影响的验证器，而 Creech 的 699 个中的 597 个数字意味着有 102 个验证器在某一时刻未投票。差异反映了不同的测量方法，而非所有 102 个验证器都遭遇了相同的基础设施故障。
Creech 将这一事件描述为“Solana 韧性的证明点”。网络确实承受住了中断，但 Marinade 的数据也显示，离线质押达到了最终性停止水平的约 86%。
Teraswitch 路由故障从迈阿密蔓延至亚洲
Teraswitch 的状态报告将基础设施问题追溯到源自其迈阿密 MIA1 设施的格式错误的默认路由。阿姆斯特丹的路由反射器将更改后的路由传播到欧洲和亚太市场，当地路由器优先选择它而不是有效路由。伦敦、阿姆斯特丹、都柏林、法兰克福、新加坡和东京的 12 个站点失去了可达性。北美站点未受影响。
工程师在 10 分钟内识别出格式错误的路由，并将迈阿密从私有骨干网中移除。服务在 04:16:15 UTC 恢复。Teraswitch 随后在其计算站点部署了全局更改，以便类似格式错误的路由不应阻止流量转发。该提供商表示，潜在缺陷仍在调查中，完整的根本原因报告将随后发布。
该事件还暴露了验证器之间的基础设施集中度。Marinade 计算得出，一个自治系统持有约 1.189 亿 SOL，占所有质押 SOL 的四分之一以上，其中约 94% 的质押同时离线。
Solana避免了2024年网络中断的重演
这一结果与2024年2月网络在区块生产停止后重启的情况形成对比。在那次事件中，验证者需要进行协调重启，Solana离线了近五个小时。而8月12日的基础设施故障并未要求主网重启。
此后，Solana通过独立的验证者软件进一步增强了韧性。在相关报道中，Firedancer于2026年开始在Solana主网生产区块，在占主导地位的Agave生态系统之外增加了另一条验证者客户端路径。
最近的中断测试了另一种去中心化：物理托管和网络连接，而非验证者软件。Solana继续处理交易，但共同基础设施背后的权益集中使得一个提供商的故障能够一次性移除大量投票权益。
接下来会发生什么
Teraswitch的即时配置修复已经部署，但其调查尚未结束。该提供商仍在检查为何迈阿密默认路由被通告了错误的属性，并已联系其硬件供应商。一旦这项工作完成，预计将发布完整报告。
验证者运营商也可能面临对基础设施冗余的更严格审查。Marinade表示，计划审查按自治系统和数据中心划分的集中度限制，并在自动故障转移安排方面提供更多透明度。对于Solana而言，下一个考验是这些基础设施变更能否减少任何单一路由故障所暴露的权益份额。
