Solanaノード:バリデーター、RPCノード、セルフホスティング

残高を読み取るウォレット、2年前のトランザクションを取得するエクスプローラー、アカウントの更新を消費するトレーディングシステムは、一見すると同じSolanaサービスを使っているように見える。しかし内部では、それぞれ異なるインフラに依存している。

アプリケーションチームにとって有用な問いは、単に「Solanaノードを自前で運用すべきか」ではない。「自分たちのアプリケーションにはどのワークロードが必要で、スタックのどの部分を自社で運用すべきか」である。

Solanaインフラの3つのレイヤーとは何か

Solana上で構築する際、Solanaノードを起点とする3種類のインフラが存在する。ではSolanaノードとは何か。単純に言えば、Solanaノードはvalidatorクライアントソフトウェアを実行するサーバーである。

投票を行うvalidatorがチェーンを保護しブロックを生成する一方、投票を行わないremote procedure call（RPC）ノードはライブの状態とトランザクションAPIを公開する。標準的なノード単体では効率的に保持・応答できないワークロードに対しては、別途アーカイブ、インデックス、キャッシュ、ストリーミングのシステムが対応する。

投票を行うvalidatorがチェーンを保護する

投票を行うvalidatorはコンセンサスに参加し、ネットワークが正規のチェーンについて合意するのを助ける。また、leaderに選ばれた際にはブロックを生成する。その主な責務は、同期状態を維持し、正しく投票し、leaderとしての役割を確実に遂行することである。

アプリケーションはこのコンセンサスに依存しているが、ほとんどのアプリケーションのリクエストは投票を行うvalidatorに直接送られるわけではない。

RPCノードがライブのアプリケーショントラフィックを処理する

RPCノードは通常、投票を行わない同じvalidatorクライアントソフトウェアを実行する。クラスタに追従し、ブロックをリプレイし、現在のアカウント状態を維持するが、投票やleaderスケジュールへの参加は行わない。

代わりに、SolanaのRPCインターフェースを公開する。ウォレット、取引所、エクスプローラー、bot、その他のアプリケーションはこのインターフェースを使ってチェーンデータを照会し、トランザクションをシミュレートし、トランザクションを送信する。

投票を行うvalidatorも技術的にはRPCを公開できる。だが本番環境では、予測不能なアプリケーショントラフィックがコンセンサスやブロック生成と競合しないよう、運用者は通常このインターフェースを非公開または制限された状態に保つ。

専用システムが特化したデータワークロードを処理する

RPCノードはSolanaのAPIを公開するが、プロバイダーはすべてのリクエストにライブノードから直接応答する必要はない。以下のために構築されたシステムを利用できる。

• 長期のトランザクション・ブロック履歴
• アカウントのインデックス作成とコストの高いフィルタ付きクエリ
• 頻繁にリクエストされるデータのキャッシュ
• フィルタリング、バッファリング、リプレイ、リカバリを備えたリアルタイムストリーム

これらのシステムが処理する標準的なRPCメソッドについては、アプリケーション側は同じ馴染みのあるAPIメソッド、パラメータ、フィルタ、レスポンス形式を引き続き使用できる。変わるのはリクエストに応答するシステムだけである。古い履歴はライブノードがもう保持していないため別のストレージから取得され、コストの高い現在の状態のクエリは専用のインデックスやキャッシュからより効率的に処理できる。

各Solanaワークロードはどのインフラレイヤーが処理するか

いくつかの一般的なアプリケーションリクエストを考えてみる。

• ウォレットが残高を確認したり、トランザクションをシミュレートしたりする。ライブRPCノードが現在の状態から直接応答できる。
• エクスプローラーが2年前のトランザクションを読み込む。アプリケーションは標準のRPCメソッドを呼び出すが、ライブノードにはもうデータがないため、プロバイダーはアーカイブストレージから応答する。
• ポートフォリオアプリが大規模プログラムが所有するすべてのアカウントを照会する。同じRPCメソッドとフィルタを、ノードにその状態を繰り返しスキャンさせる代わりに、アカウントのインデックスやキャッシュから処理できる。
• トレーディングシステムがすべてのアカウントまたはトランザクションの更新をリアルタイムで必要とする。継続的な配信にはストリーミングインフラを使い、多くの場合、時点指定のクエリにはRPCも併用する。
• ネットワーク運用者が投票とブロック生成を行いたい。これには投票を行うvalidatorが必要であり、アプリケーション向けのRPCサービスでは対応できない。

