ポストモーテム（事後検証）：2025年9月10日のスラッシングインシデント

Ledefiリサーチ事業部
暗号資産
TwitterFacebookHatena BookmarkLine

2025年9月10日に発生したスラッシングインシデントについての詳細な事後検証。徹底した調査の結果、要因は外部にあり、ユーザー資産は安全であることが確認された。

2025年9月10日（水）、SSV Labsのモニタリングシステムが2件のスラッシングインシデントを検知した。最初の事例は1つのバリデータに影響し、約1時間半後に2件目が発生し、39のバリデータクラスターに影響を及ぼした。両方のインシデントは即座にエスカレーションされ、詳細な調査が行われた。結果としては、いずれもSSV Networkの外部に起因することが確認された。

以下に、詳細なイベントのタイムラインと、結論および今後の学びを共有する。

重要なポイント

今回のインシデントから得られた重要な学びは、以下の通りである。

  • バリデータキー管理：キーは単一の信頼できる環境内に限定する必要がある。意図せず並行して複数の環境でバリデータを稼働させると、二重署名やスラッシングが発生するリスクが高まる。
  • 単一クラスタインスタンス：ノードオペレーターは、同時に稼働しているクラスタインスタンスが1つだけであることを保証する必要がある。冗長性は環境を重複することで実現するのではなく、DVT（Distributed Validator Technology）によって実現すべきである。
  • スラッシングプロテクション：スラッシングプロテクションは、メンテナンス、バリデータ移行、フェイルオーバーの際に不可欠である。SSVは、バリデーターキーがそのインフラ内で一貫して管理される場合にのみスラッシングリスクを大きく低減するが、バリデーターキーが外部で再利用されると効果は弱まる。

設計上、SSVはオペレーター間で責任を分散させることでスラッシングリスクを低減する。しかし、バリデータキーがSSVの外部で運用される場合、その保証は適用されない。

現在の状況

  • SSVプロトコルおよびインフラは侵害されていない。
  • 現時点でSSVオペレーターやステーカーに求められる対応はありません。
  • 両方のインシデントはSSVプロトコルの問題ではなく、キー管理における外部の運用ミスが原因であった。

インシデント #1：単一バリデータ

タイムライン（UTC）：

  • 11:51 – 最初のスラッシングイベントを検知。
  • 11:53 – モニタリングアラートを発報。
  • 12:00 – アラートが正当なものであると確認。
  • 12:01 – 利用可能なすべてのデータ収集を開始。
  • 12:09–15:14 – オペレーター（合計6名）からログを受領。

調査結果

Beaconcha.inのデータにより、当該バリデータが二重署名違反（同じエポックに対する2つのアテステーション〔検証署名〕）によってスラッシュされたことが確認された。しかし、SSVノードのログおよびテレメトリ（稼働データの自動収集）を照合したところ、アテステーション署名は1つしか記録されていなかった。SSVノードは送信したすべてのアテステーションを確実にログに残すため、ダブルサインがSSVインフラから発生した証拠は存在しない。

SSV LabsチームとSSV DAOは、影響を受けたバリデータのステーカー（ETHを預けて報酬を得る参加者）とも直接連絡を取っている。彼らからの情報は極めて重要であり、調査をさらに進めるために追加の詳細を依存している。

結論

今回のスラッシングイベントはSSVノードによるものではなく、プロトコル外部の要因によって引き起こされた。バリデータのステーカーとのさらなる調査は現在も進行中である。

インシデント #2：39バリデータ（クラスタ）

タイムライン（UTC）：

  • 13:17 – 2回目のスラッシングを検知。
  • 13:25 – スラッシュされたすべてのバリデータが、1つのSSVクラスタ（オペレーターID 14, 17, 22, 71）に属していることを確認。
  • 13:38 – バリデータオーナー（Ankr）に連絡。
  • 13:45 – Ankrが事態を認識し、直ちに影響を受けたすべてのオペレーターをシャットダウン。
  • 14:42 – ログを受領。インシデント #1 と同様に、SSVによるダブルサインの証拠はなし。
  • 15:44 – Ankrが根本原因を確認：SSV外部で並行してバリデータインスタンスを稼働させてしまった内部メンテナンス上のミス。

結論

今回のスラッシングはプロトコル由来ではなかった。原因は、バリデータキーがメンテナンス中に2つの異なるインフラ上で同時に稼働していたことにあり、運用上の設定ミスによるものであった。その後、Ankrが自社の内部キー管理手順に関連する事象であったことを確認している。

パートナーおよびコミュニティの協力

Ankrを含むパートナーの迅速な協力と透明性、そしてこのインシデントを通じたコミュニティの建設的な関与に感謝する。オープンな協力はネットワークの強靭性にとって不可欠である。

質問がある場合は、SSVのDiscordまで連絡してほしい。