自宅サーバーでETHをステーキングする方法 (ソロステーキング)

目次

（最終更新2023年5月31日）

• 前提知識
  • イーサリアムのPoS(プルーフ・オブ・ステーク)
  • ステーキングをするメリット・デメリット
  • 自宅サーバーでのステーキングに必要なもの
  • ステーキング開始までの大まかな流れ
• ステーキングの開始手順
  1. Ubuntu Serverのインストール
  2. Ubuntu Serverの細かい初期設定
  3. JSON Web Tokenの設定
  4. イーサリアムの実行クライアントの同期
  5. イーサリアムのコンセンサス(合意形成)クライアントの同期
  6. ETHのデポジットとウォレット作成
  7. バリデーターの設定
  8. バリデーター確認用アプリのインストール
  9. (未設定の場合) 出金先アドレスの設定
  10. (任意) MEV-Boostの設定
• メンテナンス
  • 動作確認するときのコマンド
  • クライアントのアップデート方法
    • Gethのアップデート
    • Lighthouseのアップデート
    • MEV-boostのアップデート
  • バリデーターの数を増やす方法
  • バリデーターを別のサーバーに移動する方法
  • 予備のサーバーを設定する方法
  • ダッシュボードの設定方法
• ステーキングをやめる手順
  • バリデーターの退出

イーサリアムのPoS（プルーフ・オブ・ステーク）

イーサリアムは、PoS（プルーフ・オブ・ステーク, “担保金による証明”）という合意形成アルゴリズムを採用しています。取引の記録者である「バリデーター」がまず初めに32ETHを担保として提出し、不正とみなされる行為をしたら担保から罰金が引かれてしまいますが、正確な記録を続けることで報酬が得られる仕組みです。

2015年にイーサリアムが一般公開された際は、ビットコインと同様に PoW（プルーフ・オブ・ワーク）という膨大な計算処理を必要とする合意形成アルゴリズムを採用していました。2020年12月にPoSチェーンが追加され、2つのチェーンが共存する期間を経て、2022年9月に全ての機能をPoWからPoSに移行してPoWが廃止されました。この完全移行は「マージ (the merge)」と呼ばれ、界隈で非常に注目を集めました。難易度的には飛行機のエンジンを空中で交換するようなものだったとイメージしてください。2014年のイーサリアムのホワイトペーパーには将来的にPoWからPoSに移行することが書かれていましたが、実現するまでに8年かかりました。

PoSへの移行により、イーサリアムネットワークの消費電力は99.988%減少しています。例えば、PoS移行前の消費電力がエッフェル塔の高さだとしたら、移行後はレゴ人形の高さに相当します。これは年間で約1100万トンのCO2排出量の削減になっています。持続可能性が向上しただけでなく、利用者の利便性も向上しました。PoW時代のブロック生成時間（取引が記録されるまでの時間）は確率に頼っていたため、5秒から30秒以上かかることがありましたが、現在は12秒に固定されています。取引手数料も予測しやすくなり、送金したら数秒で取引が完了します。分単位で待つ場合があるビットコインの送金と比べたら雲泥の差です。

32ETHの担保金を提出すれば誰でもイーサリアムのバリデーターを運用することができます。自分で32ETHを用意し、自分のサーバーでバリーデーターを運用することをソロステーキングと呼んでいて、本記事ではこのソロステーキングのやり方を説明しています。

「自分の家にサーバーを設置してソロステーキングをする」と聞くと、非常に複雑なことをしているように感じますが、実際はそれほど難しくありません。初期設定はこの記事のコマンドをコピペしていけば良いです。初期設定が終われば後は放置するだけでよく、毎週勝手に自分のアドレスに報酬が入金されます。

※ ステーキング運用は何があっても自己責任でお願いします。この記事以外にも、英語になりますがSomer Esatの手順や、CoinCashewの手順をリソースとして活用してください。

※ 8ETHを持っていれば、ロケットプールから残りの24ETHを補充してバリデーターを運用することが可能です。やり方は別記事にまとめているので、32ETHは持ってないけれど自宅サーバーでステーキングをしたい方や、ソロステーキングで余った端数を運用したい方は是非参考にしてください。

ステーキングをするメリット・デメリット

ソロステーキングをすることで以下のメリットがあります。

• 約4~5%（2023年5月31日現在）の年利報酬を得られる：担保のETHに対して年利約4~5%の報酬を得ることができます。バリデーターがオフラインになると罰金となり、オンライン期間とオフライン期間が半々くらいであれば年利報酬がプラマイゼロになります。報酬額は、ネットワーク全体の総バリデーター数とチェーンアクティビティの活発度によって変動しているため、現状はここのオレンジの線を確認してください。運よく高額なMEV報酬を貰うバリデーターがいるため、平均値であるオレンジの線より中央値はもう少し低くなります。
  
  貰える報酬には、(A)常に貰える報酬と(B)ブロック生成をすると貰える報酬があります。
  (A)ブロックの中身を認証(“attestation”)することで貰える報酬です。全てのブロックを認証するわけではなく、6.4分(1エポック = 32ブロック)に1回認証します。また、確率は低いですが27時間毎にランダムに選ばれた512個のバリデーターはsync committeeという役割を果たします。1つのバリデーターあたり約3年に1度選ばれる程度ですが、選ばれた際は27時間attestation報酬が約50倍になります。
  (B)ブロック生成をするバリデーターはランダムで選ばれているため、貰えるブロック生成報酬には個人差があります。平均で1つのバリデーターあたり3か月に1回ほどブロック生成できますが(総バリデーター数600,000 ÷ 1日のブロック数7,200)、運が悪いと1年以上ブロック生成できない場合もあります。1回のブロック生成で10ETH以上のMEV報酬を貰えることがありますが、確率としてはとても低いので宝くじ感覚で楽しみにしておきましょう。
  正確な報酬内訳は(attestation報酬 * オンライン割合 * sync committee倍率) + (proposal reward + whistleblowing + fee + MEV)となります。attestation rewardは常に貰え、後半の4つはブロック生成時に貰えます。
  
  参考までに、自分が運用しているバリデーターの平均を計算してみたところ、マージ後からの約8ヶ月の報酬は年利換算で5.2%でした。これは運がいい方だと思います。
• イーサリアムのセキュリティを上げることに貢献する：個人でバリデーターを運用する人が増えるとイーサリアムのセキュリティは上がります。単なる投資手段としてステーキングする人には関係のない話かもしれません。
• サーバー知識が増える：自宅サーバーでステーキングするため、Linuxのサーバー知識が増えます。仕事や副業に活かせるかもしれません。
• 楽しい：個人的な意見ですが結構楽しいです。ネットワーク保全に関与している誇らしさを感じるだけでなく、証券会社や銀行に頼らず配当所得のようなものを得ている斬新さや、最新の技術に触れているワクワクを感じています。

逆に、ステーキングのデメリットは以下の通りです。