プロバイダーはこれらの機能のいくつかを単一のサービスとして提供する場合がある。アプリケーション側からは馴染みのあるインターフェースが見えるが、背後では異なるシステムが処理を担っている。

SolanaノードはどのようにHistorical Dataを提供するか

getTransaction、getBlock、getSignaturesForAddressなどのメソッドで過去のアクティビティを照会できる。しかし標準的なRPCノードは、ローカルには限られたレジャーウィンドウしか保持していない。古いデータが刈り取られた後は、CPUを増やしてもクエリは動作するようにならない。そのデータはもうそのノード上に存在しないためである。

深いSolanaのアーカイブデータには、以下を行う別経路が必要となる。

1. ライブおよび過去のソースからブロックとトランザクションを取り込む
2. 欠損データを検出し修復する
3. 長期保持と高いクエリボリュームに耐えるようデータを保存する
4. そのストレージレイヤーから履歴系RPCリクエストに応答する

これが、「archive RPC」が単にディスクの大きい通常のノードではない理由である。本番規模では、プロバイダーは通常、archive RPCを別のストレージ・クエリシステムから提供し、馴染みのあるRPCインターフェースを通じて公開する。

Alchemyでは、この制約を直接学んだ。当初はSolanaの履歴にGoogle Bigtableを使用していたが、その後アーカイブスタックをself-hostedのHBaseで再構築した。現在では、各レコードは2回書き込まれ、プログラムによって検証され、完全性がスキャンされる。システムが欠損を見つけると、欠けているエントリを再取り込みする。getTransactionやgetSignaturesForAddressなどの履歴系メソッドは、顧客が期待する速度と信頼性を提供するため、ライブRPCフリートのローカル保持に依存する代わりに、この最適化されたデータレイヤーから読み取る。

なぜgetProgramAccountsはコストが高いのか

getProgramAccountsは別の種類の制約を示している。アカウントデータは現在の状態として存在しているが、そのリクエストに応答するには、クエリ時に大量のアカウント集合を検索し、フィルタを適用する必要がある場合がある。

ノードが主にアカウントを保存しているのは、ブロックをリプレイし現在のチェーン状態を維持するためである。汎用の分析用データベースではない。単発の直接スキャンは許容できるかもしれないが、数百万のアカウントを繰り返しスキャンすることは、本番トラフィック下では遅く、リソースを大量に消費するようになる。

継続的なワークロードに対しては、運用者はアカウントの更新を継続的に消費し、クエリしやすいインデックスやキャッシュされたビューを維持できる。そうすればリクエストは、毎回フルスキャンを繰り返す代わりに、あらかじめ用意された結果を読み取ることになる。

getProgramAccountsリクエストを繰り返すことは、インデックスの問題であって、ノードを大きくすればよいという話ではない。言い換えれば、区別すべきは「小さいノード対大きいノード」ではない。ライブノードによるデータ提供とインデックス化されたデータ提供の違いである。

GeyserとgRPCストリーミングはどのように機能するか

トレーディングシステム、インデクサー、その他のリアルタイムアプリケーションは、アカウント、トランザクション、slot、ブロックの更新を発生と同時に処理する必要があることが多い。

WebSocketのsubscriptionはSolanaの標準インターフェースの一部であり、選択されたライブイベントに対しては十分に機能する。より低いレイテンシ、より高いスループット、より豊富なフィルタリングを必要とするワークロードに対しては、Yellowstone gRPCがHTTP/2上のgRPCを基盤とした、より高性能なストリーミングインターフェースを提供する。

