ノード間の移行
ノードマシンがその役割を果たせなくなり、別のマシンに移行する必要がある場合があります。 これは、ノードをアップグレードする場合、クラウドベースのノードから専用ハードウェアでローカルにホストされているノードに移行する場合、またはノード自体が壊滅的なハードウェア障害を起こし、バックアップマシンでvalidatorを実行する必要がある場合などに発生する可能性があります。 いずれの場合でも、このガイドはwalletとvalidatorキーを1つのノードから別のノードに安全に移行し、スラッシングされないようにする方法を理解するのに役立ちます。
スラッシングとスラッシングデータベース
あるマシンから別のマシンにwalletを移行する際、または別のマシンでwalletを復元する際に十分な注意を払うことを推奨する主な理由は、スラッシングのリスクがあるためです。 スラッシングは、1つ以上のvalidatorキーがBeacon Chainのルールに違反し、ネットワークを攻撃しようとしているように見える行為を行った場合に発生します。 これに対し、チェーンはvalidatorを強制的に退出させ、厳しいペナルティを課します。ペナルティの大きさは、自分の前後2週間以内にスラッシングされた他のvalidatorの数によって異なりますが、現在の最小値は1 ETHで、上限はありません。
「ネットワークを攻撃している」と解釈される条件はいくつかありますが、現実的に誤って発生するのは二重アテステーション(または二重提案)のみです。 これは、validatorが同じスロットに対して異なる投票を持つ2つのアテステーション(または2つのブロック提案)を送信した場合に発生します(例えば、特定のスロットに対して1つを選ぶのではなく、2つの異なる候補ブロックに投票する場合)。
これに対処するため、Validator Clientはスラッシングデータベースと呼ばれるものをホストしています。 スラッシングデータベースは、validatorの投票の記録(つまり、各投票のスロットとその投票が対象とするブロックのハッシュ)であり、既に投票したものに再び投票しないようにするためのものです。
スラッシングを回避する
すべてのValidator Clientは、ノードが二重アテステーションまたは二重提案を行わないようにするためにスラッシングデータベースを維持しています。 問題は、スラッシングデータベースなしで検証を開始し、validatorが以前に何に投票したかの記録がない状況から生じます。 これは、以下のようないくつかの状況で発生する可能性があります。
- Consensus Clientを変更したばかりで、新しいクライアントが古いクライアントからスラッシングデータベースを引き継いでいない(Smartnodeはクライアント変更時にこれを行いません)。
- 1台のマシンにwalletをロードして積極的にアテステーションを行っており、その後、最初のマシンがまだ積極的にアテステーションを行っている間に2台目のマシンにwalletをロードする。
- 1台のマシンで検証を停止し、2台目のマシンにwalletをロードしたが、現在のエポックがファイナライズされるまで十分に待機していないため、2台目のマシンがvalidatorが既にアテステーションを行ったスロットに対してアテステーションを行う。
スラッシングを回避する標準的な方法は、最後の成功したアテステーションから少なくとも15分待ってからValidator Clientを起動して再びアテステーションを行うことと、validatorキーが1台のマシンにのみ存在することを確認することです。
より具体的には、validatorが意図的にアテステーションをミスし、そのミスがファイナライズされるまで待つというプランです。 ファイナリティが達成されると、validatorはファイナライズされたエポックに対して投票することができなくなり、再びアテステーションを開始しても安全です。
15分待機するというのは、正常に動作している場合(つまり、正常なコンセンサスの場合)、Beacon Chainがエポックをファイナライズするのに約7分かかるという経験則から来ています。 15分待つことで、少なくとも1つのエポックをミスし、そのエポックがファイナライズされるまで十分に待ったことが保証され、安全のための小さなバッファが加えられます。
ノード移行チェックリスト
上記の背景を踏まえて、ノードを移行する際にスラッシングされないようにするために従うことができる便利なチェックリストを以下に示します。 これは最大限の安全性を考慮して設計されているため、一部のステップは不要だと思われるかもしれませんが、すべてのステップを完了するよう強く推奨します。
-
新しいノードを準備する。「ノードの準備」セクションから始めて、Smartnodeがインストールされ、ExecutionクライアントとConsensusクライアントが同期されるまでこれらのガイドに従ってください。
- :warning: 実行しないでください: 新しいwalletを初期化したり、古いwalletを復元したりしないでください。walletが存在しない状態でクライアントを同期させてください。
-
新しいノードでクライアントが完全に同期されるまで待ちます。
-
新しいマシンで
rocketpool wallet test-recoveryを実行して、ニーモニックが正しく記録されていることを確認します。これはキーの復元をシミュレートして、ノードwalletとすべてのminipoolのvalidatorキーが正しく復元できることを確認しますが、実際に復元してディスクに保存することはないため、スラッシングのリスクはありません。- Smartnodeが提供されたニーモニックを使用してノードwalletを復元できない場合、ニーモニックが無効である可能性があります。このプロセスを続けることを停止してください。古いノードからキーを削除すると、永久に失われる可能性があります。
- この状況では、できるだけ早くvalidatorを退出させて資金を引き出し、作動するニーモニックを持つ新しいノードで最初からやり直すことをお勧めします。
-
古いノードで検証を停止します(例えば、
rocketpool service stopを使用してvalidator clientをシャットダウンします)。 -
古いノードからキーを削除します(例えば、
rocketpool wallet purgeを使用します)。- ノードの
dataフォルダ(デフォルトは~/.rocketpool/data/validators/)を確認して、キーが削除されたことを確認してください。各Consensus Clientは、そのdataフォルダの下に独自のフォルダを持ち、独自のキーのコピーを持っています。 - これを行う方法については、以下のキー削除の確認セクションを参照してください。
- すべてのキーが削除されていることを確認してください。
- ノードの
-
古いノードを電源オフし、イーサネットケーブルまたはWi-Fiモジュールを取り外してインターネットから切断します。
-
古いノードからSSDをワイプします。以下のいずれかの方法を使用してください。
-
続行する前に少なくとも15分待ちます。https://beaconcha.inなどのブロックエクスプローラーを使用して、validatorのアテステーション記録を確認します。少なくとも1つのアテステーションがミスとして記録され、対応するエポックがファイナライズされるまで待ちます。
- 注意: 複数のminipoolがある場合は、すべてが少なくとも1つのアテステーションをミスし、それがファイナライズされていることを確認する必要があります。
-
既存のWalletのインポート/復元の指示に従って、新しいマシンでノードwalletを復元します。
-
validatorキーがロードされていることを確認するためにValidator Clientを再起動します(例えば、
docker restart rocketpool_validatorを使用します)。
これで、新しいノードにvalidatorキーがロードされ、安全にアテステーションを開始できます。
キー削除の確認
Validatorキーは、jsonファイルの形式でディスクに保存されます。
これらはノードのdataフォルダ内に保持されます。
デフォルトでは、以下の場所で見つけることができます。
service config TUIを使用してdataディレクトリを変更した場合(例えば、Aegisキーを使用していて、それをdataフォルダとして設定した場合)、上記のパスを<あなたのdataフォルダ>/validatorsに変更する必要があります。
各クライアントは、異なる形式または構成でキーを期待するため、独自のキーのコピーを持ちます。
ディスク上でキーを見つけるには、以下のコマンドを実行します。
例えば、2つのminipoolを持つマシンでは、出力は以下のようになります。
これは、キーがまだ削除されていない、ファイルシステムに残っている例を示しています。
キーが削除されている場合、そのコマンドの出力に16進数文字列(0xで始まる大きな文字列)がいずれのクライアントのフォルダにも表示されないはずです。