Metrikaによるこのインシデントの分析によると、8月12日のインシデントでは、ステークされたSOLの約29%を保有する約90のSolanaバリデータが接続を失い、ブロックのファイナライズには通常13秒のところ、最大約30分かかりました。

しかしSolanaは決してダウンしませんでした。ブロックは生成され続け、この日の稼働率チャートは平凡な一日を示していたはずです。10月21日水曜日には、ネットワークがAlpenglowを稼働する予定です。これは約150ミリ秒のファイナリティを目指すアップグレードですが、このニアミスの背景にあるホスティング問題には何も対処していません。FidelityのFCAT部門が10月16日に公開したリサーチレポート「The State of Solana: Network Health and Resilience」では、最大のホスティングネットワークがステークの約29%を占めるとされ、Metrikaがオフラインになったと見た割合に近い水準です。

8月12日に何が起きたのか

Solanaがブロックをファイナライズできる ― つまりトランザクションが不可逆になる時点 ― なのは、ステークされたSOLの3分の2超が投票している間だけです。通常このプロセスには約13秒かかります。8月12日にはステークの約71%が依然オンラインだったため、ネットワークはこのラインを上回り続けましたが、わずかでした。Metrikaはオフライン割合を28.83%としており、ファイナライズがチェーン全体で停止する33.34%の水準と対比しています。

チャート: 8月12日のオフラインになったステークSOLの割合と、ファイナリティ停止ラインの対比。出典：Metrika。

Metrikaによると、影響を受けたルート上のステークがさらに〜5ポイント増えていれば、調整された復旧を必要とするネットワーク全体の停止になっていたといいます。障害はTeraSwitchのマイアミ施設で発生し、ロンドン、アムステルダム、フランクフルト、シンガポール、東京のバリデータインフラに広がりましたが、多くの場合、影響を受けたバリデータのバックアップシステムは起動しませんでした。

TeraSwitchは診断後約10分で障害を修正し、開始から33分後の04:16 UTCまでにトラフィックは再び流れました。バリデータはその後40分かけて回復しました。この間、ブロックを生成しなかったスケジュール済みスロットの割合は1%未満から32%を超えて急増しました。非投票トランザクションの毎秒処理数は約1,100〜1,300から300未満に低下しました。約30分間、ブロックはまったくファイナライズされず、その後バックログは一気に解消され、生成からファイナリティまで平均約1,600秒かかりました。

動かなかった唯一の数字は稼働率で、チェーンがブロック生成を止めなかったため100%を維持しました。しかし約30分間、支払いがいつ不可逆になるかを誰も言えませんでした。デジタル資産リスク管理プラットフォームを販売し、この分析では独自の指標を用いているMetrikaは、Solanaで資金を決済する者にとって重要な出来事として、ダウンタイムではなくファイナリティの遅延を位置付けています。

停止したチェーンが意味するもの、意味しないもの

FCATが説明するリスクは、ファイナリティの停滞と検閲の可能性です。レポートによれば、ステークの3分の1超を保有する連合は、残りがファイナライズに必要な3分の2に達するのを妨げることができますが、ユーザー資産への無制限なコントロールやファイナライズ済みトランザクションを書き換える能力を得ることはありません。同じ割合のステークを失うホスティング障害は、誰も攻撃していなくてもファイナリティを停止させます。

その割合は到達が難しいものではありません。FCATはステークの3分の1超を保有する約20のバリデータID(別の箇所では18)を数えており、その3分の1が2カ国、2つのホスティングネットワーク、2つのベースクライアント実装上にあると述べています。これらは独立した組織ではなく投票アカウントです。たとえばFigmentはこのグループの上位5バリデータのうち2つを運営しています。FCATの全体的な評価は肯定的で、2年超にわたるメインネットの重大な障害なしの記録、2026年の投票成功率平均約99.7%、そして徐々に多様化しているソフトウェアスタックを挙げています。注視すべき点として集中を挙げています。FCATはFidelityの応用技術研究部門であり、独自の小規模なSolanaバリデータも運営しています。

2カ月経っても、割合は約29%のまま

FCATの10月のスナップショットでは、最大のホスティングネットワークがステークの約29%を占めています。2つの数字は異なるもの ― 障害時のオフラインステークと、ネットワークの全ステークに占める割合 ― を測定していますが、同じ場所に着地します。FCATは、Solana FoundationがすでにTeraSwitchの支配力を減らす取り組みを進めていたと述べています。バリデータを運営する人々からそのコードまで、数字の内訳は以下の通りです:

• 18〜20の運営者 ― ステークの3分の1超を保有するバリデータID。これらは独立した組織ではなく投票アカウントであり、Figmentはこのグループの上位5のうち2つを運営しています。
• 約40%のロケーション ― フランクフルトとアムステルダムにあるステークの割合。これはFCATが不正確な可能性があるとするIP位置情報の推定であり、約59%がドイツ、オランダ、米国にあります。
• 約29%のネットワークプロバイダー ― 10月のスナップショットでの、1つのホスティングネットワーク上のステークの割合。異なる都市のバリデータが同じプロバイダーを共有したり、同じ都市のバリデータが異なるプロバイダーを使うこともあります。
• 約63%のソフトウェア ― 第3四半期にJitoベースのソフトウェアを実行していたステークの割合で、さらに26%がHarmonicを実行していました。ほとんどの構成は依然として基盤でAgaveコードを共有しているため、そこで1つのバグが発生すれば同時に影響を受ける可能性があります。

