Eth2 検証者のリスクを評価するための正しい姿勢について 1 つの記事で学びましょう

ソース |Ethereum Blog

ソース |

ビーコン チェーンにはバリデータの動作に対する複数のインセンティブ メカニズムがあり、それらはすべてネットワークの現在の状態によって決定されます。したがって、ノードを保護する方法を決定するときは、他のバリデーターが問題に遭遇する可能性がある状況を考慮することも重要です。

• アクティブなバリデーターの残高は増加または減少し、同じままではありません。したがって、リスクを可能な限り軽減することがリターンを最大化する方法です。検証者の残高がビーコン チェーンによって差し引かれる主な状況は 3 つあります。

• 一般ペナルティ: このペナルティは、検証者が義務を怠った場合 (オフラインなど) に課せられます。

• 非アクティブなリーク: ネットワークがファイナライズできない状態にある場合、検証者は過失、つまりオフラインの他の検証者との関連性が高いとして罰せられます。

スラッシュ: バリデーターが矛盾するブロック提案または証明を行うと、それはスラッシュされます (おそらく攻撃)。

注: 平均して、単一のバリデーターは一定の残高を持っていますが、作業に参加することで報酬またはペナルティが与えられます。

相関

ネットワーク全体が正常な状態であれば、単一のバリデーターがオフラインになったり、スラッシュをトリガーしたりする影響は小さいため、処罰はそれほど厳しくありません。逆に、ネットワーク内の多数のバリデーターがオフラインの場合、オフラインのバリデーターの残高ははるかに早く削減されます。

同様に、多数のバリデーターが同時にスラッシュをトリガーした場合、それはビーコンチェーンへの攻撃と同等となるため、これらのバリデーターの誓約資金の 100% が破棄されます。

こうした「反相関」のインセンティブがあるため、バリデーターは、個人的に孤立するのではなく、同時に他の人に影響を与える問題についてもっと考える必要があります。

故障の原因と可能性

いくつかの失敗例を見て、同時に影響を受ける他のバリデーターの数と、あなたのバリデーターがどれほど重くペナルティを受けるかを見てみましょう。@econoarここには同意しません

声明。これらの問題の重大度は中程度であると考えられます。家庭用 UPS およびデュアル WAN アドレスの障害は、他のユーザーには関係がないため、考慮から除外されます。

🌍 インターネット/停電

自宅からバリデーターを実行している場合、将来的にこれらの問題に遭遇する可能性があります。ホーム ネットワークと電源接続は稼働時間を保証するものではありません。ネットワークが切断されたり停電した場合、多くの場合、たとえ数時間であっても、エリア全体が影響を受けます。

Validator #12661ネットワークや電力が非常に安定していない限り、この理由でペナルティを受ける価値はありません。数時間ペナルティを受けますが、ネットワーク全体が正常に動作しているため、ペナルティはその期間中に受け取るべき報酬とほぼ同じになります。つまり、失敗時間が k 時間の場合、バリデーターの残高は失敗の k 時間前の値にロールバックされ、k 時間後にバリデーターの残高は失敗前の値に戻ります。Beaconcha.in

残高はオフラインで減少するのとほぼ同じ割合で戻ります -

🛠 ハードウェア障害

ネットワークの問題と同様に、ハードウェア障害はランダムに発生し、障害が発生するとノードが数日間オフラインになる可能性があります。バリデーターの耐用年数にわたって予想される利点と予備のハードウェアのコストを考慮することが重要です。障害の期待値 (オフラインのペナルティと発生確率の積) は、予備のハードウェアのコストより大きいですか?

個人的には、故障の可能性が低く、予備のハードウェアのコストが高い場合は、価値がありません。でも、繰り返しますが、私は巨大なクジラ 🐳 ではありません。実際の状況に応じてすべての障害シナリオを評価する必要があります。

☁️ クラウドサービスの障害

おそらく、ハードウェアやネットワークの障害を回避するために、クラウド サービスの使用を選択するかもしれません。クラウド サービスを使用すると、上記の関連リスクが発生します。あなたと同じクラウドプロバイダーを使用しているバリデーターは他に何人いますか?作成の一週間前に、AmazonのAWSが長時間ダウン

、ネットワークに大きな影響を与えました。同様のイベントが発生し、多数のバリデーターが同時にオフラインになった場合、非アクティブペナルティがトリガーされます。

さらに悪いことに、クラウド サービス プロバイダーが新しい仮想マシンでノードを実行しているにもかかわらず、誤って古いノードの実行を停止しなかった場合、その結果、あなたがスラッシュされる可能性があります (これが他のバリデーターにも影響を与える場合、ペナルティは特に大きくなります)。

どうしてもクラウド サービスを使用したい場合は、小規模なサービス プロバイダーに切り替えることを検討すると、損失が軽減される可能性があります。