• 32ETHの単位でしかステーキングできない：ソロステーキングでは1つのバリデーターあたり32ETHを担保としてデポジットします。2023年5月31日現在の価格で約840万円です。8ETHまたは16ETHでバリデーターを運用したい場合は、ロケットプールを活用した方法を別記事にまとめてるので参考にしてください。
• 担保のETHは引き出しに時間がかかる：ステーキングを辞める際は資金が戻ってくるまでに数日かかります。ソロステーキングは比較的安全に年利数%の報酬を得ることができますが、もっと高い利率で稼げる一部の玄人にとっては機会損失になる可能性があります。
• 資産を失う可能性がある：複数のサーバーで同じバリデーターを実行するなど、不正とみなされる行為をすると、担保のETHの一部を没収され強制的に退場させられてしまいます。2023年5月31日現在で過去に強制退場させられたバリデーターは約0.04%（252 ÷ 600,000）です。この記事の通りに運用していれば問題ありません。
  また、出金先アドレスを設定せずに24個の英単語からなるバックアップフレーズを紛失したり、間違った出金先アドレスを登録すると資産を引き出せなくなります。出金先アドレスは必ず設定するようにしましょう。
• メンテナンスをする必要がある：初期設定に加え、クライアントのアップデート等のメンテナンスをする必要があります。自分が過去半年でメンテナンスに費やした時間はトータルで2時間くらいです。
• 機器代と電気代がかかる：サーバーの機器代として8~15万円の初期投資が必要です。また、パソコンを24時間365日つけっぱなしにするため、月に数百円程度の電気代がかかります。ステーキング報酬に比べると数百円は誤差の範囲です。サーバーの機器代と電気代、およびインターネット代の一部は経費として計上できます。

システム操作に自信がない方は、手順5の「イーサリアムのコンセンサス(合意形成)クライアントの同期」まではETHを担保としてデポジットしなくても実践できるので試してみてはいかがでしょうか。また、ETHのデポジットも試してみたい人は、テスト環境であればテスト環境用のETH(無料)を使用して実践できます。本番環境とテスト環境(Goerli)の作業相違点はこちらを参照してください。

自宅サーバーでのステーキングに必要なもの

「サーバー」と聞くと大きなマシンをイメージする人もいるかもしれませんが、ソロステーキングは一般的なパソコンがあれば十分です。自分はPN50というミニPCを冷蔵庫の上に置いています。サーバーの中に担保のETHが保管されているわけではないので、このパソコンを盗まれても全く問題ないです。

• 最低32 ETH：1つのバリデーターあたり32 ETHを担保としてデポジットします。１つのサーバーで複数のバリデーターを運用することが可能です。
• サーバーとして使用するパソコン：クラウドサーバーという手段もありますが、割高なサーバー代を毎月払うよりも、パソコンを買ってしまって将来的にパーツを流用したり売ったりした方がコスパが良いです。バリデーター数とCPU負荷が比例するのは64個まで且つ64個運用してもそれほどCPU負荷が高くないため、サーバーとなるパソコンは1つあれば十分です。普段使いのパソコンを併用するのではなく、ステーキング専用機を用意してください。推奨性能は以下の通り。
  ■ 目安としてPassMarkが5000点以上のCPU（消費電力を考慮してTDPが25W以下のCPUをお勧めします。CPUはRyzenではなくIntelの方がLinuxとの互換性によるトラブルが少ないです。）
  ■ 2TB以上のSSD（HDDは遅すぎて使えません。速度が遅いSSDもあるので動作確認ができているものにした方が安心です。ブロックチェーンデータは1週間で14GBほど増加していきますが、ほとんどが不要なデータなので定期的にそぎ落としが必要です。4TBにすればメンテナンスの回数を大幅に減らせます。）
  ■ 16GB以上のメモリ（32GBあればデータの増加速度を少し下げられます。）
  ■ OSは不要（無料のUbuntu Serverを使います。）
• サーバーとして使用しないパソコン：普段使いのパソコンでよいです。インターネットに繋がっていれば性能はなんでもいいです。自分はWindowsを使いましたが、Macでも大丈夫です。ブラウザでETHをデポジットをしたり、サーバーを遠隔操作するのに使います。
• モニター：サーバーの初期設定が終わるまでは遠隔操作できないためモニターが必要です。
• 秘密鍵生成用のパソコン：必須ではないですが推奨します。バリデーターの秘密鍵はエアギャップされた（インターネットに繋がっていない）環境で作成するのが一番安全です。自分は使わなくなった古いノートパソコンにUbuntu Desktopを入れてます。
• ご自身のインターネット環境：ルーターの設定をいじったり、大量のデータを安定して通信したいので公共インターネットでは厳しいです。
• USBメモリ：SDカードでも代用可能です。Ubuntuのインストールメディアを扱うので8GB以上だとよいです。
• 有線LANケーブル：初期設定は有線LANを使った方が楽です。初期設定後は無線LANで運用してもよいですが、電子レンジなどでWi-Fiに障害が出ないように気を付けてください。

ステーキング開始までの大まかな流れ

Ubuntu Serverをインストールしたパソコンで、以下のソフトを常時起動させておく必要があります。

• 実行クライアント：イーサリアムの全トランザクション(取引)データです。常に最新のトランザクションが同期されるようにします。
• ビーコンノード：バリデーターに仕事を割り振るために使われる出勤簿のようなものです。コンセンサス(合意形成)クライアントの機能の1つです。常に最新の情報が同期されるようにします。
• バリデーター：トランザクションの記録係です。コンセンサス(合意形成)クライアントの機能の1つです。バリデーターがオンラインであることによって報酬をもらえますが、前提としてビーコンノードと実行クライアントが最新の状態に同期されている必要があります。
• (任意) MEV-Boost：ブロック生成時にブロック内に含めるトランザクションを外部に選定してもらう機能です。使用するとブロック生成報酬が上がります。

ステーキング開始までの流れは以下の通りです。1TBくらいのダウンロードの待ち時間を含めると2日くらいかかります。実際の作業時間は5時間もないと思います。慣れるとトータル2時間くらいの作業量です。

1. Ubuntu Serverのインストール
   自宅サーバーとなるパソコンにUbuntu ServerというOSをインストールします。
2. Ubuntu Serverの細かい初期設定
   Ubuntu Serverのインターネットの設定など、細かい初期設定をします。
3. JSON Web Tokenの設定
   実行クライアントとコンセンサスクライアントが安全に通信するためのファイルを作成します。
4. イーサリアムの実行クライアントの同期
   イーサリアムの全トランザクションをダウンロードし、常に最新のトランザクションが同期されるようにします。
5. イーサリアムのコンセンサスクライアントの同期
   バリデーターに仕事を割り振るために使われるビーコンチェーン(出勤簿のようなもの)をダウンロードし、常に同期されるようにします。Checkpoint syncを使えば同期は数分で終わります。
6. ETHのデポジットとウォレット作成
   1つのバリデーターあたり32 ETHを担保としてデポジットします。デポジット後にバリデーターのウォレットを作成します。
7. バリデーターの設定
   取引の記録係であるバリデーターを設定し、常に起動されている状態にします。
8. バリデーター確認用アプリのインストール
   受け取った累計報酬などをスマホアプリで確認できます。バリデーターがオフラインになった時や、ブロック生成した時に通知してくれます。
9. (未設定の場合) 出金先アドレスの設定
   ステーキング報酬の送金先を設定すると溜まった報酬が約1週間に1度このアドレスに出金されます。ステーキングをやめる際は、このアドレスに担保の32ETHを含めた全額が出金されます。
10. (任意) MEV-Boostの設定
    ブロック生成時の報酬を上げたい場合に設定します。

ステーキングの開始手順

1. Ubuntu Serverのインストール

