#Smartnodeスタックの設定（Docker / Hybridモード）

完全なExecution層とConsensus層のクライアントを実行することは困難に思えるかもしれません。選択できるオプションがいくつかあり、それぞれに多数の異なる設定があります。 幸いなことに、Smartnodeはそのような複雑さをすべて隠すように設計されており、迅速かつ簡単に設定できる一方で、必要に応じてすべてをカスタマイズする自由も提供します。

このセクションでは、Dockerベースのセットアップを使用している場合、または外部で管理されているExecutionまたはConsensusクライアント（例えば、ソロステーキング用にSmartnode外で管理しているクライアント）に接続するHybridセットアップを使用している場合の、Smartnodeを設定するさまざまな方法について説明します。

設定には3つの方法があります。

• ウィザードUI経由 - これが最も簡単な方法です。いくつかの基本的な質問だけを行い、十分にテストされたデフォルト値を使用します。これは初めてrocketpool service configを実行したときに表示されます。
• 設定マネージャーUI経由 - これにより、Smartnodeのすべての設定にアクセスでき、必要なだけカスタマイズできます。
• コマンドラインによるヘッドレス設定 - これは、Smartnodeをヘッドレス（非対話型）環境で実行し、自動的に設定する必要がある人向けのオプションです。

上記のリストから詳しく知りたいモードを選択するか、以下の各オプションをスクロールしてください。

#ウィザードによる設定

設定プロセスを開始するには、次のコマンドを実行します。

rocketpool service config

これにより、ターミナルベースのUIが起動し、ノードを迅速かつ簡単に設定できるとともに、高度なカスタマイズのためのすべての設定に対するオプションの詳細な制御も提供されます。

設定UIを初めて実行すると（または後でウィザードを再度実行することを選択した場合）、次のような画面が表示されます。

準備ができたら、Nextを押してください。

#ネットワークの選択

次の画面では、使用するネットワークを選択するよう求められます。

上と下の矢印キー（またはTabとShift+Tab）を使用して、さまざまな選択肢をハイライト表示できます。 選択肢を変更すると、右側の説明ボックスに各オプションの簡単な説明が表示されます。 これはウィザードのすべての選択ベースのページに当てはまり、ネットワーク選択だけではありません。したがって、このスタイルのページは頻繁に表示されます。

無料で入手できる偽のETHとRPLを使ってHoodiテストネットワークでRocket Poolノードを実行する練習をしたい場合は、Hoodi Testnetを選択してください。

実際の報酬を得るために本物のRocket PoolノードをMainnetで作成する準備ができている場合は、Mainnetを選択してください。

#クライアントモード

クライアントモードには2つのオプションが表示されます。

Locally Managed（**「Dockerモード」**とも呼ばれます）がデフォルトの選択肢です。 すでにクライアントペアを持っておらず、Smartnodeに管理してもらいたい場合に使用します。 これを選択すると、SmartnodeはDockerコンテナとしてExecution & Consensusクライアントペアを作成、設定、管理します。 心配しないでください、次に実行するどのクライアントを選択するかを決めることができます。

Externally Managed（**「Hybridモード」**とも呼ばれます）は、すでに別の場所で手動で管理しているExecution & Consensusクライアントペアを実行しているユーザーにとって便利な選択肢です。 これを選択すると、Smartnodeは既存のクライアントに接続するだけで、独自のクライアントは実行しません。 たとえば、ユーザーは現在ソロステーキングに使用しているクライアントにプラグインすることができます。そうすれば、クライアントの2つの別々のコピーを持つ必要がありません。

#Executionクライアントの設定

Executionクライアントを管理するために使用するモードを選択し、以下の対応するタブの手順に従ってください。

Locally Managed

External

SmartnodeにExecutionクライアントを管理してもらいたい場合、次の画面でクライアントを選択するよう求められます。

各オプションの説明については、ETHクライアントの選択セクションを参照してください。 選択したら、以下の適切なタブをクリックして設定方法を学んでください。

