(最終更新2024年6月16日)
目次
- 前提知識
- ステーキングの開始手順
- メンテナンス
- ステーキングをやめる手順
イーサリアムの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は持ってないけれど自宅サーバーでステーキングをしたい方や、ソロステーキングで余った端数を運用したい方は是非参考にしてください。
ステーキングをするメリット・デメリット
ソロステーキングをすることで以下のメリットがあります。
- 約2.5~4%(2024年6月16日現在)の年利報酬を得られる:担保のETHに対して年利約2.5~4%の報酬を得ることができます。バリデーターがオフラインになると罰金となり、オンライン期間とオフライン期間が半々くらいであれば年利報酬がプラマイゼロになります。報酬額は、ネットワーク全体の総バリデーター数とチェーンアクティビティの活発度によって変動しているため、現状はここのオレンジの線を確認してください。運良く高額なMEV報酬を貰うバリデーターがいるため、平均値であるオレンジの線より中央値はもう少し低くなります。
貰える報酬には、(A)常に貰える報酬と(B)ブロック生成をすると貰える報酬があります。
(A)ブロックの中身を認証(“attestation”)することで貰える報酬です。全てのブロックを認証するわけではなく、6.4分(1エポック = 32ブロック)に1回認証します。また、確率は低いですが27時間毎にランダムに選ばれた512個のバリデーターはsync committeeという役割を果たします。1つのバリデーターあたり約5年に1度選ばれる程度ですが、選ばれた際は27時間attestation報酬が約50倍になります。
(B)ブロック生成をするバリデーターはランダムで選ばれているため、貰えるブロック生成報酬には個人差があります。平均で1つのバリデーターあたり135日に1回ほどブロック生成できますが(現役バリデーター数977,700 ÷ 1日のブロック数7,200)、運が悪いと1年以上ブロック生成できない場合もあります。1回のブロック生成で1ETH以上のMEV報酬を貰えることがありますが、確率としてはとても低いので宝くじ感覚で楽しみにしておきましょう。
正確な報酬内訳は(attestation報酬 * オンライン割合 * sync committee倍率) + (proposal reward + whistleblowing + fee + MEV)となります。attestation rewardは常に貰え、後半の4つはブロック生成時に貰えます。 - イーサリアムのセキュリティを上げることに貢献する:個人でバリデーターを運用する人が増えるとイーサリアムのセキュリティは上がります。単なる投資手段としてステーキングする人には関係のない話かもしれません。
- サーバー知識が増える:自宅サーバーでステーキングするため、Linuxのサーバー知識が増えます。仕事や副業に活かせるかもしれません。
- 楽しい:個人的な意見ですが結構楽しいです。ネットワーク保全に関与している誇らしさを感じるだけでなく、証券会社や銀行に頼らずに配当所得のようなものを得ている斬新さや、最新の技術に触れているワクワクを感じています。
逆に、ステーキングのデメリットは以下の通りです。
- 32ETHの単位でしかステーキングできない:ソロステーキングでは1つのバリデーターあたり32ETHを担保としてデポジットします。2024年6月16日現在の価格で約1790万円です。
- 担保のETHは引き出しに時間がかかる:ステーキングを辞める際は資金が戻ってくるまでに数日かかります。ソロステーキングは比較的安全に年利数%の報酬を得ることができますが、もっと高い利率で稼げる一部の玄人にとっては機会損失になる可能性があります。
- 担保のETHを失う可能性がある:複数のサーバーで同じバリデーターを実行するなど、不正とみなされる行為をすると、担保のETHの一部を没収され強制的に退場させられてしまいます。2024年3月4日現在で過去に強制退場させられたバリデーターは約0.03%(退場数435 ÷ 累計バリデーター数1,446,000)です。この記事の通りに運用していれば問題ありません。
また、出金先アドレスを設定せずに24個の英単語からなるバックアップフレーズを紛失したり、間違った出金先アドレスを登録すると資産を引き出せなくなります。出金先アドレスは必ず設定するようにしましょう。 - メンテナンスをする必要がある:初期設定に加え、クライアントのアップデート等のメンテナンスをする必要があります。自分が過去半年でメンテナンスに費やした時間はトータルで2時間くらいです。
- 質の良いインターネット環境を用意する必要がある:初期設定は数日で1TB以上の通信量を消費します。初期設定後は、ネットワーク遅延によってattestationやブロック生成が失敗することがあります。契約しているプロバイダによっては、転送量規制または速度制限が設けられていたりするので要確認です。戸数の多いマンションは夜間にインターネット速度が落ちるという話を聞きますし、オンラインゲームや動画視聴を家族全員が同時にするような家庭であれば、自宅にサーバーを建てても問題なく動作するかテストネットで確認した方がよいかもしれません。
- 機器代と電気代がかかる:サーバーの機器代として8~15万円の初期投資が必要です。また、パソコンを24時間365日つけっぱなしにするため、月に数百円程度の電気代がかかります。ステーキング報酬に比べると数百円は誤差の範囲です。サーバーの機器代と電気代、およびインターネット代の一部は確定申告の際に経費として計上できます。
ハードウェア構成やシステム操作に自信がない方は、手順5の「イーサリアムのコンセンサス(合意形成)クライアントの同期」まではETHを担保としてデポジットしなくても実践できるので試してみてはいかがでしょうか。また、ETHのデポジットも試してみたい人は、テストネットであればテストネット用のETH(無料)を使用して実践できます。メインネットとテストネットの作業相違点はこちらを参照してください。
自宅サーバーでのステーキングに必要なもの
「サーバー」と聞くと大きなマシンをイメージする人もいるかもしれませんが、ソロステーキングは一般的なパソコンがあれば十分です。自分はPN50というミニPCを冷蔵庫の上に置いています。サーバーの中に担保のETHが保管されているわけではないので、このパソコンは壊れたり盗まれたりしても大丈夫です。
- 最低32 ETH:1つのバリデーターあたり32 ETHを担保としてデポジットします。1つのサーバーで複数のバリデーターを運用することが可能です。
- サーバーとして使用するパソコン:クラウドサーバーという手段もありますが、割高なサーバー代を毎月払うよりも、パソコンを買ってしまって将来的にパーツを流用したり売ったりした方がコスパが良いです。バリデーター数とCPU負荷が比例するのは64個まで且つ64個運用してもそれほどCPU負荷が高くないため、サーバーとなるパソコンは1つあれば十分です。普段使いのパソコンを併用するのではなく、ステーキング専用機を用意してください。推奨性能は以下の通り。
■ 目安としてPassMarkが5000点以上のCPU(消費電力を考慮してTDPが25W以下のCPUをお勧めします。CPUはRyzenではなくIntelの方がLinuxとの互換性によるトラブルが少ないです。)
■ 4TB以上のSSD(HDDは遅すぎて使えません。速度が遅いSSDもあるので動作確認ができているものにした方が安心です。実行クライアントにNethermindを使うのであれば2TBでも足りますが、数年後には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:ブロック生成時にブロック内に含めるトランザクションを外部に選定してもらう機能です。使用するとブロック生成報酬が上がります。
ステーキング開始までの流れは以下の通りです。ダウンロードの待ち時間を含めると2日くらいかかります。実際の作業時間は5時間もないと思います。慣れるとトータル2時間くらいの作業量です。
- Ubuntu Serverのインストール
自宅サーバーとなるパソコンにUbuntu ServerというOSをインストールします。 - Ubuntu Serverの細かい初期設定
Ubuntu Serverのインターネットの設定など、細かい初期設定をします。 - JSON Web Tokenの設定
実行クライアントとコンセンサスクライアントが安全に通信するためのファイルを作成します。 - イーサリアムの実行クライアントの同期
イーサリアムの全トランザクションをダウンロードし、常に最新のトランザクションが同期されるようにします。 - イーサリアムのコンセンサスクライアントの同期
バリデーターに仕事を割り振るために使われるビーコンチェーン(出勤簿のようなもの)をダウンロードし、常に同期されるようにします。Checkpoint syncを使えば同期は数分で終わります。 - ETHのデポジットとウォレット作成
1つのバリデーターあたり32 ETHを担保としてデポジットします。デポジット後にバリデーターのウォレットを作成します。 - バリデーターの設定
取引の記録係であるバリデーターを設定し、常に起動されている状態にします。 - バリデーター確認用アプリのインストール
受け取った累計報酬などをスマホアプリで確認できます。バリデーターがオフラインになった時や、ブロック生成した時に通知してくれます。 - (未設定の場合) 出金先アドレスの設定
ステーキング報酬の送金先を設定すると溜まった報酬が約1週間に1度このアドレスに出金されます。ステーキングをやめる際は、このアドレスに担保の32ETHを含めた全額が出金されます。 - (任意) 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と9001(Lighthouse)を許可してください。
- 正確な時刻の設定:ミリ秒単位で時刻が合っている必要があるためChronyをインストールします。
- IPアドレスの固定:SSHで他のパソコンからサーバーを遠隔操作する場合は、IPアドレスを固定しないと面倒くさいことになります。
- ルーターのポート開放:ルーターによっては、ポート転送の設定をする必要があります。30303(実行クライアント)と9000と9001(Lighthouse)が固定したIPアドレスに転送されるように設定してください。
- SSHの設定:他のパソコンからサーバーを遠隔操作できるようにします。
- (Wifiで運用する場合)Wifiを使えるようにします。
- (32GB以上のメモリを使用している場合)十分なメモリ容量があるため、スワップ処理は無効化した方が処理スピードが上がります。
- (AMDのCPUを使用している場合)処理落ちが発生する場合はこの記事の設定をしてください。
詳細設定の完了後は念のためサーバーを再起動してください。
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
が表示されるようになれば同期完了です。
※ 自分は同期中にM.2のSSDがフリーズすることがありましたがAPST(省電力設定)を無効化したら発生しなくなりました。フリーズすることがあればお試しください。
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
[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 \
-relay-check \
-relays https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money \
-min-bid 0.05
[Install]
WantedBy=multi-user.target
※relay URLの一覧はここにまとめられてます。
※複数のrelayを設定する場合は、-relays
にスペースなしのコンマで繋げてください。(例:-relays https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money,https://0x8b5d2e73e2a3a55c6c87b8b6eb92e0149a125c852751db1422fa951e42a09b82c142c3ea98d0d9930b056a3bc9896b8f@bloxroute.max-profit.blxrbdn.com
)
※複数の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
を1つずつ作成します。複数のバリデーターの鍵を一度に作ることができますが、ローンチパッドでETHをデポジットする時はどのアドレスにデポジットしたらいいのか迷いやすいため1つずつ作ることをお勧めします。
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
を古いサーバーからこのディレクトリにコピーします。 - 同じバリデーターを2つのサーバーで同時に起動しないため、古いサーバーは初期化してデータを全て削除してください。バリデーターが数十分間オフラインになると思いますが、slashingされるよりはましです。次の手順は急ぎ過ぎず、安全のため少なくとも12分以上(2 epoch以上)はバリデーターをオフラインにしてください。
- 手順6「ETHをデポジットしてウォレットを作成する」の8番「ビーコンノードを停止し…」から再開し、最後まで実施してください。
予備のサーバーを設定する方法
サーバーに何らかの異常が生じてバリデーターがオフラインになると、1つのバリデーターにつき1日あたり約1,000円のペナルティが課せられます。本来受け取れたはずの1,000円も考慮すると、常時オンラインであった場合と比べて約2,000円の損失が発生します。仮に5つのバリデーターを運用していた場合、1日あたりの損失は10,000円です。
複数のバリデーターを運用している人は、予備のサーバーを設置することを検討してみてください。多少の機器代と電気代がかかったとしても、トータルで見るとリターンが高くなる可能性があります。予備のサーバーは常に稼働させる必要はなく、主要なハードフォークがある時や旅行に行く時に、普段使いのパソコンのSSDを差し替えて予備のサーバーにするだけでも精神的に全然違います。Tailscaleなどを使った外出先からのリモート操作ももちろん設定して欲しいですが、ブロックチェーンデータが破損した場合は、予備のサーバーがないと再同期に1日以上かかってしまいます。
予備のサーバーでは実行クライアントとビーコンノードだけを稼働し、バリデーターは実行しないでください。メインサーバーのバリデーターを予備サーバーのビーコンノードに繋げます。2つのサーバーで同時にバリデーターを起動すると罰則を受けるため、もう一度言いますが予備サーバーではバリデーターを絶対に起動しないでください。
自分はメインサーバーでGeth、予備サーバーでNethermindを利用していて、どちらかの実行クライアントでエラーが発生しても別のクライアントでやり過ごせるようにしています。
- ステーキングの開始手順に従い、予備サーバーで実行クライアントとビーコンノードを設定します。固定するIPアドレスはメインサーバーと被らないようにしてください。複数のビーコンノードが同じポートを奪い合ってpeer数が少なくなることがあるため、予備サーバーではビーコンノードに
--port 9100
を追加し、ポート9100と9101を開放したほうがよいです。経験上、実行クライアントはポートが被っても問題が起きにくいですが、予備サーバーのポートを30305に変更してもよいです。
- 他のサーバーから予備のビーコンノードにアクセスできるようにするため、予備サーバーのビーコンノードのExecStartに
--http-address 0.0.0.0
を追加します。
- メインサーバーのバリデーターの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も含め全額出金することができます。
前提として出金先アドレスが設定されている必要があります。
まだ設定していない場合は、出金先アドレスの設定を先に実施してください。
- 動いているバリデーターを止めます。
sudo systemctl stop lighthousevalidator
- 退出させるバリデーターの
keystore
ファイルのパスを下記コマンドに代入し実行します。
/usr/local/bin/lighthouse account validator exit --keystore ~/staking-deposit-cli/validator_keys/keystore-m....json
- Keystoreファイルのパスワードを入力し、合言葉の入力を求められるので下記を入力します。
Exit my validator
- 退出されるまではバリデーターの仕事は続くのでバリデーターを起動しておきます。
sudo systemctl start lighthousevalidator
- 後は待つだけです。
退出されたら、出金が許可されるまで約27時間待ちます。
許可されたら、出金の順番待ちがあります。
自分のバリデーターの出金スケジュールはbeaconcha.inから確認できます。
プロセスの詳細は公式ドキュメントに記載されています。