Ubuntu Serverのインストール方法はこの記事を参照してください。
後で設定するmev-boostはUbuntu Serverのバージョンが22.04以上でないと動かないので22.04以上のLTSをインストールするようにしてください。

2. Ubuntu Serverの細かい初期設定

インターネットやセキュリティの設定をしてから、遠隔操作できるようにします。
下記を上から順番に設定してください。

• セキュリティアップデートの自動更新：Ubuntuのセキュリティアップデートが自動で適応されるようにします。
• DNSサーバーの変更：グーグルのパブリックDNSを使用します。
• ユーザーの作成：ethereumというユーザーを作成し、sudoというグループに入れてください。今後サーバーで作業をするときはこのユーザーを使用してください。
• ファイアーウォールの設定：サーバーにアクセス可能なポートを制限します。他のパソコンから遠隔操作する時に使用する任意のポート番号の他に、30303（実行クライアント）と9000（Lighthouse）を許可してください。
• 正確な時刻の設定：ミリ秒単位で時刻が合っている必要があるためNTPをインストールします。
• IPアドレスの固定：SSHで他のパソコンからサーバーを遠隔操作する場合は、IPアドレスを固定しないと面倒くさいことになります。
• ルーターのポート開放：ルーターによっては、ポート転送の設定をする必要があります。30303（実行クライアント）と9000（Lighthouse）が固定したIPアドレスに転送されるように設定してください。
• SSHの設定：他のパソコンからサーバーを遠隔操作できるようにします。
• （Wifiで運用する場合）Wifiを使えるようにします。
• （32GB以上のメモリを使用している場合）十分なメモリ容量があるため、スワップ処理は無効化した方が処理スピードが上がります。
• （AMDのCPUを使用している場合）処理落ちが発生する場合はこの記事の設定をしてください。

詳細設定の完了後は念のためサーバーを再起動してください。

sudo reboot

3. JSON Web Token の設定

実行クライアントとコンセンサスクライアントが安全に通信するためのJSON Web Token(JWT)のファイルを作成します。

1. JWT用のディレクトリを作る。

sudo mkdir -p /var/lib/jwtsecret

2. opensslという暗号通信プロトコルで32バイトの16進数ファイルを作る。

openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null

3. 作成したファイルを開いて中身が入力されていることを確認する。（Ctrl + X で閉じる）

sudo nano /var/lib/jwtsecret/jwt.hex

4. イーサリアムの実行クライアントの同期

イーサリアムの全トランザクションをダウンロードし、常に最新のトランザクションが同期されるようにします。1TB近くあるのでダウンロードに1日以上かかります。

1. バイナリのダウンロードに必要なパッケージをインストールする。

sudo apt install curl

2. Gethの公式サイトを開き、「Geth X.XX.XX for Linux」のボタンを右クリックし、URLをコピーする。

3. Go Ethereumのバイナリをダウンロードする。上記で取得した最新のURLを使用してください。

cd ~

curl -LO https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

4. 解凍して/usr/local/binにコピーし、不要になったファイルを削除する。

tar xvf geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

cd geth-linux-amd64-X.XX.XX-XXXXXXXX

sudo cp geth /usr/local/bin

/usr/local/bin/geth version

cd ~

rm -r geth-linux-amd64-X.XX.XX-XXXXXXXX

rm geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

5. Go Ethereum実行用のユーザーgoethを作成する。

sudo useradd --no-create-home --shell /bin/false goeth

6. ノードを保存するディレクトリを作成し、ユーザーgoethにアクセス許可を与える。

sudo mkdir -p /var/lib/goethereum

sudo chown -R goeth:goeth /var/lib/goethereum

7. サーバー起動時にGo Ethereumが自動的に開始されるためのserviceファイルを作成する。

sudo nano /etc/systemd/system/geth.service

8. 以下を入力し、保存する。（Ctrl + O で保存、Ctrl + X で閉じる）

[Unit]
Description=Go Ethereum
After=network.target
Wants=network.target

[Service]
User=goeth 
Group=goeth
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/geth \
  --datadir /var/lib/goethereum \
  --authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex

[Install]
WantedBy=default.target

※ExecStart=のパラメータに--maxpeers 20を追加すればデータの送受信を抑えられます。デフォルトは50に設定されています。低くしすぎると同期に支障をきたす場合があります。

※gethのチェーンデータは1週間で14GBほど増加していきますが、殆どが不要なデータなので定期的にそぎ落とし（プルーニング）が必要です。メモリを多く搭載している場合は、gethの利用するメモリ容量を--cache 16000（デフォルトは4096）のように増やすとチェーンデータの増加スピードを少し鈍らせることができます。メモリ設定を高くしすぎても、gethは自動的に安全圏までしか使わない仕様になってます。

9. daemonをリロードし、Go Ethereumがちゃんと動くか確認する。今後上記のserviceファイルに変更を加えることがあれば、毎回daemonをリロードして変更を適応するようにしてください。
   （active (running)と緑で表示されれば OK、Q で閉じる）

sudo systemctl daemon-reload

sudo systemctl start geth

sudo systemctl status geth

10. サーバー起動時にGo Ethereumが自動的に開始されるようにする。

sudo systemctl enable geth

11. ログで同期状態を確認する。（Ctrl + Cで閉じる）

sudo journalctl -fu geth

※ビーコンノードが設定されていないと同期は開始しません。

※全てのデータがダウンロードされ、同期が完了するまで1日程度かかります。ログにImported new potential chain segmentが表示されるようになれば同期完了です。

※ 自分は同期中にM.2のSSDがフリーズすることがありましたがAPST(省電力設定)を無効化したら発生しなくなりました。フリーズすることがあればお試しください。

5. イーサリアムのコンセンサス(合意形成)クライアントの同期

バリデーターに仕事を割り振るために使われるビーコンチェーンをダウンロードし、常に同期されるようにします。この手順ではビーコンノードとバリデーターに「Lighthouse」というクライアントを採用しています。Checkpoint syncを使用すれば同期は数分で終わりますが、使用しなければ数日かかります。

1. 最新のLighthouseのバイナリをダウンロードする。
   最新バージョンのURLは公式GitHubから取得してください。

cd ~

curl -LO https://github.com/sigp/lighthouse/releases/download/vX.X.X/lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

2. 解凍して/usr/local/binにコピーし、不要になったファイルを削除する。

tar xvf lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

sudo cp lighthouse /usr/local/bin

/usr/local/bin/lighthouse --version

rm lighthouse

rm lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

3. ビーコンノード実行用のユーザーlighthousebeaconを作成する。

sudo useradd --no-create-home --shell /bin/false lighthousebeacon

4. ビーコンチェーンを保存するディレクトリを作成し、ユーザーlighthousebeaconに権限を付与する。

sudo mkdir -p /var/lib/lighthouse/beacon

sudo chown -R lighthousebeacon:lighthousebeacon /var/lib/lighthouse/beacon

5. サーバー起動時にビーコンノードが自動的に開始されるためのserviceファイルを作成する。

sudo nano /etc/systemd/system/lighthousebeacon.service

6. 以下を入力して、保存する。（Ctrl + O で保存、Ctrl + X で閉じる）

[Unit]
Description=Lighthouse Beacon Node
Wants=network-online.target
After=network-online.target