Geth、Besu、またはNethermindを選択した場合、ウィザードがすべての設定を処理します。 このプロセスの最後にいくつかのパラメータを手動で調整できますが、使用されるデフォルト値はノード操作に完全に適しています。 次のセクションに進むことができます。

注意

ルーターのポート転送設定でP2Pポートを開いてください。ポート30303のTCPとUDPの両方をマシンのローカルIPアドレスに転送するように設定します。 これにより、他のConsensusクライアントがそれを発見し、外部から通信できるようになります。これにより、Consensusクライアントが迅速に同期し、パフォーマンス（したがって報酬）が向上します。

各ルーターには異なる方法があるため、ポート転送の設定方法については、ルーターのマニュアルを確認する必要があります。

注意

Smartnodeは独自のDockerコンテナで実行されるため、Dockerの内部ネットワークを使用します。 ここではlocalhostや127.0.0.1のようなホスト名を使用できません。Executionクライアントが Smartnodeと同じマシンで実行されている場合は、代わりにマシンのLAN IPアドレスを提供する必要があります。

これで、Executionクライアントの設定はすべて完了です。

外部管理のExecutionクライアントの場合、次の画面でHTTPベースのRPC（web3）APIのURLとWebsocketベースのRPC APIのURLを入力するよう求められます。

SmartNodeはHTTP URLを使用して通信し、チェーンの状態のクエリやトランザクションの送信などのブロックチェーンアクティビティを実行します。 まだクライアントのAPIポートを有効にしてSmartNodeマシンからアクセスできるようにしていない場合は、今すぐ設定する必要があります。 これに関する手順はクライアントごとに異なります。HTTP RPCエンドポイントの設定方法については、クライアントのドキュメントを参照してください。

Websocket URLは、自分で使用する必要がある場合にのみ関連します。Smartnodeは使用しません。 必要ない場合は空白のままにできます。

注意

Smartnodeは独自のDockerコンテナで実行されるため、Dockerの内部ネットワークを使用します。 ここではlocalhostや127.0.0.1のようなホスト名を使用できません。フォールバックExecutionクライアントがSmartnodeと同じマシンで実行されている場合は、代わりにマシンのLAN IPアドレスを提供する必要があります。

フォールバックExecutionクライアントの選択に満足したら、次のステップに進みます。

#Consensusクライアントの設定

Executionクライアントの準備ができたので、次のタスクはConsensusクライアントの設定です。 「モード」（ローカルまたは外部）は、以前にExecutionクライアントに使用した選択から継承されます。

以下のタブから以前に選択したモードを選択してください。

Locally Managed

Externally Managed

SmartnodeにConsensusクライアントを管理してもらいたい場合、次の画面でクライアントを選択するよう求められます。

ネットワーク全体の健全性と多様性のために推奨される選択肢は、**Random (Recommended)**選択肢です。これは、サポートされている4つのConsensusクライアントの中からランダムに1つを選択します。

明示的にクライアントを選択したい場合は、ETHクライアントの選択セクションを参照して、各オプションの説明を読んで、十分な情報に基づいた決定を下してください。

注意

クライアント選択に基づいて警告が表示される2つの条件があります。

• 選択したクライアントが現在スーパーマジョリティクライアントである場合、つまり、Beacon Chainのバリデータの不健全な大多数がそれを使用しており、ネットワークの安定性を脅かしている

• 選択したクライアントが現在使用しているハードウェアに対してリソースを消費しすぎる場合

選択したクライアントにこれらのケースのいずれかが当てはまる場合、警告が表示され、別のクライアントを選択するよう求められます。 選択したものを引き続き使用するオプションもありますが、そうすることのリスクを認識しておく必要があります。

選択を行ったか、ランダムクライアントが割り当てられたら、以下の適切なタブをクリックして設定方法を学んでください。

Lighthouse

Nimbus

Prysm

Teku

Lodestar

