← 観測ノート一覧

OBSERVATION NOTE / MDFOOB-HU

Solana約29%ステーク一時オフライン――停止寸前報道とインフラ集中リスクの解説

Solanaの約28.83%のステークが一時オフラインとなった事例を、finality閾値、障害ドメイン、インフラ集中、Cardanoとの違いから整理します。

1. 結論

今回のSolanaの事象は、Solanaプロトコルそのもののバグによる停止ではなく、ネットワーク・インフラの集中によって「約1/3のステークがオフラインになるとfinalityが維持できなくなる境界」にかなり近づいたインシデントと理解するのが適切です。

報道およびMarinade Financeの分析では、約28.83%のステークが一時オフラインになりました。

Solanaでfinality維持が困難になる境界は約33.34%のステーク離脱なので、差は約4.51ポイントでした。言い換えると、今回の障害はfinality停止閾値まで約86%の地点に達していたことになります。

一方で、

  • ブロック生成は継続
  • トランザクション処理も継続
  • finalityも維持

されており、Solanaのチェーン停止(outage)そのものではありませんでした。

したがって、

「Solanaは停止寸前まで近づいた」

というMarinade側の警告と、

「ネットワークはストレス下でも停止しなかった」

というSolana Foundation側の説明は、必ずしも矛盾しません。


2. 何が起きたのか

報道では、原因はSolanaのコンセンサスコードではなく、主要インフラ事業者TeraSwitchに関連するルーティング障害とされています。

TeraSwitchのMiami拠点から誤ったdefault routeが伝播し、Amsterdam側のroute reflectorを介して欧州・アジア太平洋へ影響が拡大したと報じられています。

London、Amsterdam、Dublin、Frankfurt、Singapore、Tokyoなど複数拠点で有効なネットワーク経路が失われ、そこに接続していたvalidatorがネットワークから切り離されました。

概念的には以下のようになります。

TeraSwitch Miami
      │
      │ 誤ったdefault route
      ↓
Amsterdam
      │
      ├─ London
      ├─ Frankfurt
      ├─ Dublin
      ├─ Singapore
      └─ Tokyo
             ↓
      Validator接続断
             ↓
   約28.83% stake offline

つまり、Solanaそのものが壊れたというより、Solana validatorを支えるInternet/hosting layerで大規模な相関障害が発生したということです。


3. なぜ約29%のオフラインが重大なのか

PoSネットワークでは、単純なvalidator台数だけではなく、各validatorが代表するstake weightが重要です。

Solanaでは約1/3を超えるstakeが投票不能になると、ネットワークのfinality形成が困難になります。

オフラインstake状態の概念
5%通常は大きな問題にならない
15%劣化するがネットワーク継続可能
28.83%今回。finality停止境界にかなり近い
約33.34%finality停止の重要境界
>33.34%finalize不能となるリスク

今回の28.83%は、33.34%という閾値に対して約86%まで到達した計算になります。

したがって、Marinade Financeが重大なnear missとして扱ったことには技術的な根拠があります。


4. それでもSolana Foundationが「耐えた」と評価する理由

Solana Foundation側は、障害中もネットワークが実際には動き続けたことを重視しています。

報道されたFoundation幹部の説明では、

  • 699 staking validatorsのうち597が投票を継続
  • およそ6/7のvalidatorが稼働
  • block production継続
  • transaction処理継続
  • validatorは比較的短時間で復旧

とされています。

評価軸を整理すると以下のようになります。

Marinade側の視点Solana Foundation側の視点
あと約4.51ポイントで重要閾値だった実際には閾値を超えなかった
infrastructure concentrationが危険provider障害をネットワークが吸収した
約29%の同時離脱は重大な警告約71%のstakeが残り稼働した
near missresilience testを耐えた

この2つは同時に成立します。

航空機で例えるなら、

「重大なシステム障害が発生した」

ことと、

「冗長系が機能し、飛行そのものは継続できた」

ことは両立します。


5. 最重要ポイント――validator数ではなく「障害ドメイン」

今回の事件から最も重要な教訓の一つは、validator数だけでは分散性を正しく測れないことです。

Marinadeの分析として報じられた数字では、AS20326という単一Autonomous Systemに全stakeの約27.34%が集中し、その大部分が同時にオフラインになったとされています。

概念的には、

Validator A ─┐
Validator B ─┤
Validator C ─┤
Validator D ─┼→ 同じAS / network infrastructure
Validator E ─┤
Validator F ─┘

