原題：「Understanding The Validator Lifecycle》
原題：「
著者: ジム・マクドナルド
原文編集：ジョン
バリデーター (Validator) のライフサイクルを理解する
イーサリアム 2.0 は、ネットワーク セキュリティを確保するためにプルーフ オブ ステークを使用しており、「検証者」と呼ばれるコンピュータ プロセスが、次にパッケージ化されるブロック (以下、「監視者」と呼びます) に投票し、ブロックをブロックに詰め込むことも提案します。 。ただし、バリデーターは単に「オン」または「オフ」であるだけではなく、存続期間中に一連のトランザクションを実行します。この記事では、バリデーターのライフサイクルを詳しく分析し、各状態と状態遷移で何が起こるか、状態遷移のトリガーとなるもの、および各状態遷移に必要な時間を示します (注 1)。
時間の象徴
イーサリアム 2.0 では、時間は通常エポック単位であり、エポックには 384 秒、つまり約 6 分半が含まれます。理解を容易にするために、この方法で測定された時間はおおよそ分、時間、日に換算されており、正確な情報は対応する脚注に記載されています。
ライフサイクルの概要
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 1: バリデーターのライフサイクルの概要
ステータスラベルは次のとおりです。
入金済み - 入金プロトコルはイーサリアム 1.0 ネットワークによって受け入れられました
保留中 - デポジットプロトコルはイーサリアム 2.0 ネットワークによって受け入れられました
アクティブ - バリデーターがブロックを監視し、提案しています
終了中 - バリデーターは監視とブロックの提案を中止する処理中です
スラッシュ - バリデーターが不正行為を行っていることが判明し、証人を打ち切りブロックを提案している最中です。
終了 - バリデーターは監視に参加していません
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 2: 証人のメタ状態
これらの状態を定義したら、各状態とそれらの間のトランザクションを詳細に分析します。
入金状況
受領デポジット契約は、バリデーターのライフサイクルの始まりです。バリデーターの資金はイーサリアム 1.0 チェーンから得られるため、受け入れはイーサリアム 1.0 チェーン上で行われます。現時点では、イーサリアム 2.0 チェーンはこのデポジットを認識していません。
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 3: デポジット状態から準備完了状態への遷移
保留中のステータス
デポジットがイーサリアム 1.0 チェーン上に十分長く存在すると、イーサリアム 2.0 チェーンに追加されます。これは、このバリデーターがイーサリアム 2.0 によって正式に認められたことを示しています。少なくとも 32 ETH が入金されていれば (注 4)、バリデーターは立会いを開始できるようになります。
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 4: 準備完了状態からアクティブ状態への遷移
アクティブ状態
バリデーターは、主要なライフサイクルをアクティブな状態で過ごすことになっています。アクティブなバリデーターは 6 分の頻度で現在の立会に参加し、ブロックチェーンの取り組みを提案することがあります (注 7)。バリデータは、次のいずれかが発生するまでアクティブのままです。
バリデーターは、立会に参加する必要があるときに職務を遂行しなかったためにペナルティを課され、資金が16 ETHを下回る原因となりました。
ユーザーは、適切なトランザクションを送信して検証の停止を要求します (このトランザクションは、バリデーターがアクティブになってから最初の 9 日間は開始できません)。
検証者が不正行為を行っていることが証明されました。
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 5: アクティブ状態から終了状態への遷移
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 6: アクティブ状態からスラッシュ状態への遷移
同じバリデーター情報を含む追加の入金契約を送信することで、アクティブなバリデーターに追加の ETH を入金できることに注意してください (有効残高は 32 ETH を超えることができないことに常に注意してください)。これは、バリデーターの資金が 16 ETH を下回って出口キューに追加される状況を回避するのに役立ちます。
終了ステータス
ネットワークの既存の検証者が検証を停止する意思を表明した場合、自発的であるか非自発的であるかに関係なく、すぐに検証を停止せず、以前のアクティブな状態と同じ終了状態に入り、引き続き参加します。同様のことを目撃し、提案します。これにより、ネットワークの安定性が確保され、バリデーターが離脱を決定して即座に職務の実行を停止する状況が回避されます。
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 7: 終了状態から終了状態への遷移
斬撃ステータス
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 8: スラッシュから終了への移行
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
図 9: 拡張スラッシュ条件
終了ステータス
バリデーターが終了状態に達すると、正式にミッションを完了したことになります。彼はブロックの立会いや提案に参加する必要がなくなり、イーサリアム 2.0 チェーンに関する状態情報を知る必要もなくなりました。
終了後、資金がバリデーターから送金されるまでに、最終的に約 1 日の遅延が発生します (注 8)。ただし、バリデーターがスラッシュとしてマークされている場合は、さらに 2 つのペナルティが課せられます。
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
グラフ 10: ほぼ同じ期間にネットワークによって削減されたバリデーターの割合として削減された実効残高
36 日が経過すると、削減されたバリデーターの残りの資金を転送できます。
ライフサイクル図からわかるように、終了したバリデーターは、いかなるメカニズムを通じてもアクティブ状態に戻ることはできません。つまり、バリデーターが終了すると、その資金は転送されるまで休眠状態になります。 Ethereum 2.0 のフェーズ 0 では資金を転送できないことに注意してください。資金移動操作が導入されるまで、終了したバリデーターの資金はすべてバリデーターに残ります。送金操作ができない理由は、ETHを送金できるユーザーアカウントが不足しているためです。
バリデーターのライフサイクルの延長
イーサリアムバリデーターのライフサイクルを詳しく説明します: イーサリアムネットワークの正常な動作を保証するにはどうすればよいですか?
イーサリアム 2.0 ステーキング インフラストラクチャの運用を確実に成功させるには、状態間の移行に何が必要か、どのくらいの時間がかかるかを理解することが重要です。最初の入金から資金の出金まで、ライフサイクルは各状態で何が起こるかを示し、いつでもバリデーターの動作を明確に説明します。
脚注
脚注
脚注 1: イーサリアム 2.0 では明確な状態メカニズムが設定されていないこと、つまり、状態の名前は理解しやすいように作成者によって提案されたものであることは注目に値します。
脚注 2: 1,024 イーサリアム 1.0 ブロックと 32 イーサリアム 2.0 エポック。
脚注 3: これは、入金プロトコルが 32 ETH 全額を必要とすることを前提としています。デポジット契約がこのしきい値よりも小さい場合、バリデーターは、より多くのデポジット契約によってバリデーターの残高が少なくとも 32 ETH に増加するまで、デポジットされた状態に留まります。
脚注 4: そうでない場合は、別のデポジットを追加して、バリデーターの残高をこの金額まで増やすことができます。
脚注 5: 各エポックは (アクティブ + 取り消された + スラッシュ付きバリデータ)/65536 で、最小値は 4 です。
脚注 6: 4 エポック。
脚注 7: 各エポックの検証者は 1 回だけ立会でき、各スロットで指定された 1 人の検証者だけが提案者の義務を果たします。
脚注 8: 256 エポック
脚注 9: 8192 エポック
IOS
Android