[Service]
User=lighthousebeacon
Group=lighthousebeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --http \
  --execution-endpoint http://localhost:8551 \
  --checkpoint-sync-url https://sync-mainnet.beaconcha.in \
  --execution-jwt /var/lib/jwtsecret/jwt.hex

[Install]
WantedBy=multi-user.target

※別のサーバーで動かしている実行クライアントと繋げるときは、そのサーバーのIPアドレスとポート番号を指定します（例：http://192.168.0.88:8551）。その場合はJWTファイルのコピーも忘れずに。

※Checkpoint syncを使用すれば同期を数分で終わらせることができるので強く推奨します。Checkpoint syncをする場合はExecStartに--checkpoint-sync-urlオプションを追加し、一般公開されているエンドポイントを指定してください（例：--checkpoint-sync-url https://sync-mainnet.beaconcha.in）。自分の別のサーバーで起動しているビーコンノードを指定する場合は、既存のビーコンノードでポート5052を解放してExecStartに--http-address 0.0.0.0を追加し、新しいビーコンノードのExecStartで既存のビーコンノードのIPアドレスを入力します（例：--checkpoint-sync-url http://192.168.0.99:5052）。

7. daemonをリロードし、ビーコンノードがちゃんと動くか確認する。今後上記のserviceファイルに変更を加えることがあれば、毎回daemonをリロードして変更を適応するようにしてください。
   （active (running)と緑で表示されれば OK、Q で閉じる）

sudo systemctl daemon-reload

sudo systemctl start lighthousebeacon

sudo systemctl status lighthousebeacon

8. サーバー起動時にビーコンノードが自動的に開始されるようにする。

sudo systemctl enable lighthousebeacon

9. 同期状態を確認する。（Ctrl + Cで閉じる）

sudo journalctl -fu lighthousebeacon

※ Checkpoint syncをした場合はログでINFO Starting checkpoint syncが表示されると数秒～数分間ログに変化がない状態になります。そのうちLoaded checkpoint block and stateが表示され、定期的にInfo Syncedが表示されるようになればバリデーターが仕事をするための必要最低限の同期が完了しています。

※ 実行クライアントとビーコンノードが同期されていないとバリデーターが仕事をしてくれないため、両方同期されるのを待ちましょう。

6. ETHをデポジットしてウォレットを作成する

1つのバリデーターあたり32 ETHを担保としてデポジットコントラクトに送金します。その後、バリデーターのウォレットを作成します。

※ 以下の手順ではステーキング用のサーバーで鍵を作成していますが、可能であれば別のエアギャップしたパソコンで鍵を作成し、USB経由でステーキング用のサーバーに鍵をコピーし、鍵を作成したパソコンはインターネットに繋ぐことなくOSの初期化をすることを推奨します。

1. 必要なパッケージをインストールする。

sudo apt update && sudo apt upgrade -y

sudo apt install python3-pip git -y

2. 鍵生成用のリポジトリをクローンしてインストールする。

cd ~

git clone https://github.com/ethereum/eth2.0-deposit-cli.git

cd eth2.0-deposit-cli

sudo ./deposit.sh install

3. 実行クライアントとコンセンサスクライアントを実行していたら終了し、サーバーの電源を落とし、インターネットの接続を完全に切って再起動する。

sudo systemctl stop lighthousebeacon

sudo systemctl stop geth

sudo shutdown -h now

4. 運用するバリーデーターの数を指定して（例：--num_validators 2）鍵生成用のコマンドを実行する。

cd ~/eth2.0-deposit-cli

./deposit.sh new-mnemonic --num_validators バリデーター数 --chain mainnet --eth1_withdrawal_address 0x000....000

※--eth1_withdrawal_addressオプションで出金先アドレスを設定できます。セキュリティの観点から、最初から出金先アドレスは設定しておいた方がよいです。後日設定する場合はバックアップフレーズを再入力する必要があり労力と神経を消耗するので、報酬を貯めておく特別な理由がない限りは今設定しましょう。出金先アドレスは1度設定すると変更できないため、アドレスの所有権を失わないように注意してください。

5. 案内に従ってkeystoreにパスワードを設定する。24個の英単語のバックアップフレーズは紙にメモし、安全な場所に保管してください！くれぐれもインターネットに接続されている環境に保存しないでください！！出金先アドレスが未設定の時にバックアップフレーズを盗まれたらETHを失ったと思ってください！！！（出金先アドレスが設定されていれば、バックアップフレーズを盗まれてもそこまでの痛手はないです）
   
   動物のサイの絵が表示されたら完了です。~/eth2.0-deposit-cli/validator_keysに2種類のファイルが作成されます。
   deposit_data ⇒ 担保のETHをデポジットする際に使用するファイルで、複数のバリデーターを運用する場合であっても1つだけ作成されます。
   keystore ⇒ バリデーターのウォレットを作成するときに使用するファイルで、複数のバリデーターを運用する場合はバリデーターの数だけ作成されます。
   
   正式なファイル名にはdeposit_data-1615115954.jsonのように作成時の時刻が含まれているため、以下のコマンドで確認してください。deposit_dataを開き、withdrawal_credentialsに出金先アドレスが正しく表示されていることを確認しておくと安心です。

ls ~/eth2.0-deposit-cli/validator_keys

nano ~/eth2.0-deposit-cli/validator_keys/deposit_data-XXXXXXXXXX.json

※ バックアップフレーズは出金先アドレスを設定する時（未設定の場合）や、Keystoreファイルを復元する時に使います。バックアップフレーズとKeystoreファイルを紛失したらどうなるのかを表にまとめました。とりあえず出金先アドレスが設定されていれば最悪の事態は免れます。KeystoreファイルはUSBに予備をコピーしておくといいです。

	バックアップフレーズ所持	バックアップフレーズ紛失
Keystoreファイル所持	GOOD!	Keystoreファイルを紛失する前に、バリデーターを退出させましょう。退出すると出金先アドレスに全額返金されます。出金先アドレスを設定していない場合はほぼゲームオーバーです。サーバーを引き続き稼働し、ブロック生成時の手数料のみ受け取り続けることができますが取るに足らない額です。
Keystoreファイル紛失 （サーバーのSSD故障等）	バックアップフレーズでKeystoreファイルを復元し、できる限り早くバリデーターを復旧させましょう。	バリデーターを再稼働する手段がないため、32ETHが削られていくのを黙って見ることしかできないです。出金先アドレスが設定されていれば16ETHを下回った時点で自動的に返金されます。出金先アドレスが設定されていなければゲームオーバーです。

6. USBかSFTPを使用してdeposit_dataをWindowsに送る。
   以下はSFTPを使った場合のWindowsで実行するコマンドです。

sftp -i SSH用の秘密鍵のディレクトリ -P ポート番号 サーバーユーザ名@サーバーIP
# 例
sftp -i /home/myuser/key -P 1234 ethereum@192.168.0.99

get ~/eth2.0-deposit-cli/validator_keys/deposit_data-XXXXXXXXXX.json deposit_data.json

7. Windowsでイーサリアムの公式ローンチパッドを開き、「BECOME A VALIDATOR」をクリックし、案内に従いdeposit_dataをアップロードして32 ETHをデポジットする。デポジットする時の案内で出金先アドレスを聞かれますが、deposit_dataに既に記載されているため改めての入力は不要です。
   デポジット後はビーコンチェーンにデポジットが認可されるまで10時間以上かかるため、それまでに手順7の「バリデーターを設定する」を完了させてバリデーターをオンラインにしておいてください。