という構造です。

validatorが6台あっても、同じAS、同じhosting provider、同じdata center、同じupstream networkなどに依存していれば、物理インフラの観点では一つのfailure domainとして同時に失われる可能性があります。

つまり、

論理的なvalidator分散 ≠ 物理的なインフラ分散

です。


6. ホスティング事業者が別でも安全とは限らない

報道ではTeraSwitch以外の一部インフラでも同じ時間帯にstakeのオフラインが観測されたとされています。

ただし、そのすべてが同じ障害原因だったかどうかは公開情報だけでは確定できません。

ここで重要なのは、

「hosting providerが違うから独立した障害ドメインである」

とは限らないことです。

例えば、

Data Center A ─┐
Data Center B ─┤
Cloud C       ─┼→ 共通ISP / AS / IX / upstream
Cloud D       ─┘

なら、表面的には異なる事業者でも下位のネットワーク経路を共有している可能性があります。

したがって、ブロックチェーンの分散性評価は今後、

  1. validator
  2. hosting provider
  3. data center
  4. Autonomous System(AS)
  5. upstream network
  6. geographic region
  7. software client

という複数階層で見る必要があります。


7. 今回はどれくらい危なかったのか

単純化すると次の位置関係です。

正常                    今回                 Finality停止境界
0%                    28.83%                    33.34%
│──────────────────────●────│
                          ↑
                       約4.51pt

実際の経済的損失より重要なのは、

単一または相関したネットワーク・インフラ障害によって、全stakeの約29%が短時間に同時離脱し得た

という構造的事実です。

これはSolanaのコンセンサス・アルゴリズムそのものの欠陥を意味しません。

むしろ、コンセンサス層より下にある物理ネットワーク層の集中リスクを示しています。


8. Solanaにとって悪材料なのか

CGTAの評価では、短期的には中立〜ややポジティブ、長期的には重要な警告材料です。

評価項目CGTA評価
コンセンサス耐障害性★★★★☆
Validator多様性★★★★☆
Hosting分散★★☆☆☆
AS/network分散★★☆☆☆
障害復旧★★★★☆
今回の直接的実害★★★★★(軽微)
潜在的tail risk★★☆☆☆

ポジティブな面は、これだけ大きなstake離脱でも実際にネットワークが停止しなかったことです。

これはSolanaにとって実地の耐障害性試験を通過した実績になります。

一方で、

「単一または相関するネットワーク障害によって、1/3 thresholdのかなり近くまでstakeを失い得る」

という構造が露呈したことは無視できません。


9. Cardanoとの比較

今回の事象は、ブロックチェーンの「性能」と「ノード運用コスト」と「物理的分散性」の関係を考える上でも重要です。

非常に単純化すると、SolanaとCardanoには次のような設計思想の違いがあります。

項目SolanaCardano
基本的な方向性高性能L1分散性・堅牢性を重視
Validator/SPO要求比較的高い比較的低い
Data center依存高くなりやすい相対的に低くしやすい
ネットワーク帯域要求高い相対的に低い
infrastructure concentration risk今回顕在化相対的に抑えやすい
現状throughput非常に高い相対的に低い
スケーリング方向Firedancer、ネットワーク高速化などLeiosなど

Solanaは高いthroughputを実現するため、validator側にも高性能CPU、メモリ、network bandwidthなどを要求します。

そのため一般論として、

性能要求↑
   ↓
validatorハードウェア要求↑
   ↓
professional hosting利用↑
   ↓
data center / AS依存↑
   ↓
correlated failure risk↑

という副作用が生じやすくなります。

一方、Cardanoは比較的低いnode requirementを維持することで、自前運用を含むphysical infrastructure diversityを確保しやすい設計です。

ただし、Cardanoもインフラ集中リスクがゼロという意味ではありません。実際の比較には、各チェーンのAS、クラウド、地域、リレー構成などの最新データが必要です。


10. 「Nakamoto coefficient」だけでは足りない

今回の事象から、ブロックチェーンの分散性を単一指標で評価する限界がよく分かります。

今後は少なくとも、

  • Stake Nakamoto coefficient
  • Validator coefficient
  • Hosting-provider coefficient
  • Data-center coefficient
  • AS coefficient
  • Geographic coefficient
  • Client diversity
  • Correlated-failure coefficient

を組み合わせる必要があります。

特に重要なのがcorrelated-failure coefficientという考え方です。

