💰

Ethereum Solo Staking 入門 (中編)

2022/10/16に公開

Ethereum

この記事はEthereum Solo Staking 入門 (前編)の続きになります。

この記事では、これらの準備ができていることを前提としています。

Solo Staking用のハードウェア購入
Testnetで用いる32.02 GoETHの取得

Stakingを行うためのノードについて

前編では、クライアントの選定、コミュニティの参加、ハードウェアの用意、Testnet用の32 GoETHの取得が完了しました。それではSolo Stakingを……と言いたいところですが、StakingにはValidatorを機能させるノードの構築が必要です。

Stakingを行うノードは24時間365日安全に動かすことが前提となるため、今回はサーバ構築を「Hardening」と「Monitoring」という観点から行いました。

この記事では、以下の手順に沿って実際のノード構築を行なっていきます。

Ubuntuのインストールについて

特に説明する事はないですが、筆者はUbuntu 22.04 LTS Serverを使用しています。

最近ではUSBディスクをインストールメディアとして利用することもあると思います。ホストマシンがWindows環境ならばRufusを使っても良いですし、ライブUbuntuを利用しても同様にブータブルUSBを用意することもできます。

最近のUbuntuであれば、Githubアカウントを指定することでインストール時に自身のSSH公開鍵を取り込むことができます。サーバをリモートからセットアップする際にこの機能は非常に便利なので、是非利用してみましょう。

Ubuntuのインストールが完了したら、du -hコマンドを実行してディスクの容量が正しく認識されているか確認することをオススメします。

Hardeningについて

Hardeningは日本語で「要塞化」とも呼ばれているセキュリティプロセスで、「サイバー攻撃の手段を取り除くプロセス^[1]」を指します。

わかりやすく言えば、脆弱性対策、不要なサービスの停止、コンフィグの最適化、FWの適切な設定などをプロセスとして含みます。今回は「Ethereumノード」として必要十分な状態になるようにサーバを強化していきます。

Hardeningの結果を客観的に評価するツールとしてはOpenSCAPが有名ですが、Ubuntu 22.04にはまだ対応していないようなので、今回はLynisを利用してスコアを確認します。

Monitoringについて

Monitoringとは、サーバの監視プロセスのことです。特に「監査（audit）」と呼ばれている部分は、セキュリティとも関わりが強い分野になります。

今回はITインフラエンジニア向けの記事なのでMonitoring自体には深入りしませんが、ノードの安定運用にはMonitoringが非常に重要です。一般的なサーバと同様に、Ethereumノードにおいても以下のメトリクスは監視が必要です。

CPU使用率
メモリ使用率
ディスク使用率
ディスクI/O
ネットワークI/O

全て大事ですが、特に失敗しやすいポイントはディスク使用率だと思います。ノード運用では、ブロックチェーンを最新の状態に同期する（syncing）ことが大切ですが、ディスクの空きがなければチェーンを同期することはできません。この状態が継続すると同期できない状態になることが稀にあり、その場合は空き容量を増やしてもエラーが解決しません。最初から同期をやり直す必要があります。

PoSネットワーク上のValidatorノードがオフラインになっている状態をinactiveと呼びますが、Mainnet/Testnet問わずinactiveだとペナルティが発生します。inactiveの場合、ペナルティとして預けたETHが少しずつ減っていきますが、チェーンの同期を最初からやり直すと数時間〜数日かかるため、精神衛生上非常に良くない状態になります。

Ethereumノード固有の最重要メトリクスとしては、

Peers

があります。これはクライアントに接続しているPeerの数を表したものであり、ValidatorノードのAttestation Effectiveness (effectiveness)と呼ばれる評価指標と強い相関^[2]^[3]があるメトリクスです。簡潔にいうと、Peersに問題があると貰えるETHの量が少なくなります。^[4]

クライアントの実行について

今回はeth-dockerを利用します。これを利用することで、実行クライアントとコンセンサスクライアントを一度にセットアップすることが可能になります。公式ドキュメントにも書いてありますが、Stakingをめちゃくちゃ簡単にできるすごいヤツです。