8. ビーコンノードを停止し、ログイン中のユーザーethereumにバリデーターのウォレットを保存するディレクトリの権限を与える。

sudo systemctl stop lighthousebeacon

sudo chown -R ethereum:ethereum /var/lib/lighthouse

9. バリデーターのウォレットを作成する。

cd /usr/local/bin

lighthouse account validator import --network mainnet --directory $HOME/eth2.0-deposit-cli/validator_keys --datadir /var/lib/lighthouse

10. バリデーターのウォレットが作成されていることを確認する。

lighthouse account_manager validator list --network mainnet --datadir /var/lib/lighthouse

11. ウォレットのディレクトリ権限をユーザーethereumから剥奪し、ビーコンノードを再開する。

sudo chown root:root /var/lib/lighthouse

sudo chown -R lighthousebeacon:lighthousebeacon /var/lib/lighthouse/beacon

sudo systemctl start lighthousebeacon

7. バリデーターを設定する

取引の記録係であるバリデーターを設定し、常に起動されている状態にします。

1. バリデーター実行用のユーザーを作成する。

sudo useradd --no-create-home --shell /bin/false lighthousevalidator

2. ユーザーlighthousevalidatorにディレクトリ権限を与える。

sudo chown -R lighthousevalidator:lighthousevalidator /var/lib/lighthouse/validators

3. サーバー起動時にバリデーターが自動的に実行されるためのserviceファイルを作成する。

sudo nano /etc/systemd/system/lighthousevalidator.service

4. 以下を入力し、保存する。（Ctrl + O で保存、Ctrl + X で閉じる）

[Unit]
Description=Lighthouse Validator
Wants=network-online.target
After=network-online.target

[Service]
User=lighthousevalidator
Group=lighthousevalidator
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse vc \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --suggested-fee-recipient FeeRecipientAddress

[Install]
WantedBy=multi-user.target

※ --suggested-fee-recipientにはブロック生成時に貰える手数料の受取先となるアドレスを指定してください。（例：--suggested-fee-recipient 0xABC...）

※ バリデーターごとに異なる手数料の受信先を設定する場合は、--suggested-fee-recipientフラグを使わず、validator_definitions.ymlに追記してください。詳細は公式Documentを参照。

※ Graffitiとは、ブロック生成をした際に記念に文字列をブロックに刻む機能です。自分は特に入力したい文字列がないので利用していません。Graffitiを設定したい場合は、ExecStartに--graffiti "hello world!"のように追加します。xy座標と色コードを入力することでGraffiti Wallにピクセル単位で絵を描くことも可能です。

5. systemdをリロードし、バリデーターがちゃんと動くか確認する。今後上記のserviceファイルに変更を加えることがあれば、毎回daemonをリロードして変更を適応するようにしてください。
   （active (running)と緑で表示されれば OK、Q で閉じる）

sudo systemctl daemon-reload

sudo systemctl start lighthousevalidator

sudo systemctl status lighthousevalidator

6. サーバー起動時にバリデーターが自動的に実行されるようにする。

sudo systemctl enable lighthousevalidator

7. バリデーターのログを確認する。（Ctrl + Cで閉じる）

sudo journalctl -fu lighthousevalidator

※実行クライアントとビーコンノードの同期が完了していないとバリデーターは仕事をしてくれません。

8. バリデーター確認用のアプリをスマホにインストールする

受け取った累計報酬などをアプリで確認できます。
バリデーターに不具合がありオフラインになってしまったら通知してくれるので便利です。

1. iPhoneの場合はApp Storeから、Androidの場合はPlay StoreからBeaconchain Dashboardというアプリをダウンロードします。

2. アプリを開き、Validatorsタブから自身のバリデーターを検索し、お気に入りに登録する。ビーコンチェーンにデポジットが認可されるまで検索できないので10時間以上待つ必要があります。デポジット元のアドレス、バリデーターのパブリックアドレス、または自動採番されるバリデーター番号で検索が可能です。

3. Preferencesで受け取りたい通知の種類を選択する。
   実行クライアントとコンセンサスクライアントのアップデート通知は受け取るようにした方がいいです。マイナーなアップデートであれば急いで適応する必要はないため、アップデートがリリースされる度に各クライアントの公式Githubでアップデートの優先度を確認するか、各クライアントのDiscordでアナウンスを受け取るようにしましょう。

※1日に数回「Attestation Missed」という通知が来ることがありますが心配しないでください。ブロック生成をするバリデーターのせいで自分ではどうしようもないことが多いです。Attestation Effectivenessが98%以上であれば正常です。常に95%以下の場合はサーバーの設定に原因がありそうです。

9. (未設定の場合) 出金先アドレスの設定

出金には報酬部分のみを出金する「Partial Withdrawal」と、ステーキングをやめて担保の32ETHも含め全額出金する「Full Withdrawal」の2通りがあります。

出金先アドレスを設定すると自動的に「Partial Withdrawal」が約1週間に1度実施されるようになります。出金先アドレスが設定されている状態でバリデーターを退出させると「Full Withdrawal」がトリガーされ全額出金されます。

32ETHをデポジットする際にeth2.0-deposit-cliで--eth1_withdrawal_addressフラグを使って既に出金先アドレスを設定している場合はこの手順は不要です。

自分のバリデーターに出金先アドレスが既に設定されているか確認する方法は以下の通りです。

1. beaconcha.inで自分のバリデーターを検索する。
2. Depositsタブを開く。
3. Beaconchain DepositsのWithdrawal Credentialsが0x00から始まっていれば出金先アドレスは設定されていません。0x01から始まっていれば出金先アドレスが設定されています。

出金先アドレスを設定する方法は以下の通りです。
出金先アドレスを1度設定すると変更できないので注意してください。

1. 最新のEthdoのバイナリをダウンロードする。
   Ethdoの最新バージョンのURLは公式Githubから取得してください。

cd ~

curl -LO https://github.com/wealdtech/ethdo/releases/download/vX.XX.X/ethdo-X.XX.X-linux-amd64.tar.gz

tar xvf ethdo-X.XX.X-linux-amd64.tar.gz

rm ethdo-X.XX.X-linux-amd64.tar.gz

2. ethdoがビーコンノードと通信できるか確認する。結果はSyncing: falseとなっていればよいです。trueの場合はビーコンノードの同期が終わるのを待ってください。

~/ethdo node info --verbose

3. バックアップフレーズはエアギャップされたパソコンで入力したいため、オフラインで作業するためのファイルを作成します。ビーコンノードからバリデーターの情報が抽出され、offline-preparation.jsonというファイルが作成されます。

~/ethdo validator credentials set --prepare-offline

4. エアギャップするパソコンにEthdoをダウンロードし、USB経由でoffline-preparation.jsonをEthdoと同じディレクトリにコピーしてください。ファイル名は変更しないでください。次の手順に進む前にパソコンをエアギャップしてください。

5. バックアップフレーズと出金先アドレスを下記のコマンドに代入して実行するとchange-operations.jsonというファイルが作成されます。

~/ethdo validator credentials set --offline --mnemonic="abandon abandon abandon … art" --withdrawal-address=0x0123…cdef