出典：FCAT、The State of Solana: Network Health and Resilience(2026年10月)。

バリデータが集中するのには理由があります。レイテンシは他のノードの近くにいることに対して報酬を与えるとFCATは指摘し、TeraSwitchやLatitudeのような専門ホストはSolanaのワークロード向けにハードウェアを構築しています。運営者にはフェイルオーバー、予備電源、公衆インターネットへの依存を減らすDoubleZeroなどのプライベートネットワークといった保護手段があります。Foundationも2026年初頭にインシデント対応ネットワークSIRNを設立しました。しかし8月12日には、ほとんどのバックアップが起動しませんでした。

Foundationの制限が届くのはステークの約4%

Solana Foundationの委任プログラムが主なルールを定めています。2026年5月1日以降、Foundationのステークを得たいバリデータは、25%上限未満のホスティングネットワーク上、かつ15%未満のデータセンターに置かれる必要があります。基準を満たせないバリデータは、再び合格するまでFoundationの委任を失います。

この制限は8月の障害の3カ月前に発効しましたが、FCATの10月のスナップショットでは最大のネットワークは依然として上限を超えていました。プログラムの及ぶ範囲が問題のもう半分です。第3四半期時点でバリデータの約51%に委任していましたが、それらの委任はアクティブステークの約4%にすぎませんでした。このルールはバリデータに多様化する理由を与えますが、残りのステークを管理するものではありません。

FCATの10月のデータでは、最大のホスティングネットワークはステークの約29%を占め、Foundationの25%上限を超えています。一方、Foundationのプログラムが委任したのは、第3四半期時点でアクティブステークの約4%でした。

Alpenglowが修正するもの、しないもの

Alpenglowはエポック1064でメインネットに導入されます。Solanaは10月21日水曜日の15:00 UTC頃に開始するとし、Agaveクライアントの開発チームであるAnzaは14:50頃としています。旧投票システムは最初の5,000スロット(約18分)稼働し続け、新しいシステムがスロット459,653,000で引き継ぎます。ファイナリティは約12.8秒から約150ミリ秒に短縮される予定で、Solanaはこの数字を定数ではなく期待値と説明しています。ウォレットやアプリは今日と同じように動作し続けます。

アップグレードはホスティング問題には何もしません。より速い投票は合意にかかる時間を短縮しますが、Solのアップグレードページには、バリデータがどこで稼働するか、どのプロバイダーが接続するかを変える内容はありません。

現時点ではソフトウェアの多様性も狭めます。バリデータはAgave 4.3.0ベースのリリース上で、Agave、Jito-Solana、またはHarmonic Salsaを実行する必要があります。移行期間中はFiredancerとFrankendancerがサポートされず、Solanaのページには対応時期の日付が示されていません。Firedancerは、FCATが独立したクライアント多様性に向けたSolanaの最も重要な動きと呼ぶ独立コードベースです。バリデータはまた、投票アカウントにレント免除最小額を上回る少なくとも0.8 SOLを保有していなければ、次のエポックで投票もブロック生成もできません。

• 移行前 ― 現在から10月21日の14:50〜15:00 UTC頃まで: FiredancerとFrankendancerの運営者はAgaveベースのクライアントに移行し、すべての投票バリデータは投票アカウントにレント免除額を超える0.8 SOLを保有します。
• 切替時 ― エポック1064の開始: 旧投票システムは最初の5,000スロット(約18分)稼働し、Alpenglowがスロット459,653,000で引き継ぎます。
• 移行後 ― データ面での変更: 投票トランザクションがブロックから外れるためトランザクション数は減少し、confirmedとfinalizedが同じ状態になり、参加データはブロックフッターの証明書に移行します。

監視も変わります。Metrikaの分析では、投票はブロックに含まれる通常のトランザクションであるため、ブロックあたりの投票数をネットワークがファイナリティラインにどれだけ近いかを示す最も良い指標として扱っています。Alpenglowは投票をブロックから外すため、Solanaの移行ノートによれば、投票トランザクションを解析してバリデータの参加を測るものはすべて、そのデータがブロックフッターの証明書に移るため、新しいデータソースを必要とします。報告されるトランザクション数も、実際の活動が減らなくても減少します。

今週確認すべきこと

SOLをステークする場合: 委任する前に、バリデータがどこでホストされているかを確認してください。FCATとFoundationの双方が使用するValidators.appは、ホスティングネットワークとデータセンター別のステークを追跡しています。最大のネットワーク上のバリデータは8月と同じリスクを抱えています。

Solana上で開発する場合: 水曜日には、実際の活動が変わらなくてもトランザクション数とTPSのダッシュボードが下がることを想定してください。Solanaの移行ノートの助言に従い、Alpenglowが稼働するまではconfirmedを読み続け、その後finalizedに移行してください。稼働前は、finalizedでも約12.8秒の待ち時間が発生します。その遅延に合わせて調整されたタイムアウトやリトライロジックを再確認し、稼働率と併せてファイナリティまでの時間も追跡してください。

バリデータを運営する場合: FiredancerまたはFrankendancerを使用している場合は、エポック1064の前にAgaveベースのクライアント切り替え、投票アカウントが0.8 SOLを保有していることを確認してください。

水曜日以降、注目すべき2つの数字があります。最大のホスティングネットワークの割合がFoundationの25%上限を下回るかどうか、そしてFiredancerがいつ再びサポートされるかです。どちらも水曜日のスケジュールには載っていません。

本記事は情報提供のみを目的としたものであり、金融または投資助言を構成するものではありません。