Lighthouseの設定の最初のオプションは、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

次は、Checkpoint Syncを有効または無効にするオプションです。

Lighthouseには、信頼できる既存のBeacon Nodeに接続することで、Beacon Chainネットワークの最新ブロックに即座に同期する機能があります。 これは従来の同期よりも好まれます。時間がかからない（従来の同期には数日かかる可能性があります）ため、いくつかのセキュリティ上の利点もあります。 詳しく知りたい場合は、チェックポイント同期に関する彼らのドキュメントをご覧ください。

REST APIへのアクセスを提供する任意のBeacon NodeのURLをここに入力できます。

使用したい場合は、以下のCheckpoint Syncingに関するセクションをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

LighthouseはDoppelgänger Detectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はLighthouseのValidator Client再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Lighthouseは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Lighthouseは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

バージョン4.5.0以降、LighthouseにはQUICプロトコルを使用してより効率的な方法でP2P接続を確立するオプションがあります。この機能を使用する場合は、ETH2設定で追加のポート「P2P QUICポート」フィールドを定義し、ルーターのポート転送設定でノードに転送する必要があります。デフォルトのP2P QUICポートは8001（UDP）です。ノード（またはフォールバック/テストネットノード）で既に使用されているポートとの競合を避けてください。また、ノードでファイアウォールを使用している場合は、同じポートが開いていることを確認してください（ufw statusを確認してください）。 QUIC設定が機能しているかどうかを確認するには、docker run --network rocketpool_net curlimages/curl http://eth2:9100/metrics | grep libp2p_peers_multiを実行したときにlibp2p_quic_peersの後に2桁の数字が表示されるはずです。

Nimbusの設定の最初のオプションは、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

次は、Checkpoint Syncを有効または無効にするオプションです。

Nimbusには、信頼できる既存のBeacon Nodeに接続することで、Beacon Chainネットワークの最新ブロックに即座に同期する機能があります。 これは従来の同期よりも好まれます。時間がかからない（従来の同期には数日かかる可能性があります）ため、いくつかのセキュリティ上の利点もあります。 詳しく知りたい場合は、チェックポイント同期に関する彼らのドキュメントをご覧ください。

REST APIへのアクセスを提供する任意のBeacon NodeのURLをここに入力できます。

使用したい場合は、以下のCheckpoint Syncingに関するセクションをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

NimbusはDoppelgänger Protectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はNimbus再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Nimbusは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Nimbusは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

Prysmの設定の最初のオプションは、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

次は、Checkpoint Syncを有効または無効にするオプションです。

Prysmには、信頼できる既存のBeacon Nodeに接続することで、Beacon Chainネットワークの最新ブロックに即座に同期する機能があります。 これは従来の同期よりも好まれます。時間がかからない（従来の同期には数日かかる可能性があります）ため、いくつかのセキュリティ上の利点もあります。 詳しく知りたい場合は、チェックポイント同期に関する彼らのドキュメントをご覧ください。

REST APIへのアクセスを提供する任意のBeacon NodeのURLをここに入力できます。

使用したい場合は、以下のCheckpoint Syncingに関するセクションをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

PrysmはDoppelgänger Protectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はPrysmのValidator Client再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Prysmは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Prysmは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

Tekuの設定の最初のオプションは、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

最後の質問は、Checkpoint Syncを有効または無効にするオプションです。

Tekuには、信頼できる既存のBeacon Nodeに接続することで、Beacon Chainネットワークの最新ブロックに即座に同期する機能があります。 これは従来の同期よりも好まれます。時間がかからない（従来の同期には数日かかる可能性があります）ため、いくつかのセキュリティ上の利点もあります。 詳しく知りたい場合は、チェックポイント同期に関する彼らのドキュメントをご覧ください。

REST APIへのアクセスを提供する任意のBeacon NodeのURLをここに入力できます。

使用したい場合は、以下のCheckpoint Syncingに関するセクションをご覧ください。

