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

※旧記事です。こっちに引っ越しました。

ステーキングの開始手順

1. Ubuntu Serverのインストール

Ubuntu Serverのインストール方法はこの記事を参照してください。
後で設定するmev-boostはUbuntu Serverのバージョンが24.04 LTSで動作確認済みです。
インストール後は、パッケージを最新の状態にして、ログインしなおしてください。

sudo apt update && sudo apt upgrade -y

exit

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

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

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

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

sudo reboot

3. JSON Web Token の設定

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

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

sudo mkdir -p /var/lib/jwtsecret

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

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

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

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

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

イーサリアムの全トランザクションをダウンロードし、常に最新のトランザクションが同期されるようにします。1TB近くあるのでダウンロードに1日以上かかります。実行クライアントの中ではGethが50%以上のシェアを持っています。自分はネットワークの分散性を上げるためにGethとNethermindを併用しています。

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

sudo apt install curl

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

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

cd ~

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

解凍して/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

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

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

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

sudo mkdir -p /var/lib/goethereum

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

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

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

以下を入力し、保存する。（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は自動的に安全圏までしか使わない仕様になってます。

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

sudo systemctl daemon-reload

sudo systemctl start geth

sudo systemctl status geth

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

sudo systemctl enable geth

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

sudo journalctl -fu geth

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

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

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

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

最新の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

解凍して/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

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

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

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

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

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

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

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

以下を入力して、保存する。（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）。

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

sudo systemctl daemon-reload

sudo systemctl start lighthousebeacon

sudo systemctl status lighthousebeacon

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

sudo systemctl enable lighthousebeacon

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

sudo journalctl -fu lighthousebeacon

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

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

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

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

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

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

cd ~

curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/vX.X.X/staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

鍵生成用のバイナリを解凍し、ディレクトリ名を変更する。

tar xvf staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

rm staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

mv staking_deposit-cli-xxxxxxx-linux-amd64/ staking-deposit-cli/

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

sudo systemctl stop lighthousebeacon

sudo systemctl stop geth

sudo shutdown -h now

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

cd ~/staking-deposit-cli

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

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

案内に従ってkeystoreにパスワードを設定する。24個の英単語のバックアップフレーズは紙にメモし、安全な場所に保管してください！くれぐれもインターネットに接続されている環境に保存しないでください！！出金先アドレスが未設定の時にバックアップフレーズを盗まれたらETHを失ったと思ってください！！！（出金先アドレスが設定されていれば、バックアップフレーズを盗まれてもそこまでの痛手はないです）

動物のサイの絵が表示されたら完了です。~/staking-deposit-cli/validator_keysに2種類のファイルが作成されます。
deposit_data ⇒ 担保のETHをデポジットする際に使用するファイルで、複数のバリデーターを運用する場合であっても1つだけ作成されます。
keystore ⇒ バリデーターのウォレットを作成するときに使用するファイルで、複数のバリデーターを運用する場合はバリデーターの数だけ作成されます。

正式なファイル名にはdeposit_data-1615115954.jsonのように作成時の時刻が含まれているため、以下のコマンドで確認してください。deposit_dataを開き、withdrawal_credentialsに出金先アドレスが正しく表示されていることを確認しておくと安心です。

ls ~/staking-deposit-cli/validator_keys

nano ~/staking-deposit-cli/validator_keys/deposit_data-XXXXXXXXXX.json

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

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

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 ~/staking-deposit-cli/validator_keys/deposit_data-XXXXXXXXXX.json deposit_data.json

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

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

sudo systemctl stop lighthousebeacon

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

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

cd /usr/local/bin

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

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

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

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

sudo chown root:root /var/lib/lighthouse

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

sudo systemctl start lighthousebeacon

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

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

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

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

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

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

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

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

以下を入力し、保存する。（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 \
  --enable-doppelganger-protection

