[ネイティブモード] RedstoneアップデートとMergeのガイド

このガイドでは、ネイティブモードを使用している場合に、RedstoneアップデートとMergeに向けてノードを準備するために知っておく必要があるすべてをカバーします。

v1.5.0へのアップグレード前にすべきこと

Smartnodeのv1.5.0以降にアップグレードする前に、次のチェックリストを確認して準備が整っていることを確認してください:

フルExecutionクライアントへの切り替え

Mergeでは独自のExecutionクライアントを実行する必要があるため、InfuraやPocketなどのリモートプロバイダーを使用できなくなります。

この変更により、現在ライトExecutionクライアントを使用している場合は、v1.4のままフルクライアントに切り替え、同期を完了させてからv1.5にアップグレードする必要があります。

Engine APIのセットアップ

MergeはExecutionクライアントとConsensusクライアントの通信方法を変更します。 古いHTTPまたはWebsocketベースのRPCシステムを使用する代わりに、MergeはExecutionクライアントによって公開されるEngine APIと呼ばれる新しいシステムを必要とします。

これは、Consensusクライアントが古いProof-of-WorkマイニングシステムをProof-of-Stakeに置き換えることを可能にする特別な接続です。これはMergeの心臓部です。 また、秘密トークンで認証されているため、ConsensusクライアントのみがExecutionクライアントに接続でき、他には何もできません。

独自のExecutionおよびConsensusクライアントを管理しているため、Engine APIを手動でセットアップする必要があります。 その方法は、実行しているクライアントによって完全に異なります。

CoinCashewには、ExecutionおよびConsensusクライアントでEngine APIをセットアップする方法についての優れた簡潔なガイドがあります。 それを見て、アップグレードする前に正しくattestすることを確認して新しい構成をテストしてください。

以下で、Smartnodeソフトウェアが自動的に必要とする正しいfee recipientを使用するようにValidator Clientをセットアップする方法を示します。

v1.5.0へのアップグレード

Smartnodeスタックをv1.5.0にアップグレードすることは、他のアップグレードと変わりません。 単にこちらの通常の手順に従ってください。

アップグレード後にすべきこと

ネイティブモードでは、アップグレード後に手動で行う必要があることがいくつかあります:

アップグレードの成功を確認

