イーサリアム 2.0 ステーキングのベテランドライバーズガイド: ステーキングを避けるための 3 つのヒント
編集者注: この記事は以下から引用しましたバビット情報（ID：bitcoin8btc）編集者注: この記事は以下から引用しました
バビット情報（ID：bitcoin8btc）
バビット情報（ID：bitcoin8btc）
、著者：ラウル・ジョーダン、翻訳：無料で簡単、許可を得て掲載。
この記事では、イーサリアム 2.0 ネットワークのスラッシュ メカニズムについて説明します。ステーキング参加者 (特に直接参加する人) は、どのような状況でスラッシュが発生するのか、またスラッシュを回避する方法を理解する必要があります。このドキュメントに記載されている情報のほとんどは、クライアントの選択に依存しません。つまり、Prysm、Lighthouse、Teku、Nimbus、または別の Ethereum 2.0 クライアントを実行するかどうかに関係なく、すべてのユーザーに適用されます。
原作者はPrysmatic Labsの共同創設者であるRaul Jordan氏。
*重要な免責事項*
Prysmatic Labs は、クライアントのバグやドキュメントのエラーなど、原因を問わずユーザーの資金の損失に対して責任を負いません。この責任の除外はスラッシュ プロセスにも適用されます。すべての Ethereum 2.0 クライアントはコードベースの安全性を確保するために最善を尽くしていますが、他の開発プロジェクトと同様に、エラーの可能性は常にあります。イーサリアム 2.0 への参加はリスクを伴う活動であり、参加者は自らが負うリスクと責任を調査し、理解することが重要です。
斬撃とは何ですか？
スラッシュは、バリデーターがイーサリアム ネットワークと競合する動作を示すときに発生します。スラッシュは必ずしも悪意によるものではなく、設定ミスが原因である可能性もあります。検証者の行為はシステムに混乱を引き起こしたり、システムの完全性を破壊したりする可能性があるため、ネットワークに損害を与えた検証者には、約束したETHに対してペナルティが課せられますが、これは取り消すことができません。
スラッシュと非アクティブペナルティを混同しないように注意してください。スラッシュの目的は、イーサリアム 2.0 ネットワークに害を及ぼそうとする人々の意欲をそぎ、その代わりイーサリアム 2.0 ネットワークを計画通りに維持、管理、運用する人々に報酬を与えることです。スラッシュの主な目的は、チェックポイントが設定されたさまざまな履歴ビューに対してバリデーターの競合するフォークを作成するなど、イーサリアム 2.0 ネットワーク上で実行される攻撃を軽減することです。
プロトコルに正しく従うバリデーターは、通常の操作ではスラッシュ可能な投票を発行することはなく、バリデーターがオフラインであるためにスラッシュされることもありません。
スラッシュの仕組み
スラッシュ行為は、イーサリアムネットワークに害を及ぼすバリデーターの賭け金を破壊し、彼らをネットワークから強制的に退出させ、善良なアクターを促進することでブロックチェーンのセキュリティを強化します。
スラッシュは罰の一種ですが、バリデータが正しく構成されていない場合は、通常のユーザーでもスラッシュを受ける可能性があります。したがって、オーセンティケーター クライアントとオペレーティング システムを適切に設定および管理する方法を知ることが重要であり、ユーザーはその機能を完全に理解せずに高度な命令を使用しようとしないようにする必要があります。
バリデーターは、同じスロット内で異なるルート (本質的には内部データのハッシュ) を持つ 2 つの競合するブロックを提案します。このような行為が罰せられなければ、バリデーターが不要なフォークを作成したり、混乱を引き起こしたりすることが容易になります。注: 同じブロックを 2 回提案するだけではスラッシュされません。
バリデーターは、同じスロット内の 2 つの競合するブロックを証明します。これは二重投票として知られており、バリデーターがチェーンの競合するフォークを作成しようとする可能性があることも意味します。注: 同じブロックに 2 回投票するだけではスラッシュされません。https://github.com/protolambda/eth2-surround
バリデーターによって投じられた投票は、以前の投票を「囲む」か、または以前の投票に「囲まれる」ことになります。これは、バリデーターが歴史に反する投票を試みることを意味します。その場合、バリデーターは削減されます。
画像の説明
イーサリアム 2.0 サラウンド投票、から1、2没収された後はどうなりますか?
スラッシュを防止するメカニズムは複数ありますが、各バリデータ キー ペアが 1 つのバリデータによってのみ使用されることが重要です。これは簡単に思えますが、複数のバリデーターが構成されている場合、誤ってバリデーターを復元したり、既に実行されていたバリデーターを複製したりすることが簡単に発生します。変更を行うときは、正しいバリデータ キーが使用/復元/設定されていることを常に確認してください。
ここで見つけることができます (
) 追加のリソースを見つけてください。バリデーターがスラッシュされると、さまざまなことが起こる可能性があります。）；
スラッシュされたバリデーターは 36 日以内にビーコンチェーンから撤退することを強制されます。
スラッシュされたバリデータには 3 種類のペナルティが課せられます (
ソース
ペナルティは、バリデーターが終了キューを離れるまで、各エポックで開始されます。ここ。
レポートメッセージがブロックに含まれてからスラッシュされたバリデーターが終了するまでの間に、この期間中にスラッシュされた他のバリデーターの数に比例して特別なペナルティが課されます。関連するスラッシュ付きオブジェクトのすべての有効な残高まで適用可能な最大値。
これは、バリデーターがスラッシュされた場合、直ちにペナルティが課せられ、終了できるまで約 36 日間ペナルティが課され続け、18 ～ 36 日以内に 1 回限りのペナルティが課せられることを意味します。スラッシュされた金額も影響を受けます。同じエポック中にスラッシュされたバリデーターの数によって (つまり、これが調整された攻撃であるか個別の攻撃であるかを判断します)。詳しい手順については、次のサイトをご覧ください。
ここ
最後に、スラッシュされたバリデーターはバリデーター セットに再入力できないことに注意してください。検証者が検証を継続したい場合は、新しい誓約を行って新しいキーを生成する必要があり、ペナルティは取り消し不能です。
一般に、スラッシュされると、賭けているETHがどんどん減り、途中で大幅な損失が発生します。 36 日後、ビーコン チェーンから抜け出して、残りの ETH をすべて引き出すことができますが、この 36 日間の間に ETH の大部分を失うことになります。
スラッシュにつながる一般的なユーザー エラー
上記のスラッシュ シナリオは通常のユーザーには不可能に思えますが、設定が間違っていると、正直なバリデータもスラッシュされる可能性があります。これが発生する可能性のあるいくつかのシナリオを次に示します。
1. 同じ認証キーが 2 台のサーバーで同時に実行されており、最初のサーバーに障害が発生した場合にそのうちの 1 台がフェイルオーバーとして使用される可能性があります。
注: これはスラッシュ状態になる最も簡単な方法であり、フェイルオーバー システムが最初のノードがダウンしていると誤って報告した場合、スラッシュ状態になる可能性があります。
2 つの場所でキーの検証を同時に実行しないでください。
2. 没収された保護履歴を移行せずに、キーを別のコンピュータまたは別の Ethereum 2.0 クライアントに移行した。
説明: 別のノードのクロックが正しく同期されていない可能性があり、これによりスラッシュが発生する可能性がありますが、スラッシュ保護履歴を移行すると簡単に回避できます。
3. バリデータークライアントのスラッシュ保護履歴を削除または紛失しました。
説明: スラッシュ保護履歴を失うと、時計が狂ってスラッシュされるブロックや投票が生成されるなどの問題が発生する可能性があります。
4. 永続ボリューム (PV) を使用せずにコンテナ化された環境を使用して検証する
5. スラッシュエラーを引き起こす可能性のあるプロトコルのバグ (これは可能性は低いですが、最悪のケースになります)ここバリデーターを選択する際には、インストールされているソフトウェアのセットアップ、構成、アップグレード、トラブルシューティングの方法を知ることが重要です。存在するここここ
(ethereumprice.org) Ethereum 2.0 ステーキングに参加するリスクをより深く理解するための優れたリソースは、次の場所にあります。
ここ
スラッシュ状態を検出する方法を説明する別のリソースがあります。
没収を実行しているのは誰ですか?
スラッシャー
Slasher は、スラッシュ可能なイベントを検出することを主な目的とする別個のソフトウェアを指します。スラッシャー (スラッシャー) は、イーサリアム 2.0 ネットワークの「警察」と考えることができます。悪意のあるメッセージを検出するために追加のデータと処理が必要なため、これらのスラッシャーは通常、ビーコン ノードとは独立して実行されます。スラッシュ可能なメッセージを検出するために、スラッシャーはネットワーク上のすべてのバリデーターの証明と提案の履歴を記録し、その履歴をブロードキャスト コンテンツと相互参照して、ダブル ブロックや周囲の投票などのスラッシュ可能なメッセージを見つけます。
ネットワークに必要なのは、ネットワークを監視する正直なスラッシャー クライアントです。検出されたスラッシュはネットワーク全体に伝播され、できるだけ早くブロックに含められるためです。
内部告発者の報酬
スラッシュ検出を奨励するために、バリデーターは「内部告発者報酬」を受け取ります。これは、有効なスラッシュを含むブロックを送信したことに対するビーコン チェーン上の報酬です。これらの報酬はスラッシュに参加するバリデーターに与えられ、通常はバリデーター 1 人あたり約 0.1 ETH の報酬が与えられます。
インセンティブの検出は貴重ですが、Prysm でスラッシングを発見した場合、スラッシャー クライアントを実行するだけでは内部告発者の報酬を獲得することはできません。デフォルトでは、検出されたスラッシュはできるだけ早くブロックに含められるようにネットワークにブロードキャストされるため、通常、報酬はスラッシュが検出された直後に、スラッシャーを実行するバリデーターではなく提案者に送信されます。
スラッシャーを経営しているからといって儲かるとは限りません。没収はまれで、内部告発者への報酬は低く設定されている。本質的に、スラッシャーの操作は利他的な行為であり、違反を捕捉するには、誠実で機能するスラッシャーのみをネットワーク内でアクティブにする必要があります。幸いなことに、これは参入障壁が低く、かなりの数のユーザーとエンティティがネットワークを保護するためにスラッシャーを実行すると予想されます。
没収された予防接種
朗報です。没収は防ぐことができます。削減されないようにするためのベスト プラクティスは数多くありますが、それらを理解することが重要です。
1. ローカル没収保護データベース
複数のクライアントによって実装されるスラッシュ保護の 1 つの方法は、ローカル署名履歴データベースです。この機能は、Prysm の検証クライアントではデフォルトで有効になっています。このデータベースにより、バリデーターは、自身の履歴に基づいてスラッシュ可能なメッセージとみなされるメッセージに署名しないようにします。より簡単に言うと、バリデーターは、メッセージに署名する必要があるかどうかを決定する際に、データベースを唯一の信頼できる情報源と見なします。このアプローチにより、単一のバリデーターが重複したアクションを実行しないことが保証されます。
ローカルのスラッシュ保護は、同じバリデーター・キーを使用して複数のバリデーター・インスタンスを実行することを妨げるものではないことに注意してください。
データベースは、そのローカル インスタンス内のバリデーターの署名イベントのみを追跡します。これは、ユーザーがバリデータを別のクライアントに変更した場合 (たとえば、Lighthouse から Nimbus への移行)、または新しいハードウェア セットアップに移行した場合 (新しい Linux マシンへのインストール、ホストされたソリューションへの移行)、署名が履歴データベースも移行する必要があります。これにより、過去の操作の履歴が新しいクライアントに確実に保存されます。
2.遠隔斬撃保護
スラッシュを防ぐもう 1 つの代替実装は、スラッシャーを使用することです。スラッシャーは受信したすべての証明とブロックを記録し、バリデーターはメッセージの署名に同意する前にそれらを引用します。このアプローチは、ローカル署名履歴データベースよりも強力なスラッシュ保護形式ですが、データベースと同様に、同じバリデーターの複数のインスタンスの実行に対しては保護しません。
スラッシュを防ぐもう 1 つの実装は、ビーコン ノードとバリデータ クライアントの間のミドルウェアとしてスラッシャー自体を使用することです。バリデータクライアントは、ブロックまたはプルーフを送信する前に、まずスラッシャーにそれがスラッシング可能かどうかを尋ねます。
チェックに合格すると、データはビーコン ノードを通過します。これはスラッシュ保護の最も高度な形式です。理想的には、スラッシャーはネットワーク内で発生するすべてのことを知っており、各バリデーターのブロックと証明の履歴を記録するからです。ただし、注意すべき点が 1 つあります。それは、Prysm では、スラッシャーが依然として大量のリソースを消費するため、リモート スラッシュ保護がまだ最適化されていないことです。スラッシャーのリソース消費量が多いことを考えると、バリデーターがプルーフやブロックを見逃す可能性があります。リモート スラッシュ保護は、ローカル スラッシュ保護上の追加レイヤーとして動作するように設計されています。セキュリティ上の理由から、ユーザーは Prysm でローカルのスラッシュ保護を無効にすることはできません。
3. 没収保護履歴を移行する
場合によっては、ステーキング マシンを切り替えたり、自分に合った別の Ethereum 2.0 クライアントに移行したくなる場合があります。いずれの場合も、没収記録を常に携帯する必要があります。イーサリアム没収保護規格: EIP-3076EIP-3076現在、移行に関する公式の標準が存在します。
イーサリアム
2.0 クライアント間のスラッシュで保護された履歴、と呼ばれます
。この標準では、バリデーターのスラッシュ保護履歴を JSON ファイルで表現することが提案されています。このファイルには次のものが含まれています。
検証履歴のチェーンの初期状態に関する情報 (テストネットとメインネットを区別するために使用)。
ユーザーの実行中のバリデーター公開鍵に関するすべての署名済みブロックと署名証明情報。
このファイルをエクスポートし、別のコンピュータまたは Ethereum 2.0 クライアントに移行するときにインポートすると、多くの利点が得られ、このローカル履歴を保存しないという単純なスラッシュ状態を回避できます。
既存の認証キーを Prysm にインポートする
本稿執筆時点では、Prysm v1.0.1 では、Prysm ではユーザーが EIP-3076 スラッシュ保護 JSON ファイルをバリデータ クライアントにインポートすることはできません。これは Prysm チームの最優先事項であり、イーサリアム 2.0 メインネットが稼働した後の次のバージョンで実装される可能性があります。
Prysm からスラッシュプロテクション履歴をエクスポートする
本稿執筆時点では、Prysm v1.0.1 では、Prysm はユーザーがスラッシュ プロテクション履歴を EIP-3076 スラッシュ プロテクション JSON ファイルにエクスポートすることを許可していません。繰り返しになりますが、Prysm チームはこの目標を達成するために懸命に取り組んでいます。
確実にマシンを移行する場合は、Prysm がスラッシュ プロテクション履歴のエクスポートをサポートするまで待つことをお勧めします。本当に待ちきれない場合は、次の点に留意してください。
マシン 1 のビーコン ノードとバリデータをシャットダウンし、システム プロセスとして実行されていないことを確認します。オペレーティング システムのプロセス モニター ツール、または top や htop などのコマンド ライン ツールを使用して、「prysm」、「validator」、または「beacon」という名前が含まれているかどうかを確認できます。
ウォレットのディレクトリの場所をメモします。 Prysm をデフォルトで起動した場合は、「Authenticator Account List」出力の上部にそのパスが表示されますが、これはオペレーティング システムによって異なります。
カタログ全体を取得して、次のコンピュータに移行します。