Lodestarの設定の最初のオプションは、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

次は、Checkpoint Syncを有効または無効にするオプションです。

Lodestarには、信頼できる既存のBeacon Nodeに接続することで、Beacon Chainネットワークの最新ブロックに即座に同期する機能があります。 これは従来の同期よりも好まれます。時間がかからない（従来の同期には数日かかる可能性があります）ため、いくつかのセキュリティ上の利点もあります。 詳しく知りたい場合は、チェックポイント同期に関する彼らのドキュメントをご覧ください。

REST APIへのアクセスを提供する任意のBeacon NodeのURLをここに入力できます。

使用したい場合は、以下のCheckpoint Syncingに関するセクションをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

LodestarはDoppelgänger Detectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はLodestarのValidator Client再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Lodestarは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Lodestarは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

注意

ルーターのポート転送設定でP2Pポートを開いてください。ポート9001のTCPとUDPの両方をマシンのローカルIPアドレスに転送するように設定します。 これにより、他のConsensusクライアントがそれを発見し、外部から通信できるようになります。これにより、Consensusクライアントが迅速に同期し、パフォーマンス（したがって報酬）が向上します。

各ルーターには異なる方法があるため、ポート転送の設定方法については、ルーターのマニュアルを確認する必要があります

各Consensusクライアントの動作は若干異なるため、Smartnodeは外部で使用しているクライアントを知る必要があり、それに応じて自身の動作を適応させることができます。 次の画面のリストから使用しているクライアントを選択することから始めます。

注意

現時点では、NimbusはスタンドアロンのValidator Container（VC）としてまだ実行できないため、Externalモードと互換性がありません。 クライアントがこの機能をサポートすると、ここのリストに追加されます。

以下のタブからクライアントを選択して、設定を完了する方法を学んでください。

Lighthouse

Prysm

Teku

まず、Lighthouse Beacon NodeのAPIのURLを指定します。

Smartnodeは、HTTP URLを使用して通信し、チェーンの状態のクエリやメッセージの送信などのブロックチェーンアクティビティを実行します。 まだAPIポートを有効にしてSmartnodeマシンからアクセスできるようにしていない場合は、今すぐ設定する必要があります。 これを行う方法については、Lighthouseのドキュメントを参照してください。

注意

Smartnodeは独自のDockerコンテナで実行されるため、Dockerの内部ネットワークを使用します。 ここではlocalhostや127.0.0.1のようなホスト名を使用できません。クライアントがSmartnodeと同じマシンで実行されている場合は、代わりにマシンのLAN IPアドレスを提供する必要があります。

次に、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

LighthouseはDoppelgänger Detectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はLighthouseのValidator Client再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Lighthouseは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Lighthouseは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

まず、Prysm Beacon NodeのAPIのURLとJSON-RPC APIのURLを指定します。

Smartnodeは、HTTP URLを使用して通信し、チェーンの状態のクエリやメッセージの送信などのブロックチェーンアクティビティを実行します。 JSON-RPC URLでPrysm Validator Clientを準備し、Beacon Nodeと通信できるようにします。PrysmのValidator ClientはHTTP APIを介して動作できないためです。

まだAPIポートを有効にしてSmartnodeマシンからアクセスできるようにしていない場合は、今すぐ設定する必要があります。 これを行う方法については、Prysmのドキュメントを参照してください。 grpc-gatewayおよびrpc-hostを有効にする必要があります。

注意

Smartnodeは独自のDockerコンテナで実行されるため、Dockerの内部ネットワークを使用します。 ここではlocalhostや127.0.0.1のようなホスト名を使用できません。クライアントがSmartnodeと同じマシンで実行されている場合は、代わりにマシンのLAN IPアドレスを提供する必要があります。

次に、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

最後の質問は、Doppelgänger Protectionを有効にするかどうかを尋ねます。