6. change-operations.jsonを開き、validator_indexとto_execution_addressが正しいことをダブルチェクしてください。同じバックアップフレーズから設定したバリデーターが複数ある場合は、全てのバリデーターが羅列されていることも確認してください。

nano change-operations.json

7. USB経由でchange-operations.jsonをサーバーのEthdoと同じディレクトリにコピーしてください。ファイル名は変更しないでください。コピー後は、エアギャップしたパソコンをインターネットに再度つなげることなく初期化してください。

8. サーバーで以下のコマンド実行すると出金先アドレスがビーコンチェーンに送信されます。lighthousebeaconのログでINFO Processed BLS to execution changeが表示されていればビーコンチェーンに送信されています。

~/ethdo validator credentials set

※ Slot(12秒)ごとに最大16個の出金アドレス設定が処理されているため、ビーコンチェーンに送信されたとしても、実際に処理されるまで順番待ちになる場合があります。以下のコマンドで自分のバリデーターが出力されれば正常に送信されています。順番待ちはLIFO（後入れ先出し）のため、割り込まれることがあります。

curl -s "http://localhost:5052/eth/v1/beacon/pool/bls_to_execution_changes" | jq '.data | map(select(.message.validator_index=="<バリデーター番号>"))'

# 順番待ちの総数
 curl -s "http://localhost:5052/eth/v1/beacon/pool/bls_to_execution_changes" | jq '.data | length'

9. 正常に出金先アドレスが設定できたか確認します。
   BLS credentialsと表示される場合はまだ出金アドレスが設定されていません。

~/ethdo validator credentials get --validator=バリデーターの公開鍵

10. (任意) MEV-Boostを設定する

ブロックに含めるトランザクションを選り好みしたり、他人のアビトラ取引をコピーして先に実行したり(フロントランニング)することで、ブロック生成時により多くの手数料を貰うことが可能となります。ただし、本来ブロックに含まれるトランザクションが含まれなくなるため、ブロックチェーンのポリシーである非中央集権から遠ざかる可能性が出てきます。

そのため、イーサリアムではブロックを実際に生成する「Proposer (プロポーザー)」の機能と、ブロックに含める取引を決める「Builder (ビルダー)」の機能を独立させる「Proposer/Builder Separation (プロポーザー/ビルダーセパレーション)」というアプローチがとられています。本記事の手順7で設定したバリデーターが「Proposer」に該当し、これから設定するMEV relayが「Builder」とコミュニケーションを取る設定になります。

代表的な「Builder」は以下の通りです。

• Flashbotsチームが開発しているMEV relay (OFAC準拠)
• bloXroute Labsが開発しているmax-profit relay (検閲なし)
• Ultrasound.moneyチームが開発しているultra sound relay (検閲なし)

オススメは検閲なしで報酬もそこそこいいultra sound relayです。

1. 最新のmev-boostのバイナリをダウンロードする。
   mev-boostの最新バージョンのURLは公式サイトから取得してください。

cd ~

curl -LO https://github.com/flashbots/mev-boost/releases/download/vX.X.X/mev-boost_X.X.X_linux_amd64.tar.gz

tar xvf mev-boost_X.X.X_linux_amd64.tar.gz

rm mev-boost_X.X.X_linux_amd64.tar.gz

rm LICENSE

rm README.md

2. MEV-boostを/usr/local/binにコピーする。

sudo cp ~/mev-boost /usr/local/bin

rm mev-boost

3. MEV-boost実行用のユーザーを作成する。

sudo useradd --no-create-home --shell /bin/false mev

4. サーバー起動時にmev-boostが自動的に実行されるためのserviceファイルを作成する。

sudo nano /etc/systemd/system/mev-boost.service

5. 以下を入力し、保存する。（Ctrl + O で保存、Ctrl + X で閉じる）

[Unit]
Description=MEV-boost
Wants=network-online.target
After=network-online.target

[Service]
User=mev
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/mev-boost \
  -mainnet \
  -relay-check \
  -relays https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money \
  -min-bid 0.05

[Install]
WantedBy=multi-user.target

※複数のrelayを設定する場合は、-relaysにスペースなしのコンマで繋げてください。（例：-relays https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money,https://0x8b5d2e73e2a3a55c6c87b8b6eb92e0149a125c852751db1422fa951e42a09b82c142c3ea98d0d9930b056a3bc9896b8f@bloxroute.max-profit.blxrbdn.com）

※複数のrelayを設定した場合は、より多くの報酬が得られるrelayがブロック生成時に選ばれます。

※ -min-bidを設定した場合、relayからの最高報酬が任意の閾値以下であればrelayを使用せずにローカルの実行クライアントがブロックを生成します。閾値を0.05ETH程度にすることでrelayのみを使用するより分散性を上げることができ、報酬もほとんど下がりません。

6. systemdをリロードし、mev-boostがちゃんと動くか確認する。今後上記のserviceファイルに変更を加えることがあれば、毎回daemonをリロードして変更を適応するようにしてください。
   （active (running)と緑で表示されれば OK、Q で閉じる）

sudo systemctl daemon-reload

sudo systemctl start mev-boost

sudo systemctl status mev-boost

7. サーバー起動時にMEV-boostが自動的に実行されるようにする。

sudo systemctl enable mev-boost

8. ビーコンノードのserviceファイルのExecStartに--builder http://localhost:18550を追加する。

sudo nano /etc/systemd/system/lighthousebeacon.service

[Unit]
Description=Lighthouse Beacon Node
Wants=network-online.target
After=network-online.target

[Service]
User=lighthousebeacon
Group=lighthousebeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --http \
  --execution-endpoint http://localhost:8551 \
  --execution-jwt /var/lib/jwtsecret/jwt.hex \
  --builder http://localhost:18550

[Install]
WantedBy=multi-user.target

9. バリデーターのserviceファイルのExecStartに--builder-proposalsを追加する。

sudo nano /etc/systemd/system/lighthousevalidator.service

[Unit]
Description=Lighthouse Validator
Wants=network-online.target
After=network-online.target

[Service]
User=lighthousevalidator
Group=lighthousevalidator
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse vc \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --suggested-fee-recipient FeeRecipientAddress \
  --builder-proposals

[Install]
WantedBy=multi-user.target

10. ビーコンノードとバリデーターを再起動する。

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl daemon-reload

sudo systemctl start lighthousebeacon

sudo systemctl start lighthousevalidator

11. 正常にバリデーターがRelayに登録されているか確認します。確認方法はrelayによって異なります。ultra sound relayの場合は、公式サイトの右上の「CHECK REGISTRATION」に自分のバリデーターの公開鍵を入力して「check」を押してください。

動作確認するときのコマンド

ログを確認する。

sudo journalctl -fu geth

sudo journalctl -fu lighthousebeacon

sudo journalctl -fu lighthousevalidator

sudo journalctl -fu mev-boost

# 指定した時刻以降のログを出力（現在時刻はdateで確認）
sudo journalctl -u geth --since="2021-02-23 12:30:00"

# ログの容量を確認
sudo journalctl --disk-usage
# 3日以上経ったログを削除
sudo journalctl --vacuum-time=3d

時刻の同期（NTP）を確認する。

ntpq -pn -c rv

CPU、メモリの使用量を確認する。

htop

NVMeの温度を確認する。

sudo nvme smart-log /dev/nvme0n1

SSD使用率を確認する。
Gethのプルーニング（いらないデータの削ぎ落とし）の方法はこちらを参照してください。

