新着:HeliusがLight Protocolを買収
Solana バリデータのセットアップ方法
ブログ/開発

Solana バリデータのセットアップ方法

ソフトウェアエンジニアLinkedInのJohn Sloboda
読了時間:19分
目次

この記事では、技術的な観点から 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. アイデンティティキーペア — バリデータはこのキーペアを使用してネットワーク上で自身を識別し、投票などのトランザクションを送信します。秘密キーはサーバー上に置く必要があるため、投票トランザクションに必要な量(約1 SOL/日)を超える SOL を保持しないことが最も安全です。
  2. 投票アカウントキーペア — このキーペアは投票アカウント自体を指し、投票アカウントの検索と、それに対するステークの委任に使用します。create-vote-account コマンドで秘密キーが必要なのは、必要なキーを所有していることを証明するためだけです。投票アカウントの作成後は、公開キーのみが必要です。これは変更できません。
  3. 出金キーペア — このキーペアは投票アカウントのマスターキーとして機能し、報酬の出金、アイデンティティキーや出金キーの変更、その他のアカウント操作に使用します。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

キーを書き留めた紙は、絶対に紛失しないでください。他に復元する方法はありません。ターミナルのバッファーからキーフレーズを消去することも忘れないでください。

オプション:投票アカウント用のバニティキーを生成する

一部のバリデータでは、アイデンティティキーや投票アカウントキーにバニティ公開キーを使用しています。たとえば、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 でバリデータをセットアップする手順は次のとおりです。

  1. Backpackなど、対応する Solana ウォレットプラグインをブラウザーにセットアップします
  2. Squads dAppに移動します
  3. バリデータに必要なメンバーとパラメーターを指定して squad を設定します
  4. Developers > Validators に移動し、フローに従ってバリデータを追加します
  5. 出金秘密キーの貼り付けを求められます。このキーは、既存の出金キーを squad の共有出金キーに変更するために使用されます
  6. solana vote-account を使用して、更新された出金公開キーを確認します

Squads を使用したバリデータの共同管理については、こちらをご覧ください。

マシンをバリデータサーバーとして設定する

手順はマシンの初期状態によって異なりますが、最終的には次の状態を目指します。

  • Ubuntu の最新 LTS バージョンがインストールされ、最新の状態になっている
    • 他の Linux ディストリビューション(Debian ベースなど)でも動作する可能性がありますが、ここでの例はすべて Ubuntu を前提としています。Ubuntu から離れるほど、コマンドの変更が多く必要になります
  • ユーザーレベルの SSH アクセスが設定されている
  • sol サービスユーザーが設定されている
  • システムチューニングとハードディスクの設定が完了している

システムとユーザーのセットアップ

システムが最新であることを確認し、sol サービスユーザーを作成します。

コード
$ sudo apt update
$ sudo apt upgrade
$ sudo adduser sol

sudo アクセスを付与することもできます(利便性と引き換えにセキュリティが若干低下します)。

コード
$ sudo adduser sol sudo

システムチューニング

Solana Labs が推奨する設定を sysctl と systemd に追加し、許可されるファイルディスクリプター数やメモリマップファイル数などの上限を引き上げます。バリデータが現在または次のブロックリーダーになると、ネットワーク全体が接続を開いてトランザクションを送信しようとするため、特にファイルディスクリプターの上限が重要です。

Solana Labs が推奨する最新のシステムチューニング設定はこちらで確認できます。

ハードドライブの設定

Solana Labs の現在の推奨構成は、1TB 以上の物理 SSD を2台用意し、1台をアカウントデータ用、もう1台を台帳データ用にすることです(OS もこのディスクに配置できます)。IOPS が高いため、アカウントと台帳を同じディスクに配置することは推奨されていません。

2台のドライブをセットアップするためのガイドはこちらです。

複数のドライブを活用して利用可能な 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 sshd

fail2ban と ufw を追加する

fail2banは、認証に複数回失敗した接続を、初期設定のままでブロックできます。

コード
$ sudo apt install fail2ban

ufw はシステムに付属するファイアウォールで、いくつかのコマンドで設定できます。ここでは、最終的なバリデータ設定でデフォルトのポートとポート範囲を使用し、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は、出金キーを毎回使用せずに投票アカウントから残高を自動送金する機能など、投票アカウントの管理を支援するツールを公開しています。

その他のヒントについては、Solana Labs のバリデータセキュリティページをご覧ください。

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 &gt;>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
EOF

Solana 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 で手動実行する手順は次のとおりです。

  1. solana-keygen new を使用して3つのキーペアを作成します
  2. solana create-stake-account を使用して、キーペアからステークアカウントを作成します
  3. ステークアカウントに SOL を送金します(テストネットでは solana aidrop を使用できます)
  4. solana delegate-stake を使用して、入金済みのステークをバリデータに委任します
  5. ステークが有効化されるまで次のエポックを待ち、solana stake-account で確認します

キーペアとステークアカウントを作成する

キーペアとステークアカウントを作成するプロセスは投票アカウントの作成と似ており、3つのキーペアは次のとおりです。

  1. ステーク権限キーペア - 委任、委任解除、分割、統合など、ステークアカウントの運用タスクを実行できます
  2. ステークアカウントキーペア - ステークアカウント自体を識別する公開キーです(ステークアカウント作成後は秘密キーが不要です)
  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

ステークが有効化中かどうか、どのエポックで有効になるかを次のコマンドで確認できます。

コード
$ 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開発の最新情報や新しい記事の公開通知を受け取れます