Agave validatorクライアントは、投票を行わないRPCノードとして動作している場合も含め、Geyserプラグインを実行できる。Geyserは、ノードがチェーンを処理する際にアカウント、トランザクション、slot、ブロックの更新を発行する。プロバイダーはYellowstone互換のSolana gRPCを通じてそのデータを公開し、フィルタリング、バッファリング、リプレイ、信頼性、複数ノードによる配信を追加できる。

ストリーミングはRPCの代替にはならない。RPCは状態についての問いに答える。ストリーミングは状態が変化したことをアプリケーションに伝える。多くの本番システムは両方を使用している。

Solanaインフラをいつself-hostすべきか

ほとんどのアプリケーションチームは、まずプロバイダーを利用すべきである。self-hostしたRPCノード1台では、必要となるすべてのユースケース（永続的な履歴、インデックス化されたクエリ、グローバルにレプリケートされたAPI、データストリームの提供）を自動的にカバーできず、それを確実に行うには多くの作業が必要になる。

self-hostingが理にかなうのは、自社インフラを制御することでプロダクトが向上する場合、またはポリシー要件によってマネージドサービスが選択肢から外れる場合である。例としては以下が挙げられる。

• コンセンサスに参加するvalidator運用者
• 特定のノード配置やトランザクションルーティングの制御を必要とする、レイテンシに敏感なトレーディングシステム
• カスタムのGeyserプラグイン、インデックス、保持ポリシーを必要とするサービス
• 厳格なコンプライアンスやインフラ制御要件を持つ組織
• 専任のインフラチームを正当化できるほど継続的なトラフィックを持つ大規模プラットフォーム

判断基準は、インフラを自社所有することが、ハードウェア、エンジニアリング、オンコール対応の作業を上回るだけの測定可能な優位性を生むかどうかである。

Solanaインフラを運用するには何が必要か

現在のAgaveのハードウェアガイダンスは、本番トラフィック、冗長性、隣接するデータシステムを考慮する前の時点で、すでに高い出発点を設定している。

ハードウェアは最低限の要件に過ぎない。Solanaの現在のコンセンサスシステムでは、投票を行うvalidatorは投票トランザクションに1日あたり最大でおよそ1.1 SOLを費やすこともある。本番環境のRPCサービスには、単一障害点を避けるための冗長ノードが必要である。deep history、インデックス、信頼できるストリームを必要とし、かつself-hostするチームは、これらのシステムも運用しなければならない。

Solanaノードをどのように運用するか

セットアップはコマンドラインからではなく、役割の決定から始まる。

1. ワークロードを選ぶ。デプロイメントが投票を行うのか、RPCを提供するのか、特化したデータパイプラインに供給するのかを決める。
2. ホストをプロビジョニングする。使用するクライアントと役割に合わせて、現在のCPU、メモリ、ストレージ、帯域、OS、パブリックIPの要件を満たす。
3. 役割を設定する。RPC運用者は投票なしで実行し、必要な履歴、アカウントインデックス、保持設定を選択する。validator運用者はidentityとvote accountを設定する。
4. キーとエンドポイントを保護する。機密キーはvalidatorホストに置かない。公開するRPCおよびWebSocketエンドポイントは、認証、レート制限、ロードバランシングの背後に置く。
5. サービス全体を運用する。同期状態、ディスク、CPU、ネットワーク、プロセスの健全性、アプリケーションレベルのエラーを監視する。アップグレード、リカバリ、フェイルオーバー、不正利用への対応を計画する。

現在のvalidatorのコマンドとフラグ、またはRPCノードのセットアップについては、メンテナンスされているAgaveのガイドを参照すること。

Solanaインフラプロバイダーをどのように評価すべきか

まず自分のアプリケーションに必要なワークロードを洗い出し、それぞれについてプロバイダーがどのように提供しているかを確認する。

自分のアプリケーションが使用するメソッド、subscription、リージョンをベンチマークすること。SolanaのRPCプロバイダーガイドでは、これらの基準に沿って現行の選択肢を比較している。

まとめ

Solanaアプリケーションは、抽象的な意味での「1つのノード」を必要としているわけではない。必要なのは、ライブの状態、トランザクションAPI、履歴、インデックス化されたクエリ、ストリーム、あるいはごく一部のケースではコンセンサス参加といった、具体的な能力である。