df -h

データ通信料を確認する。

# RXが受信量、TXが送信量（サーバー起動してからの累計）
ifconfig

# サーバー起動日数
uptime

クライアントのアップデート方法

geth（実行クライアント）のアップデート方法

1. サーバーのバージョンと公式サイトのバージョンを確認し、アップデートの必要があるか確認する。

/usr/local/bin/geth version

2. Gethの公式サイトを開き、「Geth X.XX.XX for Linux」のボタンを右クリックし、URLをコピーする。

3. Gethをダウンロードする。上記で取得した最新のURLを使用してください。

cd ~

curl -LO https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

4. 実行中のgethを止め、止まっていることを確認する。

sudo systemctl stop geth

sudo systemctl status geth

5. 解凍して/usr/local/binにコピーし、不要になったファイルを削除する。

tar xvf geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

cd geth-linux-amd64-X.XX.XX-XXXXXXXX

sudo cp geth /usr/local/bin

/usr/local/bin/geth version

cd ~

rm -r geth-linux-amd64-X.XX.XX-XXXXXXXX

rm geth-linux-amd64-X.XX.XX-XXXXXXXX.tar.gz

6. gethを起動する。

sudo systemctl start geth

7. gethがちゃんと動いていることを確認する。

sudo journalctl -fu geth

Lighthouse（コンセンサスクライアント）のアップデート方法

1. サーバーのバージョンと公式GitHubのバージョンを確認し、アップデートの必要があるか確認する。

/usr/local/bin/lighthouse --version

2. 最新のLighthouseをダウンロードする。最新バージョンのURLは公式GitHubから取得してください。

cd ~

curl -LO https://github.com/sigp/lighthouse/releases/download/vX.X.X/lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

3. ビーコンノードとバリデーターを止め、止まっていることを確認する。

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl status lighthousevalidator

sudo systemctl status lighthousebeacon

4. 解凍して/usr/local/binにコピーし、不要になったファイルを削除する。

tar xvf lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

sudo cp lighthouse /usr/local/bin

/usr/local/bin/lighthouse --version

rm lighthouse

rm lighthouse-vX.X.X-x86_64-unknown-linux-gnu.tar.gz

5. ビーコンノードとバリデーターを起動する。

sudo systemctl start lighthousebeacon

sudo systemctl start lighthousevalidator

6. ビーコンノードとバリデーターがちゃんと動いていることを確認する。

sudo journalctl -fu lighthousebeacon

sudo journalctl -fu lighthousevalidator

MEV-boostのアップデート方法

1. 実行中のMEV-boostを停止する。

sudo systemctl stop mev-boost

2. 最新のMEV-boostをインストールし、/usr/local/binにコピーする。

export PATH=$PATH:/usr/local/go/bin

go install github.com/flashbots/mev-boost@latest

sudo cp ~/go/bin/mev-boost /usr/local/bin

/usr/local/bin/mev-boost -version

sudo rm ~/go/bin/mev-boost

3. MEV-boostを再開する。

sudo systemctl start mev-boost

バリデーターの数を増やす方法

バリデーターの数を増やすときは、セキュリティを考慮してサーバーとは別のエアギャップしたパソコンを用意してください。エアギャップしたパソコンでバリデーターの鍵を作成し、作成した鍵をUSB経由でサーバーにコピーし、サーバーでウォレットを更新します。

将来的にもっとバリデーターを増やす想定があるのであれば、将来使うであろう鍵もあらかじめ生成してUSBに保管しておくと時短になります。

1. エアギャップ用パソコンにUbuntu Serverを新しくインストールし、鍵生成用のパッケージをインストールします。（この時点まではインターネットに繋いでいます）

sudo apt update && sudo apt upgrade -y

sudo apt install python3-pip git -y

cd ~

git clone https://github.com/ethereum/eth2.0-deposit-cli.git

cd ~/eth2.0-deposit-cli

sudo ./deposit.sh install

2. 有線LANケーブルを抜くなどしてインターネット接続を完全に切断し、パソコンを再起動します。

sudo reboot

3. 初めてバリデーターを設定したときにメモったバックアップフレーズを使用し、追加する1つのバリデーターあたりdeposit_dataとkeystoreを１つずつ作成します。複数のバリデーターの鍵を一度に作ることができますが、ローンチパッドでETHをデポジットする時はどのアドレスにデポジットしたらいいのか迷いやすいため１つずつ作ることをお勧めします。

cd ~/eth2.0-deposit-cli

./deposit.sh existing-mnemonic

4. 作成したdeposit_dataとkeystoreをUSB経由でサーバーにコピーします。

5. ETHのデポジットに使用するパソコンを使い、サーバーからdeposit_dataをSFTPでダウンロードします。

sftp -i SSH用の秘密鍵のディレクトリ -P ポート番号 サーバーユーザ名@サーバーIP
# 例
sftp -i /home/myuser/key -P 1234 ethereum@192.168.0.99

get /home/deposit_data….json deposit_data.json

6. ETHのデポジットに使用するパソコンのブラウザで公式ローンチパッドを開き、deposit_dataをアップロードして追加分のETHをデポジットします。

7. 運用する全てのバリデーターのkeystoreを、サーバーの~/eth2.0-deposit-cli/validator_keysディレクトリに入れます。

8. ビーコンノードとバリデーターを止める。

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl status lighthousevalidator

sudo systemctl status lighthousebeacon

9. 既存のウォレットを削除する。

sudo rm -r /var/lib/lighthouse/validators

10. 新しいバリデーターのウォレットを作成する。パスワードはkeystoreごとに入力します。

cd /usr/local/bin

sudo lighthouse account validator import --network mainnet --directory $HOME/eth2.0-deposit-cli/validator_keys --datadir /var/lib/lighthouse

sudo lighthouse account_manager validator list --network mainnet --datadir /var/lib/lighthouse

11. ウォレットのディレクトリ権限をユーザーlighthousevalidatorに付与する。

sudo chown -R lighthousevalidator:lighthousevalidator /var/lib/lighthouse/validators

12. ビーコンノードとバリデーターを起動する。

sudo systemctl start lighthousebeacon

sudo systemctl status lighthousebeacon

sudo systemctl start lighthousevalidator

sudo systemctl status lighthousevalidator

13. バリデーターが正常に動いていることを確認する。

sudo journalctl -fu lighthousevalidator

14. 鍵の生成に使用したパソコンはインターネットに再度繋げることなくUbuntu Serverを初期化してください。

バリデーターを別のサーバーに移動する方法

バリデーターを別のサーバーに移動する流れは初めてステーキングを開始する流れとほぼ一緒ですが、バリデーターのkeystoreはUSB経由で古いサーバーから新しいサーバーに移動します。

同じkeystoreを読み込んでいるバリデーターを複数同時に起動するとslashingされる（ETHの一部を没収されバリデータの資格を失う）ので絶対にしないでください！！

1. 手順5「イーサリアムのコンセンサス(合意形成)クライアントの同期」までを新しいサーバーで実施します。
2. 新しいサーバーに~/eth2.0-deposit-cli/validator_keysディレクトリを作成し、USB経由でkeystoreを古いサーバーからこのディレクトリにコピーします。
3. 同じバリデーターを２つのサーバーで同時に起動しないため、古いサーバーは初期化してデータを全て削除してください。バリデーターが数十分間オフラインになると思いますが、slashingされるよりはましです。次の手順は急ぎ過ぎず、安全のため少なくとも12分以上（2 epoch以上）はバリデーターをオフラインにしてください。
4. 手順6「ETHをデポジットしてウォレットを作成する」の8番「ビーコンノードを停止し…」から再開し、最後まで実施してください。