PrysmはDoppelgänger Protectionと呼ばれる機能をサポートしています。 簡単に言えば、この機能はPrysmのValidator Client再起動後に意図的にいくつかのアテステーションをミスします。その間、バリデータキーを使用してアテステーションがネットワークに送信されているかどうかを監視します。

理想的には、アテステーションはありません（つまり、他のマシンがバリデータキーを添付して実行していないことを意味します）。 短い待機期間の後、Prysmは通常どおり検証を開始します。

ただし、バリデータキーを添付して実行している他のマシンが_ある_場合、Prysmは即座にシャットダウンし、ログファイルにエラーメッセージを発行します。 これは、アテステーションも開始すると、二重アテステーションが発生し、これはスラッシュ可能な違反だからです。 スラッシュされると、バリデータはBeacon Chainから強制的に退出され、大量のETHがペナルティとして課されます。

ほとんどの場合、doppelgänger detectionは、クライアント再起動後のいくつかのアテステーションのミス以外には何も生じません。 ただし、バリデータを新しいマシンに移動している場合や新しいBeaconクライアントに変更している場合、doppelgänger detectionは、誤って二重アテステーションしてスラッシュされるのを防ぐことができます。

ミニプールの安価な保険と考えてください。再起動するたびにわずかな利益をミスしますが、キーを2か所で実行してスラッシュされることがないとかなり確信できます。

まず、Teku Beacon NodeのAPIのURLを指定します。

Smartnodeは、HTTP URLを使用して通信し、チェーンの状態のクエリやメッセージの送信などのブロックチェーンアクティビティを実行します。 まだAPIポートを有効にしてSmartnodeマシンからアクセスできるようにしていない場合は、今すぐ設定する必要があります。 これを行う方法については、Tekuのドキュメントを参照してください。

注意

Smartnodeは独自のDockerコンテナで実行されるため、Dockerの内部ネットワークを使用します。 ここではlocalhostや127.0.0.1のようなホスト名を使用できません。クライアントがSmartnodeと同じマシンで実行されている場合は、代わりにマシンのLAN IPアドレスを提供する必要があります。

次に、バリデータのgraffitiメッセージについて尋ねます。

これは、Beacon Chainで提案するブロックに添付できるオプションのカスタムメッセージです。 メッセージは永遠に保存されるので、自分の痕跡を残す楽しい小さな方法と考えてください。

graffitiの最大長は16文字です。

今日バリデータがGraffitiに何を使用しているかの例を見たい場合は、こちらをご覧ください。

#Beacon Chainチェックポイント同期

チェックポイント同期は、一部のBeacon Chainクライアントがサポートする非常に有用な技術です。 これにより、Beaconクライアントは、最初から開始してすべてのブロックをキャッチアップすることなく、Beacon Chain全体を即座に同期できます。 これは、数日かかる代わりに、Beaconクライアントが数分で準備できることを意味します。 必要なのは、信頼できる既存のBeaconクライアントへのアクセスだけです。

HTTP APIへのアクセスを提供する任意のBeacon Nodeを使用できます。 現在、多くのノードオペレーターはcheckpoint-sync-endpointsを使用しています。これは、Rocket Poolノードオペレーターが簡単にチェックポイント同期できるようにするサービスです。 Hoodi TestnetとMainnetの両方がサポートされています。 チェックポイント同期URLのリストは、次のリンクから見つけることができます。

• チェックポイント同期URL

関連するチェックポイント同期URLを選択し、Checkpoint Sync Providerの入力を求められたときにrocketpool service config中にターミナルに貼り付けます。

その後、Beacon Nodeは最初に起動したときにチェックポイント同期ノードに自動的に接続し、チェーンの最新の状態を即座にプルダウンします。

rocketpool service resync-eth2

#フォールバックノード

Smartnodeスタックの1.5.0以降、プライマリクライアントがオフラインになった場合（Gethを使用していてプルーニングする必要がある場合など）に引き継ぐことができる「フォールバック」ExecutionクライアントとConsensusクライアントのペアを提供できます。 この状況では、プライマリノードマシンは、ミニプールのバリデータキーでアテステーションとブロック提案を行う責任を引き続き負いますが、Execution層とBeacon Chainと対話するために外部マシンに接続します。

