2月第1週、ノードオペレータ（NO）のダウンタイムに直面したssv.networkバリデーターのレジリエンスを示す出来事がありました。このインシデントは4つのSSV NetworkのNOによって運営されているバリデータが関与しており、4つのうち3つのNOが長時間のオフライン状態になったにもかかわらず、バリデータをオンラインに保ち、最適なパフォーマンスを維持することできた。

ssv.network エクスプローラー「バリデータビュー」

ssvエクスプローラでわかるように、NOのクラスタから1つのNOが削除されました。分散バリデータ技術(DVT)によって実現されたフォールトトレランスにより、バリデータはオンラインを維持することができました。

beaconcha

このケーススタディでわかることは、SSV.NetworkのDVTインフラストラクチャが、障害のあるノード、悪意のあるノード、メンテナンス中のノードに対して耐性を示すことで、標準的なバリデータの設定における課題にどう解決するかを表しています。SSVはインフラソリューションであるため、プロトコルを使用するあらゆるステーカーやステーキングアプリケーションが、その固有のセキュリティと回復力の恩恵を受けることができます。

キープレーヤー：

• SSV Network： 分散Ethereumバリデータ運用のためのネットワークを提供する。
• ノードオペレータ： ネットワーク上のノードを操作し、バリデータを分散して動作させる。NO は $SSV で報酬を受け取ります。
• **バリデータ：**イーサリアムネットワーク上で新しいブロックを提案・認証する。バリデーターはネットワークの維持に参加するために32ETHを出資する。

イベントの説明： あるノードオペレータが長時間オフラインになったとします。これは従来のバリデータでは通常、ペナルティとETHの損失につながる状況です。さらに、クラスタ内の残りの3/4ノードが、エポック261395から263000までバリデータを操作し続けたとしましょう。

ssv.network「Traditional vs. SSV Validator」

クラスター・サイズは閾値3f+1に従って増えていきます。つまり、3つのノードごとに1つのノードがオフラインになっても問題ないことを意味します。したがって、7台のクラスターでは、2台のノードがオフラインになっても問題ないということです。

直面した課題：

長時間にわたってNOがオフライン状態になる事象への対応です。規模が大きくなると、よく使われているクライアントのバグやステーキングサービスノードがオフラインになるなど、イーサリアムネットワークに損害を与える可能性があります。