予備のサーバーを設定する方法

パソコンやクライアントに異常が生じ、バリデーターがオフラインになると、1つのバリデーターにつき1日あたり約500円のペナルティが課せられます。本来受け取れたはずの500円も含めると、常時オンラインであった場合と比べて約1000円の損失が発生します。仮に5つのバリデーターを運用していた場合、1日あたりの損失は5000円です。

複数のバリデーターを運用している人は、予備のサーバーを設置することを検討してみてください。多少の機器代と電気代がかかったとしても、トータルで見るとリターンが高くなる可能性があります。予備のサーバーは常に稼働させる必要はなく、主要なハードフォークがある時や旅行に行く時に、普段使いのパソコンのSSDを差し替えて予備のサーバーにするだけでも精神的に全然違います。Tailscaleなどを使った外出先からのリモート操作も可能ですが、問題発生後に慌てて対処するより、事前に問題を防いだほうが賢明です。

自分は過去2年半で3回バリデーターがオフラインになった経験があります。1回は4時間ほどで自然に解消し、残り2回はサービスを停止して再起動することで直りました。ログを調べたところ、実行クライアントのチェーンデータに問題があったようですが、問題が発生した明確な原因は分かりませんでした。予備のサーバーがあればオフラインになることを防げた可能性は高いです。

予備のサーバーでは実行クライアントとビーコンノードだけを稼働し、バリデーターは実行しないでください。メインサーバーのバリデーターを予備サーバーのビーコンノードに繋げます。2つのサーバーで同時にバリデーターを起動すると罰則を受けるため、もう一度言いますが予備サーバーではバリデーターを絶対に起動しないでください。

1. ステーキングの開始手順に従い、予備サーバーで実行クライアントとビーコンノードを設定します。当たり前ですが、固定するIPアドレスはメインサーバーと被らないようにしてください。

2. 他のサーバーから予備のビーコンノードにアクセスできるようにするため、予備サーバーのビーコンノードのExecStartに--http-address 0.0.0.0を追加します。

3. メインサーバーのバリデーターのExecStartに--beacon-nodes http://localhost:5052,http://<予備サーバーのIPアドレス>:5052を追加し、両方のサーバーのビーコンノードに接続するようにします。

4. メインサーバーでMEV-Boostを設定している場合は、メインサーバーのufwでポート18550を開放し、予備サーバーのビーコンノードのExecStartに--builder http://<メインサーバーのIPアドレス>:18550を追加します。

5. テストとして、メインサーバーの実行クライアントとビーコンノードを停止し、バリデーターが正常にAttestationを続けるか確認してください。

ダッシュボードの設定方法

サーバーやクライアントの状況をテキストで確認するコマンドを紹介しましたが、グラフ等で表示することも可能です。オープンソースの「Prometheus」というモニタリングツールと「Grafana」というダッシュボードツールを活用します。

1. Gethのserviceファイルを開き、ExecStartに--http --metrics --pprofを追加する。

sudo nano /etc/systemd/system/geth.service

2. ビーコンノードのserviceファイルを開き、ExecStartに--metricsを追加する。

sudo nano /etc/systemd/system/lighthousebeacon.service

3. gethとビーコンノードを再起動する。

sudo systemctl stop geth lighthousebeacon

sudo systemctl daemon-reload

sudo systemctl start geth lighthousebeacon

4. PrometheusとGrafanaをインストールする。

sudo apt install -y prometheus prometheus-node-exporter

sudo apt install -y gnupg2 curl software-properties-common

curl -fsSL https://packages.grafana.com/gpg.key|sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/grafana.gpg

sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"

sudo apt update && sudo apt install -y grafana

5. PrometheusとGrafanaがサーバー起動時に自動的に実行されるようにする。

sudo systemctl enable prometheus.service prometheus-node-exporter.service grafana-server.service

6. sudo nano /etc/prometheus/prometheus.ymlでPrometheusの設定ファイルを開き、中身に下記をコピペして保存する。

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
   - job_name: 'node_exporter'
     static_configs:
       - targets: ['localhost:9100']
   - job_name: 'nodes'
     metrics_path: /metrics
     static_configs:
       - targets: ['localhost:5054']
   - job_name: 'validators'
     metrics_path: /metrics
     static_configs:
       - targets: ['localhost:5064']
   - job_name: 'geth'
     scrape_interval: 15s
     scrape_timeout: 10s
     metrics_path: /debug/metrics/prometheus
     scheme: http
     static_configs:
     - targets: ['localhost:6060']

7. 標準のPrometheusの設定ファイルを上記のファイルに置き換えて、権限を変更する。

sudo mv ~/prometheus.yml /etc/prometheus/prometheus.yml

sudo chmod 644 /etc/prometheus/prometheus.yml

8. サービスを再起動する。

sudo systemctl restart grafana-server.service prometheus.service prometheus-node-exporter.service

9. ポートを解放する。

sudo ufw allow 3000

10. 普段使いのパソコンのブラウザでhttp://<サーバーのIPアドレス>:3000を開く。サーバーに正常にアクセスできていればログイン画面が開くので、ユーザー名とパスワードにはadminを入力する。

11. 左側の歯車ボタンからConfigurationを選択し以下の設定をする。
    • Add Data Sourceをクリック
    • Prometheusをクリック
    • URLにhttp://localhost:9090を入力
    • Save & testをクリック

12. 左側の四角4つのボタンから+ Importを選択し、以下からダウンロードしたjsonファイルをアップロードする。リンクを右クリックして名前を付けて保存をするとダウンロードできます。アップロード時は、PrometheusでPrometheus (default)を選択するのを忘れずに。
    • Lighthouse Beaconのダッシュボードjson
    • Lighthouse Validatorのダッシュボードjson (1)
    • Lighthouse Validatorのダッシュボードjson (2)
    • Gethのダッシュボードjson
    • Node-exporterのダッシュボードjson

ステーキングをやめる手順

バリデーターを退出(Exit)させることで、担保の32ETHも含め全額出金することができます。

前提として出金先アドレスが設定されている必要があります。
まだ設定していない場合は、出金先アドレスの設定を先に実施してください。

1. 動いているバリデーターを止めます。

sudo systemctl stop lighthousevalidator

2. 退出させるバリデーターのkeystoreファイルのパスを下記コマンドに代入し実行します。

/usr/local/bin/lighthouse account validator exit --keystore ~/eth2.0-deposit-cli/validator_keys/keystore-m....json

3. Keystoreファイルのパスワードを入力し、合言葉の入力を求められるので下記を入力します。

Exit my validator

4. 退出されるまではバリデーターの仕事は続くのでバリデーターを起動しておきます。

sudo systemctl start lighthousevalidator

5. 後は待つだけです。
   退出されたら、出金が許可されるまで約27時間待ちます。
   許可されたら、出金の順番待ちがあります。
   
   自分のバリデーターの出金スケジュールはbeaconcha.inから確認できます。
   プロセスの詳細は公式ドキュメントに記載されています。