🥩 ステーキングサービス現在、メインネットには各種お約束サービス

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

ステーキング プールが最終的に eth1 マイニング プールと同じくらい大きくなると、バグによりユーザーに大幅なスラッシュや速度低下のペナルティが発生する可能性があります。

🔗失敗Infura は先月 6 時間ダウンしました

、イーサリアムエコシステムの停滞につながります。同様に、これは Eth2 バリデーターが直面する可能性のある関連リスクでもあります。

さらに、サードパーティの eth1 API プロバイダーは、サービスへの呼び出しをレート制限する必要があります。これにより、過去にはバリデーターが有効なブロックを生成できなくなりました (Medalla テストネット)。

最良の解決策は、独自の eth1 ノードを実行することです。レート制限に遭遇しないため、相関関係のリスクが軽減され、ネットワーク全体の分散化が向上します。PR#8062Eth2 クライアントは、複数の eth1 ノードを指定できる機能の追加を開始しました。利点は、プライマリ エンドポイントに障害が発生した場合にバックアップ エンドポイントを簡単に切り替えることができることです (Lighthouse: --eth1-endpoints、Prysm:

、Nimbus と Teku は後でサポートを追加する可能性があります)。EthereumNodes.com低コストまたは無料の代替 API (

無料および有料の API エンドポイントとその現在のステータスが ) にあります。この対策は、独自の eth1 ノードを実行するかどうかに関係なく必要です。

🦏 特定の eth2 クライアントがダウンしています

コードレビュー、監査、テストにもかかわらず、eth2 クライアントのバグはどこかに隠れています。それらのほとんどは軽微な問題であり、製品がリリースされる前に発見されますが、選択したクライアントがオフラインになったり、切断されたりする可能性があります。このような状況が発生した場合、ほとんどの人 (1/3 以上) が使用するクライアントを実行したくなくなります。

どのクライアントが最も適していると考えるか、その人気との間でトレードオフを行う必要があります。ノードに何かが起こった場合に別のクライアントをインストールして構成する方法を理解できるように、他のクライアントのドキュメントを読むことを検討してください。Vouch大量の ETH をステーキングする場合は、すべての卵を 1 つのカゴに入れることを避けるために、異なるクライアントを実行する必要があります。Secret Shared Validatorsマルチノードステーキング、現在秘密共有バリデータを提供できるインフラストラクチャです（

）も急速な進歩を遂げました。

もちろん、可能性は低く、予測不可能ではあるが、リスクをもたらす大きな影響を与える出来事も数多くあります。これはあなたのステーキング設定や決定とは何の関係もありません。たとえばハードウェアレベルでSpectreそしてMeltdownそしてBleedingTooth、またはカーネルの脆弱性 (

ハードウェア スタック全体にわたる特定の危険性を示唆しています)。つまり、これらの問題を完全に予測して回避することはできませんが、問題が発生してから対応する措置を講じることになります。

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

最終的には、特定の障害の期待値 E(X)、つまりイベントが発生する可能性とそのイベントのコストを計算することになります。相関係数はペナルティの重大さに大きな影響を与える可能性があるため、eth2 ネットワークの他のメンバーのコンテキストでこれらの障害イベントを考慮することが重要です。失敗の予想コストと希薄化された失敗のコストを比較すると、試してみる価値があるかどうかについて妥当な答えが得られます。

ノードが故障する可能性のあるすべての状況や、それぞれの故障の可能性を知っている人は誰もいませんが、各故障タイプの可能性を独立して推定し、最大のリスクを薄めることによって、「群衆の知恵」が機能します。また、各バリデーターは異なるリスクに直面し、それらのリスクを異なる方法で評価するため、あなたが考慮していないリスクは他の人も遭遇する可能性があり、したがって関連性が低くなります。分散化の力！

📕 パニックにならないでください

最後に、ノードに実際に何かが起こった場合でも、パニックにならないでください。不活動漏洩で処罰されたとしても、短期間での処罰額はそれほど大きくありません。落ち着いて何が起こったのか、なぜ起こったのかを考え、それを解決する計画を立ててください。始める前に深呼吸してください！急いで間違った決定をして罰金を科されるよりは、さらに 5 分間考えてみるほうがはるかに良いでしょう。

最優先事項: 🚨 同じ検証キーを使用して 2 つのノードを実行しないでください。 🚨

免責事項: ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に属します。転載する場合は、原文と ethereum.cn の出典を示す必要があります。再版の場合は、eth@ecn.co までご連絡ください。Beaconcha.in]

免責事項: ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に属します。転載する場合は、原文と ethereum.cn の出典を示す必要があります。再版の場合は、eth@ecn.co までご連絡ください。

公式アカウント: ETHチャイニーズステーション

公式アカウント: ETHチャイニーズステーション