Ethereum Solo Staking 入門 (後編)
この記事はEthereum Solo Staking 入門 (中編)の続きになります。
この記事では、これらの準備ができていることを前提としています。
- Testnetで動作するSolo Staking用Validatorノードの構築
- Testnet用のStaking Launchpadで32ETHをデポジット済み
- Testnet上でValidatorとしてactiveになっている
Validatorノード運用中に起こるありがちな問題
筆者の独断と偏見から、実例を交えつつValidatorノード運用中に起こるありがちな問題をピックアップしていきます。
ディスクの空き容量が枯渇した
これはめちゃくちゃあるあるですが、Ubuntuサーバのインストール設定ミスでも起こる問題です。
Ubuntuサーバのインストールを行う場合、パーティションサイズをしっかりと確認してください。公式イメージからインストールを行う場合、デフォルト設定ではディスクの空き容量全てがルートパーティションに割り振られないことに注意してください。例えば2TBのディスクを搭載していても、パーティションとしては100GBしか用意されていないことがあります。
Testnetでさえ数百GB単位の空き容量が必要になるため、この状態ではチェーンの同期が永遠に完了しません。またデータを書き込めないことで同期処理事態に不具合が発生することもあるようで、空き容量を増やしてもチェーンの同期がうまくいかない場合もありました。
クライアントをbeaconcha.inと連携していれば、スマホのアプリ経由でアラートが通知されるためほぼ確実に気づくことができます。beaconcha.inはいいぞ。
Effectivenessが低い
これもよく聞く問題で、通常の設定だとEffectivenessが低く出る環境があるそうです。Valiidatorとしては、Effectivenessが80%以上ある状態[1]が健全なようです。
ネット回線に問題がなければ、Peersの数を増やすことでEffectivenessの問題を解決できる場合[2]があります。特にTekuの場合、デフォルト設定[3]では64 peersを超えると新規のpeersを探しにいかない状態になるため、この問題が発生しやすいらしいです。
Tekuでは、この問題の解決に--p2p-peer-lower-boundコマンドオプションを利用できます。デフォルト値よりも大きな値を指定することで解決できる場合があります。
eth-dockerにおいては、.env内のCL_MIN_PEER_COUNTで設定できます。
# Some clients suggest adjusting to higher (or lower) peer count. Adjust here, per client
# Nimbus peer count should not be set below 70. CL_MIN_PEER_COUNT is used for Teku only.
CL_MAX_PEER_COUNT=
CL_MIN_PEER_COUNT=
筆者は、EthStakerのDiscordポスト[4]を参考にCL_MIN_PEER_COUNT=９0を設定して様子を見ることがありました。--p2p-peer-upper-boundのデフォルト値は100なので、これぐらいの数字がちょうど良いのかなと感じています。
Validatorノードの現在のPeers数に関しては、eth-docker付属のGrafanaダッシュボードもしくはbeaconcha.inのスマホアプリから確認できます。
チェーンの同期がおかしくなった
クライアントが異常終了したときに、たまに発生する不具合です。BesuやTekuだけではなく、Gethも含めた様々なクライアントで同様の問題が報告されています。基本的にはログのエラー表示を見ればおかしいと気付けることが多いですが、解決方法を真面目に考えるよりも同期をやり直したほうが早く解決します。
クライアントがバグってる
メモリリークでクライアントが強制終了する、ブロックの提案がおかしい、などなど。
最近ではBesu 22.7.3で実際にメモリリークの問題があり、一定時間経過するとクライアントの動作がおかしくなる問題がありました。メモリリークなどの問題に関しては、CPU使用率、メモリ利用率、Context Switchesの回数などで気付ける場合がほとんどなのできちんと監視しましょう。
さらにいうと、クライアントとのアップデート情報を日々確認することが大事です。最新のクライアントをMainnetでいきなり使うことは、個人的にあまりオススメできません。Testnetで十分に検証したバージョンだけを利用するようにしましょう。
Wagyu Key Genを利用したMainnet用の鍵生成
比較的ユーザーフレンドリーな鍵生成ツールとして、Wagyu Key Genがあります。大きな特徴はGUIでValidator向けの鍵を簡単に生成できることで、初心者でも迷わずに鍵生成を行うことができます。（Githubのrepoはこちら）
WindowsやMac上で利用した場合は、開発元が検証されていないと警告が出る可能性があります。
生成されたニーモニックフレーズの安全な保存については、実のところかなり難しい問題です。ファイルに書き込んでバックアップ、フレーズの印刷、パスワード管理サービス上で暗号化したテキストを保存するなどの方法が考えられますが、どれも一長一短あります。何にせよ鍵の管理は自己責任なので、ニーモニックフレーズを絶対に思い出せる方法を選択することが重要だと感じています。
Wagyu Key Genで生成した鍵をeth-docker/.eth/validator_keysに格納することで、先の手順と同様に鍵のインポートを行うことができます。TestnetのETHに余力があれば、Wagyu Key Genを利用したStaking手順も是非試してみてください。
Mainnetでやらかした話
この記事を公開するきっかけとなったSolo Stakingでやらかした話を書き留めておきます。興味のない人は読み飛ばしてください。
皆様はMainnetとTestnetの大きな違いをご存じでしょうか？ それは利用者の数、つまりチェーンのサイズです。筆者はMainnetでのStakingを始める前にTestnetで十分な検証を行なっていたため、Testnetでの時間感覚に慣れきっていました。
クライアントが十分に動くことを確認し、MainnetのチェーンをSyncingし始しました。数時間待ったところ同期は順調に進んでいるようです。現在はほとんど問題になっていないのですが、実はValidatorの登録数は1日の上限が決められており、過去には32ETHデポジットした後、有効になるまで1週間待つような状態になっていたこともありました。
Mainnetのチェーン同期ですが、確か2年前くらいに一度試したことがあります。そのときは一日あれば十分だった記憶があります。TestnetであるGoerliの同期は8時間程度でしたので、「まぁ、多くてもその倍くらいか」ということで、深夜寝る前にStaking Launchpadを開いて鍵の登録を開始しました。Mainnetのチェーンを同期し始めてから、既に数時間が経過しています。クライアントに対する鍵のインポート手順の検証も終わり、Staking Launchpad上ではTestnetで練習した手順をなぞっていくだけでした。32ETHをデポジットする手順はスムーズに完了しました。
翌朝起きてもクライアントの同期はまだ完了していません。鍵の有効化もペンディングの状態です。beaconcha.inの画面でも表示されますが、鍵の有効化は通常16〜24時間程度必要です。日が終わり寝る前に再度確認してみると、鍵の有効化がようやく完了したところでした。しかし、どうやらまだ……クライアントの同期は終わってないようです。そろそろ終わるだろうとタカを括って寝ることにしました。
深夜に目が覚めてしまったので、クライアントの同期状態を再び確認します。実行クライアントのSyncingはまだ終わる気配がありません。beaconcha.inの画面にMissの文字が並び始めていました。モニタリング状況を何度確認しても動作に異常はありません。何やら嫌な予感がしました。クライアントのログには淡々とSyncingが表示され続けています。
この辺りでMainnetの同期にかかる時間を再び調べ始めました。Googleのパワーでおおよその値を知っているつもりでしたが、EthStakerのDiscord内を検索してみたところ、2022年9月時点で最短1.5日程度の時間が必要だったそうです。36時間……。36時間……。
Missで赤くなったbeaconcha.inの表示を横目に、心の平静さを保つ目的で現在この記事は執筆されました。
Mainnetの同期は、本当に時間がかかるよ。
追記：2022年10月現在、筆者の環境ではMainnetの同期に49時間必要でした。2日分の祈りが届いて良かったです。
おわりに
素数を数えながら震えていた結果、前中後編の長い記事が書き終わりました。元ネタは書きかけのブログ記事でしたが無事脱稿できて良かったです。
日本語で紹介されているほとんどの記事がMainnetを対象にしたものであり、TestnetのValidatorノード運用に関する記事は、比較的貴重な内容になっていると思います。軽くではありますが、ノード運用に踏み込んだあるあるネタにも触れることができて良かったです。
文章にして改めて確認することができましたが、やはりStakingのハードルはまだまだ高いなと感じました。コミュニティの外からでは技術以前のレベルで分からないことも多く、検索しても出てこない情報が多すぎるだろ！！！と、まとめながら二重の意味で泣きそうになっていました。
とりあえず僕は、Grafanaダッシュボードを見ながらMainnetの同期が成功することを祈ろうと思います。（デポジットの前に確認しろ）
それではみなさん、良いSolo Stakingライフを！ 🎉
Discussion