eth-docker aims to make running an Ethereum staking full node simpler than setting everything up manually, while allowing the user choice when it comes to the exact client mix they wish to run.

ただし、手順が簡単になるだけなので、Solo Stakingに必要な知識量が減るわけではない点は注意が必要です。

Ansibleを用いたノードの構築

細かいことは良いからさっさと動かしたい！という人のために、筆者が利用しているミニマムな環境をAnsible Playbookとして公開しています。

特徴は以下の通りです。

devsec.hardeningを利用したHardening
netdataを利用したMonitoring
その他最低限必要なセキュリティ強化や監査ツールの導入
HOMEディレクトリにeth-dockerを自動配置（セットアップ時に最新環境をgit clone）

後述しますが、外部のサービスに発生する通信（IPアドレス特定などの危険性）を許容できる場合、次のような有益なサービスを利用することもできます。

特にbeaconcha.inはSolo Stakingにおいて、ほぼ必須と言って良いサービスだと思います。

Ansibleの実行

それではUbuntuをインストールしてValidatorノードの構築を始めていきます。筆者はUbuntu 22.04 LTS Server上でこれらの作業を行なっています。

該当のレポジトリをgit cloneします。

sudo apt update && apt install git
git clone https://github.com/nitky/stakenode-playbook

ansibleをインストールします。

sudo apt update
sudo apt install ansible

Ansible 2.10以降のバージョンを利用する必要があるため、Ubuntu 20.04の方は以下の手順を実行するかpipインストールを利用してください。

sudo apt update
sudo apt install software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible

Playbookを実行します。デフォルトではHome Stakingを想定しているので、クラウド環境やVPSで動かす方は必要に応じてPlaybookを編集してください。

cd stakenode-playbook
ansible-galaxy install -r ./requirements.yml
ansible-playbook playbooks/stakenode.yml -i inventory/local.yml -K

ここまで動いたらまずは、Netdataが動いているかを確認します。http://[nodeのIPアドレス]:19999でアクセスが可能です。クラウド環境やVPSのFW設定に関しては、各サービスのドキュメントを読むか各サービスのサポートに問い合わせてください。

ノード上で動作するNetdata

eth-dockerによるクライアントの実行

ベースとなる環境が整ったので、eth-dockerを利用してクライアントを起動します。

./ethd configでは、利用するクライアントの種類、MEV Boostの利用、Checkpoint Syncの利用、Rewardsアドレスの設定、Grafanaダッシュボードの利用について聞かれます。基本的にはデフォルトの設定のままで大丈夫ですが、Rewardsアドレスは自身が所有するEOAアドレスを指定してください。

cd ~/eth-docker
sudo ./ethd config

これでBesu+Tekuの動作環境が整いました。クライアントが動作するコンテナを起動して、それぞれのクライアントが正常に動いていることを確認します。

sudo ./ethd start
sudo ./ethd logs -f consensus
sudo ./ethd logs -f execution

TestnetであるGoerliの場合、同期にはおよそ８時間程度かかります。（2022年10月現在）

PoSで利用する鍵の生成

クライアントがチェーンの同期を行なっている間にValidatorが利用する鍵の生成を行います。これらはValidator Keysと呼ばれており、Validator Keysはさらに二種類の鍵に分類されます。

The validator key（以下、validator鍵）：チェーンの操作に利用
The withdrawal key（以下、withdrawal鍵）：ETHの引き出しに利用

詳細は省きますが、PoSで利用する鍵の中でもwithdrawal鍵はめちゃくちゃ大事ということを覚えておけばとりあえずは大丈夫です。withdrawal鍵は1つあれば十分ですが、validator鍵は操作するValidatorの数だけ生成する必要があります。

Testnetで利用する鍵をeth-dockerで生成

それではTestnet用のValidator Keysを作成します。Testnetではありますが、本番と同様にパスワードを入力してニーモニックも検証します。鍵を生成する際、validator鍵がいくつ必要か聞かれますが、運用するValidatorの数を入力すれば大丈夫です。通常であれば、Testnetで運用するValidatorは1台だけになると思います。