フォールバックノードの詳細については、このセクションを参照してください。完了したらここに戻ってください。

#メトリクス設定

Rocket Poolには、ノードのハードウェアの健全性、システムアップデート、バリデータのパフォーマンス、報酬、Rocket Poolネットワーク全体に関する情報などを示す詳細なダッシュボードを表示する機能が付属しています。

ウィザードの次の質問では、これを有効にするかどうかを尋ねます。

有効にすることを選択した場合、プロセスの後半のGrafanaダッシュボードの設定セクションで、設定方法と使用方法について詳しく学びます。

#MEV設定

2022年9月のExecution層とConsensus層のMerge以降、Ethereumバリデータは優先手数料を獲得し、Maximal Extractable Value（略してMEV）に参加する能力を持つようになりました。

Smartnode v1.7.0以降、MEVはオプトアウトになったため、初期設定の一部として構成が提示されます。次の画面に表示されます。

MEVの詳細、設定、およびウィザードのこのセクションで何をすべきかについては、MEVガイドをお読みください。 完了したらここに戻ってください。

#完了

この質問の後、Smartnodeの設定が完了しました。 次のダイアログが表示されます。

セットアップに満足していてSmartnodeを開始する準備ができている場合は、ここでSave and Exitをクリックして、次にノードの保護セクションに進んでください。

すべての設定を確認し、ウィザードに含まれていない多くの追加設定をカスタマイズしたい場合は、Review All Settingsをクリックして、次のセクションに進んでください。

#設定マネージャーによる設定

すでにrocketpool service configを実行している場合、ウィザードではなく、設定マネージャー画面が表示されます。

この画面には3つの主な機能があります。

1. カテゴリリスト。Smartnodeスタックの各カテゴリの設定にドリルダウンできます
2. Review Changes and Saveボタン。変更した設定を確認して更新された設定を保存する準備ができたときに使用できます
3. Open the Config Wizardボタン。代わりにそのインターフェイスを希望する場合は、セットアップウィザードに移動します

カテゴリリストをスクロールすると、各オプションは画面の右側の説明ボックスに役立つ説明が表示されます。 自由に探索してください。Reviewダイアログを介してReview Changes and Saveボタンを使用するまで何も保存されず、いつでもCtrl+Cを押して保存せずに終了できるため、ここで設定をいじって誤って何かを台無しにすることはありません。

#設定の構成

ホーム画面から、Enterキーを使用して任意のカテゴリを選択し、そのカテゴリの設定を表示します。 たとえば、これはSmartnode and TX Feesカテゴリの画面です。

矢印キーを使用して設定を上下に移動します。 現在選択されているものには、末尾に白い四角形があります（テキストボックスまたはチェックボックスの場合）、または白でハイライト表示されます（ドロップダウンの場合）。

終了したら、Escapeを押して設定マネージャーのホーム画面に戻ります。

設定をスクロールすると、各設定は右側の説明ボックスに何をするかの簡単な説明が表示されます。 また、ストック設定に戻したい場合に備えて、デフォルト値も表示されます。

この例では、RPL Claim Gas Threshold設定が現在選択されています（左側の画面で緑色のボックスでハイライト表示されています）。 40に変更されていますが、右上隅（説明ボックスの上部）に150のデフォルトがあることがわかります。

#設定タイプとその使用方法

設定マネージャーは、次の設定タイプとUI要素を使用します。

#テキストボックス

テキストボックスは、任意のテキストまたは数字の文字列を入力するために使用されます。 次のように見えます。

希望する値を入力してから、Enterを押すか、矢印キーを使用して別の設定に移動して変更を保持します。 そうしないと、設定マネージャーはまだその設定を更新していると想定し、まだ変更としてマークしません。

