
Solana バリデータのセットアップ方法
目次
- 用語:Solana バリデータとは?
- はじめに:サーバーハードウェアを用意する
- Solana CLI をローカルにインストールする
- 投票アカウントをセットアップする
- キーペアを作成する
- オプション:出金キーにペーパーウォレットを使用する
- オプション:投票アカウント用のバニティキーを生成する
- キーペアから投票アカウントを作成する
- オプション:コミッションを設定する
- オプション:マルチシグを追加する
- マシンをバリデータサーバーとして設定する
- システムとユーザーのセットアップ
- システムチューニング
- ハードドライブの設定
- バリデータサーバーに Solana CLI をインストールする
- オプション:Jito バリデータクライアントをインストールする
- バリデータ実行スクリプトを作成する
- バリデータが正しく動作していることを確認する
- バリデータをデーモンプロセスとして設定する
- 監視とセキュリティを設定する
- パスワードベース認証を無効にする
- バリデータのアイデンティティキーペア
- Watchtower で監視を設定する
- オプション:コミュニティベースの監視
- オプション:getHealth RPC メソッドによるカスタム監視
- オプション:サードパーティーの監視ソリューション
- バリデータにステークを追加する
- キーペアとステークアカウントを作成する
- バリデータの情報を公開する
- まとめ
- その他のリソース
この記事では、技術的な観点から Solana メインネットバリデータを稼働させる方法に焦点を当てます。継続的な運用を容易にするためのツールと設定を準備しますが、より高度なバリデータ運用は扱いません。また、ステークの獲得や補助金への申請などを含むバリデータ運用の経済性も、この記事の対象外です。なお、バリデータの運用を検討している場合は、Cogent Crypto の Validator Profit Calculatorを使用して、想定シナリオにおけるバリデータの収益を見積もることをおすすめします。
この記事では、Linux の基本的なシステム管理に慣れていることを前提としています。バリデータの運用にプログラマーやシステム管理の専門家である必要はありませんが、ターミナルでのコマンド実行、基本的なシェルスクリプト、設定ファイルの操作には慣れている必要があります。
Linux のシステム管理について詳しくなくても学びたい場合は、Linux Journeyなど、優れた入門リソースが多数あります。
用語:Solana バリデータとは?
Solana CLI ツールスイートには solana-validator バイナリが含まれており、次のことができます。
- Solana クラスターに接続し、現在のクラスター状態を同期する
- 最新の状態を維持するため、スナップショットやその他のクラスターデータを生成、受信、共有する
- クラスターコンセンサスの一環として、新しいブロックを検証するために投票する
- 受信トランザクションを処理し、新しいブロックを生成する
- クラスターデータの照会と新しいトランザクションの送信を可能にする RPC およびイベント駆動型 API を公開する
Solana バリデータは、バリデータネットワークに接続してデータを要求するためクライアント、他のバリデータからの要求を処理してデータを提供するためサーバー、またはノードとも呼ばれます。
RPC ノードは、ネットワーク上のすべての情報を追跡する、ステークされておらず投票を行わない Solana バリデータです。つまり、データ要求に応答するだけで、コンセンサスには参加しません。
「Solana バリデータ」という用語は、ステークされて投票を行う Solana バリデータを運用し、コンセンサスに参加する Solana エコシステム内の事業体を指す場合もあります。
RPC、RPC プロバイダー、バリデータの違いについては、こちらをご覧ください。
はじめに:サーバーハードウェアを用意する
バリデータの運用専用となる高性能なコンピューターが必要です。テストネットとメインネットの両方でバリデータを運用する場合は、もう1台必要になります。現在の最低推奨要件は、12コア/24スレッド、256GB RAM、1TB SSD 2台(可能であれば RAID0)、10GB のインターネット接続です。ハードウェア要件の詳細はこちらで確認できます。
メインネットだけを運用してコストを抑えたい場合でも、Solana Foundation Delegation Program(SFDP)の対象になるにはテストネットバリデータを運用する必要があることに注意してください。
ハードウェアを自分で購入して運用することも、データセンタープロバイダーからレンタルすることもできます(TeraSwitchをおすすめします)。クラウドコンピューティングプロバイダーからレンタルすることもできますが、多くの場合はコストが高すぎ、パフォーマンス上の問題も起きやすいためおすすめしません。Solana Foundation Server Program は、バリデータ運用者がデータセンター事業者からハードウェアを借りやすくすることを目的としています。詳しくはこちらをご覧ください。
ネットワークの分散化に貢献するため、Solana ノードやステークがまだ多くないASNや都市を検討するとよいでしょう。一部のステーキングプールと SFDP では、ASN と都市による分散化に基づいて報酬が提供されます。
現在の主要なデータセンターはこちらで確認できます。
Solana CLI をローカルにインストールする
必要なキーをすべてローカルで生成し、出金キーをバリデータサーバーから切り離して保管できるように、ツールをローカルにインストールすることを強くおすすめします。Solana CLI をローカルにセットアップする手順はこちらで確認できます。
ローカルのコマンドラインでツールを使用できるようになったら、デフォルトでテストネットを参照するように設定します。
$ solana config set --url https://api.testnet.solana.comメインネットでは、次のデフォルトエンドポイントを指定できます。
$ solana config set --url https://api.mainnet-beta.solana.com公開メインネットエンドポイントは、多くの場合リクエストが集中しています。パフォーマンスに満足できない場合は、Helius に登録し、次のように Helius エンドポイントを使用できます。
$ solana config set --url https://mainnet.helius-rpc.com/?api-key=<YOUR-HELIUS-API-KEY>バリデータのセットアップとブートストラップにはトランザクションの実行が必要なため、SOL が入ったウォレットを用意する必要があります。テストネットのセットアップを始めたばかりの場合は、次のコマンドでデフォルトウォレットを作成し、自分に SOL をエアドロップできます。
$ mkdir -p ~/.config/solana
$ solana-keygen new --outfile ~/.config/solana/id.json
$ solana airdrop 1 ~/.config/solana/id.jsonテストネットとメインネットでは異なるウォレットを使用することを強くおすすめします。キー形式が同じため、両方で同じキーを使用できますが、使用しないでください。テストネットとメインネットの資金入りウォレットで同じキーを使用すると、テストネット向けのコマンドを誤ってメインネットで実行しやすくなります。
投票アカウントをセットアップする
バリデータの投票アカウントは、solana create-vote-account コマンドと3つのキーペアを使用して作成します。
- アイデンティティキーペア — バリデータはこのキーペアを使用してネットワーク上で自身を識別し、投票などのトランザクションを送信します。秘密キーはサーバー上に置く必要があるため、投票トランザクションに必要な量(約1 SOL/日)を超える SOL を保持しないことが最も安全です。
- 投票アカウントキーペア — このキーペアは投票アカウント自体を指し、投票アカウントの検索と、それに対するステークの委任に使用します。
create-vote-accountコマンドで秘密キーが必要なのは、必要なキーを所有していることを証明するためだけです。投票アカウントの作成後は、公開キーのみが必要です。これは変更できません。 - 出金キーペア — このキーペアは投票アカウントのマスターキーとして機能し、報酬の出金、アイデンティティキーや出金キーの変更、その他のアカウント操作に使用します。3つの中で最も機密性の高いキーであり、サーバー上で生成したり、サーバーにコピーしたりしないでください。メインネットでは、このキーにペーパーウォレット、ハードウェアウォレット、またはマルチシグを使用することを検討してください。
キーペアを作成する
次のようにテストネット用のキーペアを作成します。
$ solana-keygen new -o identity.json
$ solana-keygen new -o vote.json
$ solana-keygen new -o withdraw.jsonオプション:出金キーにペーパーウォレットを使用する
ペーパーウォレットとは、12語(または24語)のフレーズを紙に書き留め、署名にキーが必要になるたびにキーボードで入力するものです。マルチシグを設定しない場合、投票アカウントへのルートアクセスを提供するメインネットの出金キーには、この追加のセキュリティが適しています。次のコマンドを実行します。
$ solana-keygen new --no-outfile表示されたフレーズを紙に書き留めます。公開キー、キーの作成に使用した正確なコマンド、solana-keygen --version も記録しておくとよいでしょう。パスフレーズを秘密キーに変換する方式には複数の種類があることに注意してください。紙を保管する前に、それを使ってキーにアクセスできることを確認します。
$ solana-keygen verify <PUBKEY> ASK執筆時点では、ASK と prompt:// のプレースホルダーでキーのデコード動作が異なります。どちらが自分のキーで機能するかを必ず把握してください。
キーを書き留めた紙は、絶対に紛失しないでください。他に復元する方法はありません。ターミナルのバッファーからキーフレーズを消去することも忘れないでください。
オプション:投票アカウント用のバニティキーを生成する
一部のバリデータでは、アイデンティティキーや投票アカウントキーにバニティ公開キーを使用しています。たとえば、Helius バリデータでは、アイデンティティキーに HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU、投票アカウントに he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk を使用しています。これらは、grind サブコマンドで次のように作成します。
$ solana-keygen grind --starts-with PREF1X:1このサブコマンドは、公開キーが PREF1X で始まるキーを生成します。ここには任意の有効な base58 文字列を指定できます。条件に一致するキーが見つかるまで生成を繰り返すため、必要なプレフィックスの長さに応じて所要時間が指数関数的に増加します。
投票アカウントキーは変更できません。特に、公開して他の人がステークを委任し始めた後は変更できないため、バニティキーが必要なら今作成してください。
キーペアから投票アカウントを作成する
キーペアの準備ができたら、次のように投票アカウントを作成します。
$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json withdrawal.jsonここで、vote_account.json は投票アカウントのキーペア、identity.json はバリデータのアイデンティティキーペア、withdrawal.json は出金権限のキーペア、~/.config/solana/id.json は投票アカウントの作成費用を支払うための SOL が入ったウォレットです。
出金キーペアにペーパーウォレットを使用した場合、コマンドは次のようになります。
$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json ASK次のコマンドで、投票アカウント(または任意の投票アカウント)を確認できます。
$ solana vote-account <PUBKEY>この時点で、バリデータサーバーの実行にはアイデンティティキーペアが必要です。出金キーペアは秘密に保ち、投票アカウントからの出金と変更にのみ使用します。投票アカウントキーペアは不要になりますが、公開キーは忘れないでください。
投票アカウントの詳細はこちらで確認できます。
オプション:コミッションを設定する
create-vote-account ではコミッションをオプションパラメーターとして指定できますが、デフォルトは100%であり、バリデータが非公開であることを意味します。メインネットバリデータに外部からステークを集めたい場合は、より低いコミッションを選ぶ必要があるでしょう。
投票アカウントの公開キーが <VOTE_ACCT_PUBKEY>、変更費用を資金入りの id.json ウォレットから支払い、出金キーにペーパーウォレットを使用し、コミッションを8%に設定する場合は、次のように実行できます。
$ solana vote-update-commission --fee-payer ~/.config/solana/id.json <VOTE_ACCT_PUBKEY> 8 ASKオプション:マルチシグを追加する
マルチシグは、トランザクションの実行に1つ以上の他のウォレットの署名を必要とする特殊なウォレットです。複数人で投票アカウントを共同管理するために使用できます。バリデータを自分だけで管理している場合でも、後から投票アカウントに他の人を簡単に追加できるよう、マルチシグを検討するとよいでしょう。
Squadsは Solana 向けのマルチシグツールで、共有バリデータの管理に特化した機能を備えています。Squads でバリデータをセットアップする手順は次のとおりです。
- Backpackなど、対応する Solana ウォレットプラグインをブラウザーにセットアップします
- Squads dAppに移動します
- バリデータに必要なメンバーとパラメーターを指定して squad を設定します
- Developers > Validators に移動し、フローに従ってバリデータを追加します
- 出金秘密キーの貼り付けを求められます。このキーは、既存の出金キーを squad の共有出金キーに変更するために使用されます
solana vote-accountを使用して、更新された出金公開キーを確認します
Squads を使用したバリデータの共同管理については、こちらをご覧ください。
マシンをバリデータサーバーとして設定する
手順はマシンの初期状態によって異なりますが、最終的には次の状態を目指します。
- Ubuntu の最新 LTS バージョンがインストールされ、最新の状態になっている
- 他の Linux ディストリビューション(Debian ベースなど)でも動作する可能性がありますが、ここでの例はすべて Ubuntu を前提としています。Ubuntu から離れるほど、コマンドの変更が多く必要になります
- ユーザーレベルの SSH アクセスが設定されている
solサービスユーザーが設定されている- システムチューニングとハードディスクの設定が完了している
システムとユーザーのセットアップ
システムが最新であることを確認し、sol サービスユーザーを作成します。
$ sudo apt update
$ sudo apt upgrade
$ sudo adduser solsudo アクセスを付与することもできます(利便性と引き換えにセキュリティが若干低下します)。
$ sudo adduser sol sudoシステムチューニング
Solana Labs が推奨する設定を sysctl と systemd に追加し、許可されるファイルディスクリプター数やメモリマップファイル数などの上限を引き上げます。バリデータが現在または次のブロックリーダーになると、ネットワーク全体が接続を開いてトランザクションを送信しようとするため、特にファイルディスクリプターの上限が重要です。
ハードドライブの設定
Solana Labs の現在の推奨構成は、1TB 以上の物理 SSD を2台用意し、1台をアカウントデータ用、もう1台を台帳データ用にすることです(OS もこのディスクに配置できます)。IOPS が高いため、アカウントと台帳を同じディスクに配置することは推奨されていません。
複数のドライブを活用して利用可能な IOPS を増やす別の方法として、単一の RAID0 ボリュームにまとめ、RAID コントローラーにストライプの保存先を最適化させ、両方のドライブの IOPS 容量を最大化する方法があります。必要に応じて RAID にドライブを追加し、IOPS をさらに高めることもできます。当社では、この構成でバリデータを運用していて、これまでパフォーマンス上の問題は発生していません。
単一の RAID0 ボリュームを使用する場合は、そのボリューム上にバリデータのデータディレクトリをセットアップするだけです。sol ユーザーのホーム直下に作成できます。
$ sudo su sol
$ mkdir -p /home/sol/accounts
$ mkdir -p /home/sol/ledger
$ mkdir -p /home/sol/snapshots
$ mkdir -p /home/sol/logsバリデータサーバーに Solana CLI をインストールする
上記の手順を繰り返して Solana CLI をインストールします。ただし、今回はバリデータサーバー上で sol ユーザーとして実行します。バリデータサーバーにインストールする際は、ソースからビルドすることを強くおすすめします。
Solana インストールツールを使用する場合は、solana-install コマンドを使って、今後新しいバージョンに更新できます。クラスターへの参加を継続するには更新が必要です。
オプション:Jito バリデータクライアントをインストールする
Jito Labsは Solana バリデータをフォークし、Maximal Extractable Value(MEV)機能を追加した独自バージョンを公開しています。MEVとは、利益を得るために、自分が作成するブロック内でトランザクションを追加または並べ替える考え方です。Jito は、そのために追加料金を支払いたい人々(「サーチャー」)向けの市場を構築しました。Jito バリデータを運用すると、追加のチップと引き換えに、バリデータが生成するブロックへ組み込む MEV トランザクションバンドルが送信されます。
Jito バリデータはバリデータ運用の複雑さとレイテンシを増やしますが、追加収益源として MEV チップを得られます。設定の大部分は同じですが、さらに次の項目を確認する必要があります。
- MEV チップの回収と管理
- Jito ブロックエンジンによるレイテンシ
- 必要に応じた Jito リレイヤーの運用
Jito のバリデータクライアントをインストールする手順はこちらで確認できます。
バリデータ実行スクリプトを作成する
validator.sh シェルスクリプトを作成する
まず、バリデータのアイデンティティキーペアをリモートサーバーにコピーします。
$ scp identity.json remoteuser@your.validator.host:/home/solバリデータの設定を管理する標準的な方法は、シェルスクリプトでラップすることです。出発点となるスクリプトを作成し、実行可能にします。
$ sudo su sol
$ cat >/home/sol/validator.sh <<EOF
#!/bin/bash
PATH=/home/sol/.local/share/solana/install/active_release/bin:$PATH
exec solana-validator \
--identity /home/sol/identity.json \
--vote-account <VOTE_ACCOUNT_PUBKEY> \
--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
--only-known-rpc \
--log /home/sol/logs/solana-validator.log \
--accounts /home/sol/accounts \
--snapshots /home/sol/snapshots \
--ledger /home/sol/ledger \
--rpc-port 8899 \
--dynamic-port-range 8000-8020 \
--entrypoint entrypoint.testnet.solana.com:8001 \
--entrypoint entrypoint2.testnet.solana.com:8001 \
--entrypoint entrypoint3.testnet.solana.com:8001 \
--expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
--wal-recovery-mode skip_any_corrupted_record \
--limit-ledger-size
EOF
$ chmod +x /home/sol/validator.shこれらの設定は、テストネットで迅速かつ安全に稼働を開始するのに適しています。すべてのセットアップが完了したら、このスクリプトに戻り、solana-validator --help を実行して設定オプションの全一覧を確認し、カスタマイズする必要があります。
スクリプトを使用してバリデータを起動してみます。
$ ./validator.sh初回起動時には、クラスターの現在の状態に追いつく必要があります。
バリデータが正しく動作していることを確認する
クラスター内のどこからでも、自分または他のバリデータの外部から確認可能な進行状況を次のコマンドで追跡できます。
$ solana catchup <IDENTITY_PUBKEY>sol ユーザーのセッションから、内部の進行状況を次のコマンドで確認できます。
$ solana-validator --ledger /home/sol/ledger monitorバリデータがクラスターに正しく接続しているかを確認する方法の詳細は、こちらで確認できます。
バリデータをデーモンプロセスとして設定する
デーモンとして管理するため、systemd unit ファイルを作成します。
$ sudo cat >/etc/systemd/system/sol.service <<EOF
[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/sol/validator.sh
[Install]
WantedBy=multi-user.target
EOF先ほど実行した ./validator.sh が停止していることを確認してから、バリデータをデーモンとして起動します。
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now sol監視とセキュリティを設定する
パスワードベース認証を無効にする
/etc/ssh/sshd_config ファイルで、SSH デーモンがパスワード認証やチャレンジレスポンス認証を受け付けないよう設定できます。
...
PasswordAuthentication no
ChallengeResponseAuthentication no
...新しい設定で sshd デーモンを再読み込みすることを忘れないでください。
$ sudo systemctl reload sshdfail2ban と ufw を追加する
fail2banは、認証に複数回失敗した接続を、初期設定のままでブロックできます。
$ sudo apt install fail2banufw はシステムに付属するファイアウォールで、いくつかのコマンドで設定できます。ここでは、最終的なバリデータ設定でデフォルトのポートとポート範囲を使用し、SSH をポート22でホストすることを前提とします。
$ sudo ufw allow 22/tcp
$ sudo ufw allow 8000:10000/tcp
$ sudo ufw allow 8000:10000/udp
$ sudo ufw enableバリデータのアイデンティティキーペア
実際には、ほとんどのバリデータがアイデンティティキーをバリデータサーバーに保持し、人の介入なしでバリデータスクリプトを実行、再起動できるようにしています。ただし、ASK または prompt:// を使用してアイデンティティキーをバリデータに渡し、バリデータサーバーのファイルシステムに保存しないようにすることも可能です。この方法では、人が systemd の代わりとなってデーモンプロセスを手動管理する必要があるため、運用負荷とリスクが増加しますが、実行自体は可能です。
アイデンティティキーペアを保護する最善の方法は、数日分の投票コストを賄うために必要な最小限の SOL だけを入金することです。
Shinobi Systemsは、出金キーを毎回使用せずに投票アカウントから残高を自動送金する機能など、投票アカウントの管理を支援するツールを公開しています。
Watchtower で監視を設定する
solana-watchtower は Solana CLI ツールキットに含まれており、バリデータやクラスター全体の問題を通知するために使用できます。watchtower.sh スクリプトを作成することで、バリデータ自体と同様に設定して実行できます。
PagerDuty を通知に使用し、ログを watchtower.log に書き込む例を次に示します。
$ cat >watchtower.sh <<EOF
#!/bin/bash
PATH=/home/solana/.local/share/solana/install/active_release/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
exec >>watchtower.log \\
env PAGERDUTY_INTEGRATION_KEY=<PAGERDUTY_KEY> \\
solana-watchtower \\
--validator-identity <IDENTITY_PUBKEY> \\
--monitor-active-stake \\
--interval 20 \\
--minimum-validator-identity-balance 3 \\
--url https://api.testnet.solana.com
EOFSolana Labs は、Telegram を通知に使用するセットアップ例も公開しています。
バリデータと同じマシンに watchtower をセットアップすることはおすすめしません。マシン全体が停止すると通知を受け取れないためです。ただし、複数の監視方法を用意し、そのようなケースを別途監視できる場合は、同じマシンでも運用できる可能性があります。
バリデータとは異なり、watchtower は多くのリソースを必要としないため、AWS や GCP が提供するようなクラウドまたはサーバーレスコンピューティング環境で実行できます。
オプション:コミュニティベースの監視
Solana コミュニティには、クラスターを監視し、watchtower と同様の条件に基づいて通知を提供している人が多数います。
Stakewizは、Solana バリデータ向けに Telegram ベースの監視を提供しています。たとえば、Helius バリデータに基づく通知を設定する場合は、そのページに移動し、「+ アラートを作成」をクリックします。
コミュニティベースの監視は、ステーク先のバリデータに問題があることをユーザーが把握できるように設計されています。バリデータ運用者は、自分のサービスの監視を他者だけに頼るべきではありません。
オプション:getHealth RPC メソッドによるカスタム監視
バリデータの正常性を直接確認したい場合は、バリデータの JSON RPC インターフェースに getHealth というメソッドがあります。これをポーリングすることで、バリデータが正常かどうかと、問題に関する情報を確認できます。
オプション:サードパーティーの監視ソリューション
バリデータをスケールアップし、保護すべき収益源ができたら、DatadogやSplunkなど、商用グレードの SaaS 監視ソリューションを検討するとよいでしょう。この種のソリューションは通常、サーバー上でデーモンプロセスを実行してログとメトリクスをローカルで監視し、プロバイダーへ送信するか、getHealth または同様のステータスエンドポイントを公開して、プロバイダーがバリデータをリモートでポーリングする方式で動作します。
バリデータにステークを追加する
Solana ネットワークはプルーフ・オブ・ステーク(PoS)による投票プロセスでコンセンサスに到達します。ステークされた SOL を株式と考えると株式会社に似ており、バリデータの投票権重は委任された SOL のステーク量に比例します。投票に加え、バリデータがブロックリーダーになる頻度も、ステークされた SOL の量に比例します。
既存のバリデータに SOL を簡単にステークできるウォレット、dApp、その他のツールは多数ありますが、CLI で手動実行する手順は次のとおりです。
solana-keygen newを使用して3つのキーペアを作成します- solana create-stake-account を使用して、キーペアからステークアカウントを作成します
- ステークアカウントに SOL を送金します(テストネットでは
solana aidropを使用できます) solana delegate-stakeを使用して、入金済みのステークをバリデータに委任します- ステークが有効化されるまで次のエポックを待ち、
solana stake-accountで確認します
キーペアとステークアカウントを作成する
キーペアとステークアカウントを作成するプロセスは投票アカウントの作成と似ており、3つのキーペアは次のとおりです。
- ステーク権限キーペア - 委任、委任解除、分割、統合など、ステークアカウントの運用タスクを実行できます
- ステークアカウントキーペア - ステークアカウント自体を識別する公開キーです(ステークアカウント作成後は秘密キーが不要です)
- 出金キーペア - ステークの出金と、ステークアカウントの権限キーペアのリセットに使用するマスターキーペアです。慎重に扱い、ハードウェアウォレット、ペーパーウォレット、またはマルチシグの使用を検討してください
投票アカウントと同じ理由から、テストネットとメインネットでは別々のキーを使用することを強くおすすめします。ただし、同じクラスター内の複数のステークアカウントで、1組のステーク権限キーペアと出金権限キーペアを再利用できます。ステークアカウントを統合するには、同じキーを使用している必要があります。
次に、キーペアにファイルベースのウォレットを使用し、id.json ウォレットから資金を供給して、テストネット上に1 SOL のステークアカウントを作成し、そのステークを新しいバリデータへ委任する例を示します。
$ solana-keygen new -o stake_auth.json
$ solana-keygen new -o stake_acct_1.json
$ solana-keygen new -o stake_withdrawal_auth.json
$ solana airdrop 1 ~/.config/solana/id.json
$ solana create-stake-account --from ~/.config/solana/id.json stake_acct_1.json 1 --stake-authority stake_auth.json --withdraw-authority stake_withdraw_auth.json --fee-payer ~/.config/solana/id.json
$ solana delegate-stake --stake-authority stake_auth.json <STAKE_ACCT_1_PUBKEY> <VOTE_ACCT_PUBKEY> --fee-payer ~/.config/solana/id.json<VOTE_ACCT_PUBKEY> は投票アカウントのアドレスを指し、バリデータのアイデンティティではありません。
ステークが有効化中かどうか、どのエポックで有効になるかを次のコマンドで確認できます。
$ solana stake-account <STAKE_ACCT_1_PUBKEY>次のエポックが始まり、ステークが有効になると、バリデータの投票がカウントされ始めます。最近の投票は solana vote-account コマンドの一部として確認できます。例のように数 SOL しか追加していない場合、バリデータがブロックリーダーになることは期待しないでください。
投票には1日あたり約1〜2 SOL が必要です。そのため、執筆時点では、メインネットで投票するだけでバリデータに1日約200〜300ドルのコストがかかります。
(ステークの委任とステークアカウントの管理について詳しく確認できます)。
バリデータの情報を公開する
validators.appなど、一般的な Solana バリデータディレクトリを見ると、すべてのバリデータに名前、説明、ロゴ、その他のメタデータがあることがわかります。このデータは各クラスターに登録されたすべてのバリデータについてオンチェーンで公開されており、solana validator-info get を実行すると確認できます。
バリデータが稼働したら、情報を公開するとよいでしょう。特にメインネットで運用し、ステークを集めようとしている場合は重要です。
メタデータを公開する基本的な例を次に示します。
$ solana validator-info publish "My Awesome Validator" \
--website "https://awesome-validator.xyz/" \
--icon-url "https://awesome-validator.xyz/icon360x360.png" \
--keypair validator_identity.json \
--details "The best validator in the world!"メタデータレコードを作成すると固有のキーが割り当てられ、後から --info-pubkey 引数で更新できます。アイコン URL の長さは最大80文字です。バリデータ情報とメタデータの公開について詳しくは、こちらをご覧ください。
まとめ
おめでとうございます!ここまで手順に沿って進めていれば、自分の Solana バリデータが稼働しているはずです。Solana バリデータコミュニティへようこそ!
その他のリソース
関連記事
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます


