イーサリアム2.0のステーキングにはどのような潜在的な障害がありますか？どのように対処すればよいですか？

信標チェーンは、バリデーターの行動に対してさまざまなインセンティブメカニズムを提供しており、これらはネットワークの現在の状態によって決まります。したがって、ノードを保護する方法を決定する際には、他のバリデーターが問題に直面する可能性を考慮することも重要です。

アクティブなバリデーターの残高は増加するか減少するかのいずれかであり、変わらないことはありません。したがって、リスクをできるだけ低減することは、利益を最大化する一つの方法です。バリデーターの残高が信標チェーンによって差し引かれる状況は主に以下の三つです：

• 一般的な罰則：バリデーターが職務を怠った場合に適用される罰則（例：オフライン）。
• 怠慢罰則 (Inactivity Leaks)：ネットワークが確定できない状態にあるとき、バリデーターが職務を怠るとこの罰則が適用され、他のオフラインのバリデーターと高度に関連しています。
• 罰金 (Slashing)：バリデーターが矛盾するブロック提案や証明を行った場合に罰金が科されます（攻撃行為の可能性があります）。

注意：平均的には、単一のバリデーターの残高は変わらないかもしれませんが、作業に参加する限り、報酬を得たり罰を受けたりします。

ネットワーク全体が健康に運営されている場合、単一のバリデーターがオフラインになったり罰金を受けたりする影響は非常に小さく、つまり罰則の強度はそれほど大きくありません。逆に、ネットワーク内に多数のバリデーターがオフラインの場合、オフラインのバリデーターの残高削減速度ははるかに速くなります。

同様に、大量のバリデーターが同時に罰金を受けると、信標チェーンにとっては攻撃行為と同じであり、これらのバリデーターの100%のステーキング資金が消失します。

これらの「逆相関」インセンティブにより、バリデーターは他者に影響を与える問題をより多く考慮すべきであり、孤立した個人的な視点から出発すべきではありません。

故障の原因と可能性

いくつかの故障ケースを詳しく見て、どれだけの他のバリデーターが同時に影響を受けるか、そしてあなたのバリデーターがどの程度の罰を受けるかを見てみましょう。

ここで私は @econoar の意見に同意しません。これらの問題の深刻度は中程度と考えます。家庭用UPSとデュアルWANアドレスの故障は他のユーザーとは無関係であるため、考慮範囲から除外します。

? ネットワーク / 電力故障

自宅でバリデーターを運営している場合、将来的にこれらの問題に直面する可能性が高いです。家庭用ネットワークと電力接続は正常な稼働時間を保証できません。ネットワークが切断されたり電力が中断されたりすると、通常は地域全体に影響が及び、数時間続くこともあります。

あなたのネットワークや電力が非常に安定していない限り、この理由で罰を受けるのはあまり価値がありません。この数時間の間に罰を受けますが、ネットワーク全体が正常に運営されているため、あなたの罰はその期間内に得られるべき報酬にほぼ等しいです。つまり、故障時間がk時間であれば、あなたのバリデーターの残高は故障k時間前の値に戻り、k時間後には故障前の値に回復します。

バリデーター #12661 の残高回復速度はオフライン時の減少速度とほぼ同じです - Beaconcha.in

? ハードウェア故障

ネットワークの問題と同様に、ハードウェア故障もランダムに発生し、故障が発生した場合、ノードが数日間オフラインになる可能性があります。バリデーターのライフサイクル全体における期待収益と予備ハードウェアのコストを考慮する必要があります。故障の期待値（オフライン罰金×発生確率）は予備ハードウェアのコストを上回りますか？

個人的には、故障の可能性が非常に低く、予備ハードウェアのコストが高い場合は、あまり価値がありません。しかし、言うまでもなく、私は巨大なクジラではありません?。あなたは自分の実際の状況に基づいてすべての故障シナリオを評価する必要があります。

☁️ クラウドサービス故障

おそらく、ハードウェアやネットワークの故障を避けるためにクラウドサービスを利用することを選ぶかもしれません。クラウドサービスを使用する場合、上記の関連リスクが導入されます。どれだけの他のバリデーターが同じクラウドサービスプロバイダーを使用していますか？

創世前の1週間、アマゾンのAWSが長時間ダウンし、ネットワークに大きな影響を与えました。今、同様の事件が発生し、大量のバリデーターが同時にオフラインになると、怠慢罰則（inactivity penalties）が発動します。

さらに悪い状況は、クラウドサービスプロバイダーが新しい仮想マシンであなたのノードを実行し、古いノードを停止しなかった場合、あなたが罰金を受ける可能性があります（これが他のバリデーターにも影響を与えた場合、罰則の強度は特に大きくなります）。

クラウドサービスを使用することに固執する場合は、比較的小さなサービスプロバイダーに切り替えることを検討すると、損失を減らすことができるかもしれません。