最初にすべきことは、ノードが正しく動作していることを確認することです。 次の手順を検討してください:

  • Executionクライアント、Consensusクライアント、Validator Client、およびSmartnodeデーモン(rp-nodeサービス)のログスクリプトをチェックして、エラーなく正常に機能していることを確認します。
  • Block Explorer(Grafanaダッシュボードやhttps://beaconcha.inなど)で、まだ適切にattestしていることを確認します
    • Doppelganger保護を有効にしている場合、再起動後にいくつかのattestationを失うことを忘れないでください。これは正常です!

Validator ClientでFee Recipientをセットアップ

Merge前にセットアップすべき重要な詳細の1つは、Validator Clientによって指定されたfee recipientです。 概要記事で説明されているように、これは次の2つの値のいずれかになります:

  • Smoothing Poolにオプトインしている場合、これはSmoothing Pool契約のアドレスである必要があります。アドレスは公式契約ページから取得できます。
  • Smoothing Poolにいない場合、これはノードのfee distributor契約のアドレスである必要があります。アドレスは、Fee Distributor and Smoothing Poolセクションの下のrocketpool node statusを実行して取得できます。

ネイティブモードでは、Smartnodeデーモンサービスrp-nodeを使用する場合はSmartnodeにこれを管理させるか、デーモンを使用しない場合は自分で管理するかを選択できます。

デーモンによる自動管理

Smartnodeデーモンは、ノードに適切なfee recipientを自動的に決定し、変更された場合(Smoothing Poolへのオプトインおよびアウトなど)に管理します。 これは最も安全なオプションです。Smartnodeは常にペナルティを防ぐ値に設定されることを保証するためです。

これを行う方法は、正しいfee recipientを含むファイルを維持し、定期的に更新して正確性を確保することです。 更新が必要な場合、ファイルを変更し、Validator Clientを自動的に再起動して新しいrecipientをロードします。新しいminipoolをステークした後にValidator Clientを再起動する方法と同様です。

以下でクライアントを選択して、セットアップ方法を学んでください:

Lighthouse
Nimbus
Prysm
Teku

ExecStart行の_前_に次の行を追加して、Validator Clientサービスを変更します:

EnvironmentFile=`data dir`/validators/rp-fee-recipient-env.txt

例えば:

EnvironmentFile=/srv/rocketpool/data/validators/rp-fee-recipient-env.txt

次に、ExecStart行の_末尾_に次のコマンドライン引数を追加します:

--suggested-fee-recipient ${FEE_RECIPIENT}

VCは、Smartnodeデーモンによって管理されるファイルを使用するようになり、fee recipientが変更されるたびに自動的に再起動されます。

手動Fee Recipient管理

警告

これを行うことにより、fee recipientが常に正しいアドレスに設定されていることを確認する全責任を負います。

ペナルティ仕様を読んで、構成に応じて何に設定する必要があるか、およびある値から別の値に安全に変更できる時期を理解してください。

そうしないと、minipoolがペナルティを受ける可能性があります!

Redstoneがデプロイされる前は、使用しているネットワークのrETHアドレス(公式契約ページにあります)を単純に使用できます。 rETHアドレスは常に何があっても安全です。

Redstoneがデプロイされた後は、rocketpool node statusを介してfee recipientとして設定する必要がある正確なアドレスを確認できます。たとえば、Smoothing Poolにオプトインしている場合、Smoothing Poolのアドレスが表示され、fee recipientとして使用する必要があることが示されます:

Smoothing Poolにオプトインしていない場合、fee distributorアドレスが表示され、fee recipientとして使用する必要があることが示されます:

以下でConsensusクライアントを選択して、構成方法を学んでください。

Lighthouse
Nimbus
Prysm
Teku

Validator Clientのサービス定義ファイルに次のコマンドライン引数を追加します:

--suggested-fee-recipient `address`

ここでaddressは:

  • RedstoneアップデートがデプロイされるrETHアドレス(例:Mainnetの0xae78736Cd615f374D3085123A210448E74Fc6393
  • Redstoneがデプロイされた後はノードのfee distributorで、契約アップグレードが発生したらrocketpool node statusで取得できます
  • Smoothing Poolにオプトインする場合はSmoothing Poolアドレス

念のため、rocketpool node statusはいつでも使用する正しいfee recipientを表示します。

ペナルティ仕様を注意深く読んで、fee recipientに関する条件と期待を理解してください。

MEV-Boostのセットアップ

MEV-boostは、Merge後にMEV報酬をProof-of-Stake validatorに提供するためにFlashbotsが提供するシステムです。

Rocket Poolは、リターンを最大化し、プロトコルを他のstakingサービスと競争力のあるものに保つために、すべてのノードがこれを使用することを要求しています。

MEV-boostに接続するには、Beacon Node / Consensusクライアントにいくつかの調整を行う必要があります。

MEV-boostは現在HoodiまたはMainnetで利用できないため、現時点でセットアップする必要はありません。 もちろん、この移行期間中に使用しなくてもペナルティを受けることはありません。

利用可能になったら、すべてのノードオペレーターがインストールしてノードに接続する必要がある日付を発表します。 その時点でFlashbotsは従うことができる手順を提供し、ここにリンクします。

注意

すべてのノードオペレーターがMEV-boostを有効にする必要があるという発表を行ったら、Beacon Nodeに適切にインストールされ構成されていることを確認する必要があります!

そうしないと、minipoolがペナルティを受けることになります。

フォールバックノードのセットアップ

Mergeは、InfuraやPocketなどのリモートプロバイダーと互換性がないため、プライマリがオフラインになったときにフォールバックExecutionクライアントとして使用する能力を失います。

Smartnodeには依然としてフォールバックExecutionクライアント(および現在はフォールバックConsensusクライアントも)を提供する能力がありますが、制御するExecutionおよびConsensusクライアントを使用する必要があります。

フォールバックノードのセットアップの詳細については、フォールバックノードガイドを参照してください。

Fee Distributorの初期化

Smoothing Poolにオプトインせず、すべてのpriority feesとMEV報酬をfee distributor契約に請求する予定がない場合、最終的には初期化(チェーン上に契約インスタンスを作成)して、そこから出金アドレスに報酬を請求する必要があります。

これはかなり安価な操作であり、一度だけ行う必要があります。

ヒント

fee distributorの初期化はいつでも行うことができます。 初期化するずっと前に報酬をそのアドレスに蓄積させることができ、初期化後も残高は残ります。

オーバーヘッドコストを最小限に抑えるために、ガス価格が低いときに行うことをお勧めします。

報酬を請求するには初期化する必要があります。

Smoothing Poolへのオプトイン

すぐにSmoothing Poolを利用する予定がある場合は、「適格性」金額を最大化するために、最初のRedstone報酬期間の終了前にオプトインする必要があります。

オプトインは次のコマンドを実行して行うことができます:

rocketpool node join-smoothing-pool

報酬の請求

Redstoneアップグレードは、高価で問題のある古い報酬システムを、はるかに安価で、RPLの自動再ステーク(部分的および完全な金額の両方)をサポートし、そして最も重要なことにいつでも報酬を請求できる真新しいものに置き換えます。

報酬請求に時間制限がなくなり、多くの報酬間隔を一度に請求する方が安価になるため、Smartnodeの自動報酬請求機能は削除されました。 次のコマンドを介して報酬を請求できるようになります:

rocketpool node claim-rewards

これにより、Redstoneアップグレードから始まるすべての報酬間隔にわたって蓄積したすべての報酬が表示されます。