# Generate both validator(signing) and withdrawal keys:
sudo docker compose run --rm deposit-cli-new --eth1_withdrawal_address YOURHARDWAREWALLETADDRESS --uid $(id -u)
# Test your mnemonic seed phrase:
# Ensure the deposit_data JSON files are the same.
sudo docker compose run --rm deposit-cli-existing --folder seed_check --eth1_withdrawal_address YOURHARDWAREWALLETADDRESS --uid $(id -u)
diff -s .eth/validator_keys/deposit_data*.json .eth/seed_check/deposit_data*.json
rm .eth/seed_check/*

鍵はeth-dockerフォルダ内の.eth/validator_keysの中に保存されています。先ほど入力した鍵のパスワードを入れてクライアントにインポートします。

# Import keys:
sudo ./ethd keys import
sudo ./ethd keys list

鍵の削除は以下のコマンドで行えます。

sudo ./ethd keys delete YOURVALIDATORPUBLICKEY

eth-dockerが用意しているダッシュボード

Grafanaを利用する選択肢を選んだ場合、http://[nodeのIPアドレス]:3000にアクセスすることでダッシュボードが確認できます。

username: admin
password: admin

クライアントの動作状況が一目でわかるようなダッシュボードが用意されています。
ノード上で動作するダッシュボード

補足：beaconcha.inの利用

恐らくですが、ほとんどのSolo Stakerで利用しているモニタリングサービスとしてbeaconcha.inがあります。これはノードの動作状況やValidatorとしての健全さを確認できるサービスであり、モニタリングに関していえば、正直これだけあれば最低限はなんとかなります。

外出先からValidatorノードの動作状況を確認したい場合、筆者は基本的にbeaconcha.inのスマホアプリを利用しています。このサービスはGoerli上でもMainnetと同様に利用可能であり、本番環境と同じ運用をTestnetで試すことができます。

eth-dockerをbeaconcha.inと連携させるには、eth-dockerフォルダ内の.envを編集する必要があります。

# Beaconcha.in API key for sending client stats. Automatic for Lighthouse and Teku, or with prysm-stats.yml,
# source build only for Prysm as of Sept 2021.
# Specify as just the API key as found at https://beaconcha.in/user/settings#api, and give the machine name separately
BEACON_STATS_API=
BEACON_STATS_MACHINE=

BEACON_STATS_APIで利用するAPIキーは、beaconcha.inのAccount Settingsのページに記載してあります。BEACON_STATS_MACHINEは自身が識別できるValidatorノードの名前を入れてください。通常は、ノードのホスト名をそのまま入れておけば大丈夫です。

beaconcha.inの詳細な利用方法に関しては、Ethereum 2.0 Knowledge Baseをご参照ください。

beaconcha.inで確認できるValidatorの状況

Testnet上でのSolo Staking

長い準備が終わりました。それではTestnet上でSolo Stakingを行なっていきます。

まずは、Solo stake your ETHのページを確認してください。現在まで行った作業の漏れがないか、Stakingのリスクとしてどんなものがあるかを改めて確認していきます。

Get started on the Staking LaunchpadからStart staking on Goerli/Prater testnetのボタンを押してStaking Launchpadのページへ進みます。

書いてある内容を１つずつ丁寧に確認しながら、Stakingのリスクを把握して作業を進めてください。

Upload deposit data の画面になったら、自身が生成した鍵をアップロードします。手順通りに作業していれば、eth-docker/.eth/validator_keysのフォルダ内にdeposit_data-[timestamp].jsonな鍵ファイルがあります。

鍵ファイルをアップロードして32ETH（この場合は32GoETH）をデポジットすることでスマートコントラクト側の準備が完了します。デポジットが処理されValidatorとしての鍵が有効になるには、通常16〜24時間程度必要です。

筆者はこれのせいで、Mainnetでやらかしました。

後編に続く😇

脚注