まずそれらのワークロードを特定すること。次に、社内で運用することで実際に優位性が得られる部分と、マネージドサービスから得た方がよい部分をそれぞれ判断すること。

AlchemyでSolana上に構築する

ほとんどのアプリケーションチームは、自前のRPCフリート、アーカイブデータベース、インデックス、ストリーミングインフラを運用する必要はない。Alchemyは、状態とトランザクションのためのライブSolana RPC、標準メソッドを通じたgenesisからのブロック・トランザクション履歴、リアルタイムストリームのためのYellowstone互換gRPCを提供している。

Solana上で構築を始める、Solana APIクイックスタートに従う、または専用キャパシティやカスタムワークロードについてAlchemyのチームに相談する。

よくある質問

Solanaノードとは何か

Solanaノードは、validatorクライアントソフトウェアを実行するサーバーである。クラスタに追従し、ブロックをリプレイし、現在のチェーン状態を維持し、ピアと通信する。投票を行うvalidatorはコンセンサスとブロック生成に参加する。投票を行わないRPCノードはアプリケーション向けAPIを公開する。

validatorとRPCノードの違いは何か

どちらもチェーンに追従しリプレイする。投票を行うvalidatorはコンセンサスに参加し、leaderに選ばれた際にはブロックを生成することがある。RPCノードは投票やleaderスケジュールへの参加を行わない。ライブの状態とトランザクションAPIをアプリケーションに提供することに専念している。

archiveノードは別種のSolanaノードなのか

通常はそうではない。深いトランザクション・ブロック履歴は、一般的にRPC互換インターフェースの背後にある別のアーカイブデータシステムによって提供され、ディスクの大きい標準ノードによって提供されるわけではない。

アプリケーションはvalidatorを運用する必要があるか

通常は不要である。アプリケーションはチェーンを成立させるためにvalidatorに依存しているが、自分自身のリクエストは通常RPCノードや専用データサービスに送られる。validatorの運用が必要なのはコンセンサス参加のためであり、通常のアプリケーションアクセスのためではない。

Solanaのvalidatorまたは RPCノードのハードウェア要件は何か

現在のAgaveガイダンスでは、投票を行うvalidatorには最低でも12コア、24スレッド、256 GBのRAMが必要である。投票を行わないRPCノードは最低でも16コア、32スレッドが必要であり、すべてのアカウントインデックスを実行する場合は512 GBのRAMが推奨される。どちらも高速なNVMeストレージと信頼性の高いネットワークを必要とする。

Solanaノードを運用するにはSOLが必要か

投票を行わないRPCノードは投票用のSOLを必要としない。投票を行うvalidatorは、資金の入ったidentityおよびvote accountを必要とし、現在のコンセンサスシステムの下で投票トランザクションのコストを支払う。

Solana validatorの運用は利益になるか

それは、委任されたstake、投票パフォーマンス、手数料率、leaderに選ばれた際のトランザクション手数料収入、maximum extractable value収入、運用コストによって決まる。委任されたstakeが少ないvalidatorは、多くの場合収支を合わせるのに苦労する。validatorの運用は、アプリケーションにRPCアクセスを提供するための手段としてではなく、それ自体独立したインフラビジネスとして捉えるべきである。

Solanaノードをどのように運用するか

まず役割を選び、現在のクライアント要件に合わせてプロビジョニングし、投票またはRPCの動作を設定し、キーとエンドポイントを保護し、モニタリングとフェイルオーバーを追加する。サポートされているリリースや推奨事項は変化するため、コマンドやフラグについては現在のAgaveドキュメントを参照すること。

RPCノードはself-hostすべきか、それともプロバイダーを使うべきか

マネージドなキャパシティ、historical data、インデックス化されたメソッド、ストリーミング、フェイルオーバーが必要で、それらのシステムを自分で運用したくない場合はプロバイダーを利用する。制御、カスタム構成、物理的な配置、継続的な規模、ポリシー要件によって専任のインフラチームが正当化される場合はself-hostする。