[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にピクセル単位で絵を描くことも可能です。

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

sudo systemctl daemon-reload

sudo systemctl start lighthousevalidator

sudo systemctl status lighthousevalidator

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

sudo systemctl enable lighthousevalidator

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

sudo journalctl -fu lighthousevalidator

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

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

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

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

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

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

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

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

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

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

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

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

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

出金先アドレスを設定する方法は以下の通りです。
出金先アドレスを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

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

~/ethdo node info --verbose

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

~/ethdo validator credentials set --prepare-offline

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

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

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

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

nano change-operations.json

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

サーバーで以下のコマンド実行すると出金先アドレスがビーコンチェーンに送信されます。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'

正常に出金先アドレスが設定できたか確認します。
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です。

最新の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

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

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

rm mev-boost

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

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

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

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

以下を入力し、保存する。（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 \
  -addr "0.0.0.0:18550" \
  -relay-check \
  -relays https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money,https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net,https://0xa7ab7a996c8584251c8f925da3170bdfd6ebc75d50f5ddc4050a6fdc77f2a3b5fce2cc750d0865e05d7228af97d69561@agnostic-relay.net

[Install]
WantedBy=multi-user.target

※relay URLの一覧はここにまとめられてます。

※複数のrelayを設定する場合は、-relaysにスペースなしのコンマで繋げてください。

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

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

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

sudo systemctl daemon-reload

sudo systemctl start mev-boost

sudo systemctl status mev-boost

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

sudo systemctl enable mev-boost

ビーコンノードの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

バリデーターの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

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

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl daemon-reload

sudo systemctl start lighthousebeacon

sudo systemctl start lighthousevalidator

正常にバリデーターが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）を確認する。

chronyc sources

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

htop

NVMeの温度を確認する。

sudo nvme smart-log /dev/nvme0n1

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

df -h

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

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

# サーバー起動日数
uptime

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

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

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

/usr/local/bin/geth version

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

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

cd ~

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

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

sudo systemctl stop geth

sudo systemctl status geth

解凍して/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

gethを起動する。

sudo systemctl start geth

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

sudo journalctl -fu geth

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

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

/usr/local/bin/lighthouse --version

最新の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

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

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl status lighthousevalidator

sudo systemctl status lighthousebeacon

解凍して/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

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

sudo systemctl start lighthousebeacon

sudo systemctl start lighthousevalidator

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

sudo journalctl -fu lighthousebeacon

sudo journalctl -fu lighthousevalidator

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

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

sudo systemctl stop mev-boost

最新の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

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

rm mev-boost

MEV-boostを再開する。

sudo systemctl start mev-boost

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

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

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

エアギャップ用パソコンにUbuntu Serverを新しくインストールし、鍵生成用のバイナリを取得します。（この時点まではインターネットに繋いでいます）最新バージョンのURLは公式Githubから取得してください。

sudo apt update && sudo apt upgrade -y

cd ~

curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/vX.X.X/staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

tar xvf staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

rm staking_deposit-cli-xxxxxxx-linux-amd64.tar.gz

mv staking_deposit-cli-xxxxxxx-linux-amd64/ staking-deposit-cli/

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

sudo reboot

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

cd ~/staking-deposit-cli

./deposit existing-mnemonic

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

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

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

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

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

sudo systemctl stop lighthousevalidator

sudo systemctl stop lighthousebeacon

sudo systemctl status lighthousevalidator

sudo systemctl status lighthousebeacon

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

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

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

cd /usr/local/bin

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

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

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

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

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

sudo systemctl start lighthousebeacon

sudo systemctl status lighthousebeacon

sudo systemctl start lighthousevalidator

sudo systemctl status lighthousevalidator

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

sudo journalctl -fu lighthousevalidator

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

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

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

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

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

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

サーバーに何らかの異常が生じてバリデーターがオフラインになると、1つのバリデーターにつき1日あたり約1,000円のペナルティが課せられます。本来受け取れたはずの1,000円も考慮すると、常時オンラインであった場合と比べて約2,000円の損失が発生します。仮に5つのバリデーターを運用していた場合、1日あたりの損失は10,000円です。

複数のバリデーターを運用している人は、予備のサーバーを設置することを検討してみてください。多少の機器代と電気代がかかったとしても、トータルで見るとリターンが高くなる可能性があります。予備のサーバーは常に稼働させる必要はなく、主要なハードフォークがある時や旅行に行く時に、普段使いのパソコンのSSDを差し替えて予備のサーバーにするだけでも精神的に全然違います。Tailscaleなどを使った外出先からのリモート操作ももちろん設定して欲しいですが、ブロックチェーンデータが破損した場合は、予備のサーバーがないと再同期に１日以上かかってしまいます。

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

自分はメインサーバーでGeth、予備サーバーでNethermindを利用していて、どちらかの実行クライアントでエラーが発生しても別のクライアントでやり過ごせるようにしています。

ステーキングの開始手順に従い、予備サーバーで実行クライアントとビーコンノードを設定します。固定するIPアドレスはメインサーバーと被らないようにしてください。複数のビーコンノードが同じポートを奪い合ってpeer数が少なくなることがあるため、予備サーバーではビーコンノードに--port 9100を追加し、ポート9100と9101を開放したほうがよいです。経験上、実行クライアントはポートが被っても問題が起きにくいですが、予備サーバーのポートを30305に変更してもよいです。

他のサーバーから予備のビーコンノードにアクセスできるようにするため、予備サーバーの実行クライアントのExecStartに--http、ビーコンノードのExecStartに--http-address 0.0.0.0を追加します。また、予備のサーバーでufwポートの8545と5052を開放します。

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

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

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

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

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

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

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

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

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

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

sudo systemctl stop geth lighthousebeacon

sudo systemctl daemon-reload

sudo systemctl start geth lighthousebeacon

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

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

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

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']

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

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

sudo chmod 644 /etc/prometheus/prometheus.yml

サービスを再起動する。

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

ポートを解放する。

sudo ufw allow 3000

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

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

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

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

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

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

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

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

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

Exit my validator

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

後は待つだけです。
退出されたら、出金が許可されるまで約27時間待ちます。
許可されたら、出金の順番待ちがあります。

自分のバリデーターの出金スケジュールはbeaconcha.inから確認できます。
プロセスの詳細は公式ドキュメントに記載されています。