validatorが別々に見えていても、一つのネットワーク障害で同時に消えるなら、実効的な分散性はvalidator数から想像するより低いからです。


11. Solana側にも改善ルートがある

今回の問題をもって「Solanaは構造的に改善不能」と考えるのも適切ではありません。

SolanaではFiredancerなどによるclient diversity向上に加え、ネットワーク層でも専用・高性能インフラを利用する方向性があります。

概念的には、

現在
Validator
   ↓
Public Internet
   ↓
Hosting / AS

から、

将来
Validator
   ↓
複数network path
   ├─ Public Internet
   ├─ dedicated infrastructure
   └─ failover path

のように冗長化できれば、相関障害への耐性は向上します。

一方で、専用ネットワークへの依存が強くなれば、そこ自体が新しい集中点になる可能性があります。

したがって重要なのは単純な高速化ではなく、

高速化と障害ドメイン分散を同時に実現できるか

です。


12. 今後1〜3年の5段階シナリオ

以下は公開情報を踏まえたCGTAの推測であり、確定的な予測ではありません。

Scenario内容推定確率
S5 最良AS/DC分散、automatic failover、client diversity、複数network pathが進み、同種障害でも影響stakeを10%未満に抑える15%
S4今回を契機にhosting/AS concentrationが改善し、20%超の同時offlineが起きにくくなる35%
S3 基準改善は進むが高性能validatorのDC依存は残り、15〜25%規模の相関障害リスクが継続35%
S2stake集中が十分改善せず、別provider/AS障害で再び1/3 threshold近辺まで到達12%
S1 最悪infrastructure障害と別障害が重なり1/3超がofflineとなり、finality停止や大規模復旧対応が必要になる3%

13. CGTAの総合評価

今回を、

「Solanaがまた止まった」

と表現するのは不正確です。

実際にはブロック生成・トランザクション処理・finalityは継続しました。

しかし反対に、

「Solanaの分散化が十分であることが証明された」

だけで終えるのも楽観的すぎます。

より正確には、

Solanaのコンセンサスは重大なインフラ障害に耐えた。しかし同時に、stakeの約29%を一度に失わせ得るAS/ネットワーク層の集中リスクが実地で可視化された。

という事件です。

これはSolanaにとって重大なnear missであると同時に、非常に価値のある実地ストレステストでもあります。

そしてブロックチェーン全体への教訓は、

validatorの数だけでは分散性は測れない。

ということです。

論理的なvalidator分散の下に、

  • AS
  • ISP
  • data center
  • hosting provider
  • upstream network
  • geographic region
  • software client

という物理的・技術的な依存関係があります。

今回のSolana事例は、今後Bitcoin、Ethereum、Cardano、Solana、Suiなどを比較するときにも、「ノード要求スペック → データセンター依存 → 物理的分散性 → 相関障害耐性」という評価軸を明示的に加える必要性を示した事例と考えます。


情報源・Fact Check

  1. CoinDesk, Omkar Godbole / Cheyenne Ligon,

*Solana neared the network freeze threshold Wednesday, Marinade Finance says* 2026-08-12〜13報道。Solana Foundation側の説明、validator稼働状況、block/transaction継続について確認。

  1. Decrypt,

*A Routing Bug Took Solana 86% of the Way to Losing Finality* Marinade分析として28.83% stake offline、33.34%付近のfinality threshold、AS20326へのstake集中、TeraSwitchのrouting問題などを報道。

  1. Marinade Finance, delegation strategy関連資料。

validator、server provider、country、cityなど複数軸でstakeを分散させる必要性を説明。

  1. Cardano Epoch table(BWtake提供資料)

Epoch 649:2026-08-13 06:44:51 JST〜2026-08-18 06:44:51 JST。

Fact Check上の注意

  • 「約28.83% stake offline」やAS集中の詳細は主としてMarinadeの分析を報道各社が引用したものです。
  • Solana Foundationはネットワーク自体が停止していないことを強調しています。
  • TeraSwitch以外で同時刻に観測されたoffline stakeについて、すべてが同一原因だったかは公開情報だけでは確定できません。
  • Cardanoとの比較部分は設計特性からの分析を含みます。各チェーンの最新AS/hosting集中度を定量比較するには追加調査が必要です。
  • 5段階シナリオの確率はCGTAによる推定であり、観測された統計的発生確率ではありません。

作成日:2026-08-14 JST Cardano Epoch:649