#ドロップダウン

ドロップダウンは、選択肢のリストからオプションを選択するために使用されます。 次のように見えます（開いている場合）。

緑色の項目が現在選択されているものです。 矢印キーを使用してオプションを変更します。変更すると、右側の説明ボックスが更新され、現在選択されているオプションについて詳しく説明します。 選択に満足したら、Enterを押して選択したオプションを選択すると、ドロップダウンが閉じ、現在選択されているオプションが表示されます。

#チェックボックス

チェックボックスは、単純なYes/Noの質問に使用されます。 次のように見えます。

チェックされている場合、上記のように中央にXがあります。 チェックされていない場合、次のように単に空白になります。

設定を変更するには、単に選択してEnterを押します。

#変更の保存

変更に満足していて、保存する前に確認したい場合は、ホーム画面のReview Changes and Saveボタンを押します。 思い出してください。それにアクセスするには、Tabキーを押します。

次のようなビューが表示されます。

ここのReviewボックスには、変更したすべての設定が表示され、古い値と新しい値が表示されます。 たとえば、ここの最初の行は、RPL Claim Gas Thresholdが150であったことを示し、40に変更されました。

また、変更した設定によって影響を受けるコンテナも表示され、変更を保存した後にそれらを再起動するように提案されます。

変更に満足したら、Enterを押して新しい設定をディスクに保存します。 その後、ターミナルUIを終了し、次のようなメッセージが表示されます。

Your changes have been saved!
The following containers must be restarted for the changes to take effect:
	rocketpool_watchtower
	rocketpool_validator
	rocketpool_eth2
	rocketpool_node
Would you like to restart them automatically now? [y/n]

新しい設定変更を自動的に適用して、影響を受けるコンテナを再起動する場合は、yとEnterを押します。

再起動する前に他にやりたいことがあり、後で手動で行う場合は、nとEnterを押します。

いずれの場合も、設定は完了です。

2022/08/13 13:49:41 Error piping stdout: read |0: file already closed

rocketpool service stop
nano ~/.rocketpool/override/exporter.yml

# Enter your own customizations for the node exporter container here. These changes will persist after upgrades, so you only need to do them once.
#
# See https://docs.docker.com/compose/extends/#adding-and-overriding-configuration
# for more information on overriding specific parameters of docker-compose files.

version: "3.7"
services:
  node-exporter:
    x-rp-comment: Add your customizations below this line
    volumes:   ["/proc:/host/proc:ro","/sys:/host/sys:ro"]

#コマンドラインによる設定

ターミナルUIと対話できないヘッドレス環境でSmartnodeを使用する場合は、代わりにコマンドラインでノードを設定できます。

rocketpool service configコマンドは、引数として、通常ターミナルUI経由で設定できるすべての設定を受け入れます。 次のコマンドを実行して、それらのリストを表示します（非常に長いことに注意してください）。

rocketpool service config --help

出力は次のようになります。

NAME:
   rocketpool service config - Configure the Rocket Pool service

USAGE:
   rocketpool service config

OPTIONS:
   --executionClientMode value  Choose which mode to use for your Execution client - locally managed (Docker Mode), or externally managed (Hybrid Mode).
                                Type: choice
                                Options: local, external
 (default: "local")
   --executionClient value  Select which Execution client you would like to run.
                            Type: choice
                            Options: geth, infura, pocket
 (default: "geth")
   --useFallbackExecutionClient         Enable this if you would like to specify a fallback Execution client, which will temporarily be used by the Smartnode and your Consensus client if your primary Execution client ever goes offline.
                                        Type: bool

...

各オプションには、名前、タイプ、デフォルト値、および（choiceパラメータの場合）オプションがあります。 このテキストを使用して、設定したいオプションを見つけて、適切な引数を介して指定できます。

#次のステップ

ノードを好みどおりに設定したら、オペレーティングシステムを保護してノードを保護する準備ができています。 次にノードの保護セクションに進んでください。