? ステーキングサービス

現在、メインネットにはさまざまなステーキングサービスがあり、分散化の程度はさまざまですが、あなたのETHをサービスプロバイダーに委託することは、ある程度関連リスクを増加させます。これらのサービスは間違いなくeth2エコシステムの不可欠な部分であり、32 ETH未満を保有しているか、ステーキングに必要な技術知識が不足しているユーザーにとっては特に重要です。しかし、これらのサービスは人為的に設計されているため、欠陥が存在します。

もしステーキングプールの規模が最終的にeth1マイニングプールと同じくらい大きくなるなら、1つの脆弱性がそのユーザーを大規模に罰金または怠慢罰則の対象にする可能性があります。

? Infura 故障

先月、Infuraが6時間ダウンし、イーサリアムエコシステムが停滞しました。同様に、これもEth2バリデーターが直面する可能性のある関連リスクです。

さらに、サードパーティのeth1 APIプロバイダーは、サービスの呼び出しに対してレート制限を行う必要があります：過去には、これがバリデーターが有効なブロックを生成できない原因となりました（Medallaテストネット）。

最良の解決策は、自分自身のeth1ノードを運営することです：レート制限に遭遇せず、関連リスクを低減し、ネットワーク全体の分散化を促進します。

Eth2クライアントは、複数のeth1ノードを指定する機能を追加し始めています。その利点は、主要なエンドポイントが故障した場合に簡単にバックアップエンドポイントに切り替えられることです（Lighthouse:--eth1-endpoints、Prysm: PR#8062、NimbusとTekuも後にサポートを追加する可能性があります）。

コストが低いまたは無料のバックアップAPI（EthereumNodes.com）を追加することを強くお勧めします。無料および有料のAPIエンドポイントとその現在の状態があります。自分のeth1ノードを運営しているかどうかにかかわらず、この対策は非常に重要です。

? 特定のeth2クライアントの故障

コードレビュー、監査、テストが行われていても、eth2クライアントのバグはどこかに隠れています。彼らのほとんどは軽微な問題であり、製品リリース前に発見されますが、あなたが選択したクライアントにはオフラインまたは罰金を受ける可能性があります。このような場合、あなたは大多数（＞1/3）が使用しているクライアントを運営したくないでしょう。

あなたは、最も適切だと思うクライアントとその人気の間でトレードオフを行う必要があります。別のクライアントのドキュメントを通読し、ノードに予期しない事態が発生した場合に異なるクライアントをインストールして設定する方法を知っておくことを検討してください。

大量のETHをステーキングしている場合、異なるクライアントを運営することは非常に重要であり、すべての卵を一つのバスケットに入れないようにします。Vouchは、複数ノードのステーキングを提供するインフラであり、現在秘密共有バリデーター（Secret Shared Validators）も急速に進展しています。

? ブラックスワンの出来事

もちろん、可能性は低いが予測不可能で影響が大きい出来事もリスクをもたらします。これはあなたのステーキング設定や決定に関係ありません。例えば、ハードウェアレベルのSpectreやMeltdown、またはカーネルの脆弱性（BleedingToothはハードウェアスタック全体に危険が存在することを示唆しています）。つまり、私たちはこれらの問題を完全に予測し回避することはできず、問題が発生した後に適切な対策を講じる必要があります。

何を心配する必要がありますか？

結局のところ、これは特定の故障の期待値E(X)を計算することに依存します：イベントが発生する可能性とそのイベントのコスト。関連性要因が罰則の強度にかなりの影響を与えるため、eth2ネットワークの他のメンバーの文脈でこれらの故障イベントを考慮することが重要です。故障の期待コストを希釈するコストと比較することで、試みる価値があるかどうかを判断するための合理的な答えが得られます。

ノードが故障する可能性のあるすべての状況を誰も知らず、各故障が発生する可能性もわかりませんが、各故障タイプの可能性を独立して推定し、最大リスクを希釈することで、「集団知恵」が機能します。さらに、各バリデーターが直面するリスクは異なり、これらのリスクの評価も異なるため、あなたが考慮していないリスクは他の人によって遭遇される可能性があるため、関連性は低下します。分散化の力！

? パニックにならないで

最後に、もしあなたのノードに本当に何か予期しないことが起こった場合、パニックにならないでください！たとえ怠慢罰則（inactivity leaks）を受けたとしても、短期間の罰金はそれほど大きくありません。何が起こったのか、なぜ起こったのかを冷静に考え、その後問題を解決するための計画を立ててください。始める前に深呼吸をしましょう！慌てて誤った決定を下して罰金を受けるよりも、自分に5分間の考える時間を与える方が良いです。

最も重要なこと：?同じバリデーションキーで二つのノードを運営しないでください！?

同じキーで複数のバリデーターを運営することによる罰金 - Beaconcha.in