Solana RPCノード:セットアップ、プロバイダー、ベストプラクティス
Complete guide to Solana RPC nodes. Learn how they work, compare top providers like Helius and QuickNode, and fix rate limit errors for production dAp...
Solana RPCノードは、アプリケーションがネットワークと通信するために使用する読み取り、送信、およびサブスクリプションインターフェイスを提供します。プロバイダーの機能、制限、価格設定、ハードウェア要件、およびパフォーマンスの数値は時間とともに変化するため、本番環境での決定は、現在のドキュメントおよびワークロードテストに対して検証する必要があります。
最終更新日:2025年7月
Solanaの公開エンドポイントは開発には役立つかもしれませんが、普遍的な本番サービス保証ではありません。dAppが4002エラーを返したり、アカウントクエリで停止したり、負荷下での送信問題が発生したりした場合、トランザクション構築、手数料、有効期限、ネットワーキング、およびクラスターの状態とともに、RPCパスも調査すべきコンポーネントの1つです。
このガイドでは、Solana RPCノードとは何か、バリデーターノードとどう異なるか、リクエストがシステムをどのように流れるか、公開エンドポイントURLをどこで入手できるか、どのRPCメソッドが最も重要か、@solana/web3.jsを介してどのように接続するか、評価すべきマネージドプロバイダーはどれか、セルフホスティングが実際に何を必要とするか、そしておそらくすでに見ているレート制限エラーをどのように修正するかについて説明します。
TL;DR: 開発には、無料のSolana Foundation公開エンドポイントを使用してください。本番環境には、Helius、QuickNode、Alchemy、またはTriton Oneなどのマネージドプロバイダーを使用してください。セルフホスティングはより運用上の制御を提供しますが、容量計画、アクセスポリシー、監視、および現在のハードウェアガイダンスが依然として必要です。
ジャンプ:
- Solana RPCノードとは?
- RPCノード vs バリデーターノード
- Solana RPCノードの仕組み
- Solana RPCノードの種類
- RPCノードの品質が重要な理由:DeFi、NFT、dAppパフォーマンス
- おすすめのSolana RPCノードプロバイダー
- @solana/web3.jsを使用したアプリの接続
- Solana RPCメソッド:クエリできること
- 独自のSolana RPCノードの実行方法
- よくあるSolana RPCエラーとその解決策
- よくある質問
- 適切なSolana RPC戦略の選択
Solana RPCノードとは?
Solana RPCノードは、Solana JSON-RPC APIを実装したサーバーであり、クライアントアプリケーションからのリクエストを受け入れ、応答としてブロックチェーンの状態データを返します。dApp、ウォレット、ブロックエクスプローラー、および自動化されたスクリプトは、ローカルの台帳のコピーを維持することなく、これらのノードを使用してアカウント残高を読み取り、トランザクションを送信し、オンチェーンイベントを購読します。
過去の資料によると、Solanaの理論上のスループットは65,000 TPS近く、スロット時間は400ミリ秒近くです。どちらもライブでの保証された結果ではありません。トランザクション定義、スキップされたスロット、投票トラフィック、ワークロード、クラスターの状態、およびソフトウェアバージョンはすべて、観測されるパフォーマンスに影響します。ターゲットのケイデンスとアカウント状態のボリュームは、RPCインフラストラクチャに依然として substantial な要求を課しています。
リモートプロシージャコール(RPC)は、あるマシン上のプログラムが、ネットワークの複雑さを抽象化して、あたかもローカルであるかのように別マシンの関数を呼び出す通信パターンです。dAppは、独自の台帳コピーを維持する代わりに、リモートノードに対してアカウント状態をクエリしたりトランザクションを送信したりできます。Solanaは、JSON-RPC 2.0をワイヤープロトコルとして使用します。これは、REST APIのようなリソースベースのURLパスではなく、HTTPまたはWebSocket経由でメソッド名によって呼び出しをルーティングする軽量なフォーマットです。
Solana Foundationは、https://api.mainnet-beta.solana.comおよび開発ネットとテストネットの同等のURLで無料の公開エンドポイントを運営しています。これらのエンドポイントは、IPアドレスごとにレート制限を適用します。アプリケーションがこれらの制限を超えると、HTTP 429 Too Many Requestsエラーが表示され、負荷下での断続的な障害やユーザーエクスペリエンスの低下を引き起こします。
RPCノード vs バリデーターノード:違いの理解
RPCノードは、JSON-RPC APIを介して外部クライアントにブロックチェーンデータを提供します。バリデーターノードは、コンセンサスに参加し、ブロックの有効性に投票します。これらはSolanaの2つの主要なノードタイプであり、それぞれ異なる目的を果たします。
| 属性 | RPCノード | バリデーターノード |
|---|---|---|
| 主な役割 | JSON-RPC APIを介して外部クライアントにブロックチェーンデータを提供する | Tower BFTコンセンサスに参加する。各スロットでブロックの有効性に投票する |
| コンセンサス参加 | なし | あり — 全てのスロットに投票 |
| ステーキング/報酬 | ステーキング不要。ブロック報酬なし | ステーキングされたSOLが必要。SOLステーキング報酬を獲得 |
| RAM要件 | 最小256 GB(クエリ応答のために全アカウント状態を保持) | RAMは低め。投票のための低遅延ネットワークを優先 |
| アクセス方法 | HTTPまたはWebSocketエンドポイントURL経由 | 投票アカウントのパブリックキーで識別される |
バリデーターノードは、Proof-of-Stakeベースの投票メカニズムであるTower BFTコンセンサスに参加します。Proof of History(PoH)は、Solanaの暗号シーケンスメカニズム(コンセンサスプロトコルではない)であり、投票が行われる前に順序を確立します。Tower BFTはコンセンサスレイヤーであり、PoHはタイムキーピングを処理します。
Solanaのトランザクション転送プロトコルであるGulf Streamは、他のブロックチェーンが使用するメンプールをバイパスして、トランザクションを現在のリーダーノードおよび将来のリーダーノードに直接送信します。バリデーターがこの転送プロセスを処理します。RPCノードは処理しません。
RPCノードの実行には、ステーキングされたSOLは必要ありません。一部のオペレーターは、同じ物理マシン上でバリデーターとRPCの両方の機能を実行しますが、役割は論理的に分離されています。一方はコンセンサスで投票し、もう一方はクライアントクエリを提供します。RPCノードのセルフホスティングに関わるハードウェア要件については、RAMとストレージの需要は、バリデーター単独の場合よりも大幅に高くなります。
Solana RPCノードの仕組み:アーキテクチャとデータフロー
Solana RPCノードは、台帳とアカウント状態のローカルレプリカを維持し、有効なJSON-RPCリクエストを送信したクライアントにそのデータをサービスします。
JSON-RPCリクエストのライフサイクル
- クライアントアプリケーション(dApp、ウォレット、またはスクリプト)が、RPCノードのエンドポイントURLにHTTP POSTリクエストまたはWebSocketメッセージを送信します。
- リクエストボディには、
jsonrpc、id、method、paramsの4つのフィールドを持つJSON-RPC 2.0ペイロードが含まれています。 - RPCノードはリクエストを受信し、
methodフィールドに基づいて適切な内部ハンドラーにルーティングします。 - ノードは、要求されたデータのローカル台帳レプリカまたはアカウント状態ストアをクエリします。
- ノードは、要求されたデータまたは構造化されたエラーオブジェクトを含む、JSONエンコードされた応答を返します。
具体的なgetBalanceの例:
// Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "getBalance",
"params": ["YourPublicKeyBase58Here", {"commitment": "confirmed"
}
// Response
{
"jsonrpc": "2.0",
"result": {
"context": {"slot": 285823400},
"value": 5000000000
},
"id": 1
}
// Note: value is in lamports. Divide by 1,000,000,000 to convert to SOL.リソースベースのURLを使用するREST APIとは異なり、JSON-RPCはmethodフィールドを使用してすべての呼び出しを単一のエンドポイントにルーティングします。Ethereumの経験がある開発者は、リクエスト構造を認識するでしょう。Solanaは3つの主要な点で異なります。メンプールがない(トランザクションは現在のリーダーに直接送信される)、状態はEVMコントラクトストレージではなくアカウントに存在し、400msのスロットはEthereumの12秒のブロックタイムの約30倍高速です。
コミットメントレベル:processed, confirmed, finalized
状態を読み取るすべてのRPC呼び出しは、commitmentパラメータを受け入れます:
processed: ノードが認識した最新のスロット。最も高速ですが、理論的にはロールバックされる可能性があります。confirmed: スロットがバリデーター投票の過半数を受け取っています。ほとんどのdAppユースケースで強力なファイナリティがあります。finalized: スロットはチェーンの永続的な一部です。高リスクな操作に使用してください。
Solana RPCノードが格納するもの
ノードは2つのカテゴリのデータを保持します。現在の口座状態はRAMに格納されます。これは、高速なクエリ応答に必要な、最新の確認済みスロットにおける全アクティブ口座のスナップショットです。履歴レジャーデータはNVMe SSDに格納されます。これは、スロットごとに整理された全トランザクション記録です。Solanaのメインネット-ベータでは、1日あたり約100~200 GBのレジャーデータが蓄積されます。このストレージの増加と400msのスロットタイムを合わせると、RPCノードが最低256 GBのRAMと数テラバイトの高速ストレージを必要とする理由が説明できます。
Solana JSON-RPC APIの完全なリファレンスについては、docs.solana.com/api.) を参照してください。
HTTP vs. WebSocket: 適切なトランスポートの選択
| トランスポート | モデル | 一般的な用途 | 例 (メソッド) |
|---|---|---|---|
| HTTP / HTTPS | リクエスト/レスポンス (ステートレス、プル) | 一回限りのクエリ、トランザクション送信 | getBalance, getAccountInfo, sendTransaction |
| WebSocket / WSS | 永続接続 (ステートフル、プッシュ) | リアルタイムイベント購読 | accountSubscribe, logsSubscribe, signatureSubscribe |
Solana RPC ノードの種類: パブリック、プライベート、セルフホスト
Solana RPC ノードには、Solana Foundation の無料パブリックエンドポイント、マネージドプライベートプロバイダー、または自身で直接運用するセルフホストノードの3つの方法でアクセスできます。
| タイプ | オペレーター | コスト | レート制限 | サービスターゲット | 一般的な用途 |
|---|---|---|---|---|---|
| パブリックエンドポイント | Solana Foundation | 無料 | はい (IPごとに適用) | なし | 開発とテスト |
| マネージドプロバイダー | Helius, QuickNode, Alchemy, Triton One | 有料プランあり | 有料プランでは制限なしまたは高制限 | はい (有料プラン) | 本番 dApp |
| セルフホスト | あなた | ハードウェア + 運用コスト | なし (自分で制御) | あなたが定義 | 大規模プロトコル、取引所 |
パブリック Solana RPC エンドポイント (無料)
Solana Foundation は、ネットワーククラスターごとに1つずつ、4つのパブリック RPC エンドポイントを運用しています。すべて無料ですが、IPアドレスあたりのレート制限が適用されます。
| クラスター | HTTP エンドポイント URL | WebSocket エンドポイント URL | ユースケース |
|---|---|---|---|
| mainnet-beta | https://api.mainnet-beta.solana.com | wss://api.mainnet-beta.solana.com | 本番ネットワーク ("beta" ラベルは過去のもので、これはSolanaのライブメインネットです) |
| devnet | https://api.devnet.solana.com | wss://api.devnet.solana.com | 開発とテスト; 無料 SOL エアードロップあり |
| testnet | https://api.testnet.solana.com | wss://api.testnet.solana.com | 本番前ストレス テスト |
| localnet | http://localhost:8899 | ws://localhost:8900 | ローカル開発; solana-test-validator によって生成 (公式のパブリッククラスターではありません) |
パブリックエンドポイントは、IPアドレスあたり10秒あたり約100リクエストのレート制限を適用します。このしきい値を超えると、HTTP 429 Too Many Requests が返されます。これらのエンドポイントは開発とテストに機能します。本番環境での使用については、以下のSolana RPCプロバイダー比較を参照してください。
クラスターの完全なドキュメントについては、docs.solana.com/clusters.) を参照してください。
プライベートおよびマネージド RPC ノードプロバイダー
マネージド RPC プロバイダーは、専用エンドポイント、より高い公開制限、WebSocket サポート、サービスターゲット、および複数のリージョンを提供する場合があります。正確な機能は現在のプランによって異なります。Solana の4つの主要プロバイダーは以下の通りです。
- Helius: 強化された RPC API と Webhook 通知を備えた、Solana ネイティブプロバイダー
- QuickNode: 地理的分散とアドオンマーケットプレイスを備えたマルチチェーンプロバイダー
- Alchemy: エンタープライズグレードの開発者ツールを備えたマルチチェーンプロバイダー
- Triton One: 機関ワークロード向けの生 RPC パフォーマンスに焦点を当てた、Solana ネイティブスペシャリスト
価格、WebSocket サポート、および差別化要因の完全な比較は、プロバイダー比較セクションにあります。
セルフホスト Solana RPC ノード
セルフホスティングにより、レート制限なしで RPC インフラストラクチャを完全に制御できますが、ハードウェアコストは数千ドルから始まり、継続的な DevOps メンテナンスは軽視できません。完全な要件とセットアップの概要は、「Solana RPC ノードの実行方法」に記載されています。
RPC ノードの品質が重要な理由: アービトラージ、NFT、dApp パフォーマンス
RPC ノードの品質は、アプリケーションが本番環境で正しく機能するかどうかを直接決定します。4つのユースケースがこれを具体的に示しています。
アービトラージ 取引および取引ボット
Solana 上の アービトラージ プロトコルは、レイテンシが結果を決定する時間的制約のあるトランザクションを処理します。レート制限のあるパブリックエンドポイントを介して getLatestBlockhash および sendTransaction を呼び出す取引ボットは、429 タイムアウト中に古いブロックハッシュまたはトランザクションのドロップのリスクがあります。Solana の 400ms スロットタイムラインでは、RPC 応答時間の 50ms の違いが、トランザクションがターゲットスロットに入るか完全にスキップされるかを決定する可能性があります。
Jupiter (アグリゲーター)、Raydium (AMM オプション)、Drift (パーペチュアル)、Marginfi (レンディング) はすべて、低レイテンシ RPC アクセスに依存しています。Ethereum メンプール とは異なり、Solana トランザクションは Gulf Stream を介してメンプールを完全にバイパスし、現在のリーダーに直接送られます。RPC 呼び出しが遅れて到着した場合にフォールバックする順序付けキューはありません。
高需要の NFT ミントは、限られた供給を争う購入者からの数百の同時 sendTransaction 呼び出しのバーストを生成します。約 10 リクエスト/秒に制限されたパブリックエンドポイントは、ピークドロップ中にほとんどの参加者に 429 エラーを返します。Magic Eden や Tensor などの NFT マーケットプレイスは、WebSocket logsSubscribe サブスクリプションを使用してミントイベントをリアルタイムで検出しますが、これはスケーリングされた WebSocket 接続を安定して処理するプロバイダーを必要とします。
ウォレットアプリケーションは、ユーザーが所有する各資産に対して getBalance および getTokenAccountBalance を呼び出し、さらに getAccountInfo を呼び出してオンチェーンメタデータを読み取ります。10,000 のアクティブユーザーをサービスするウォレットは、1分あたり数万の RPC クエリを発行できます。十分な QPS (クエリ/秒) 容量を持つプライベート RPC プロバイダーは、ユーザーエクスペリエンスを低下させることなく、これらのクエリを解決し続けます。ここでは、QPS は Solana のネットワークレベルのトランザクションスループットではなく、RPC リクエストスループットを指します。
分析プラットフォームとインデクサーは、Solana レジャーの完全なトランザクション履歴を複製するために getBlock を繰り返し呼び出します。完全な履歴同期では、数千の getBlock リクエストが順番に発行されます。セルフホスト RPC ノードまたは専用エンタープライズティアプランのみが、このボリュームを確実にサポートできます。独自の Solana RPC ノードを実行する 集権型 取引所は、ユーザー残高を調整し、デポジットを大規模に検出するために同様の高スループットパターンを使用します。
Solana の 400ms スロットタイムは、Ethereum の約12秒のブロックタイムと比較して、Solana dApp は同等の操作で単位時間あたり約30倍頻繁に RPC をクエリするため、RPC ノードのパフォーマンスは他のほとんどのネットワークよりもここで不釣り合いに重要になります。本番トラフィックでレート制限に達している場合は、プライベート RPC プロバイダーへのアップグレードが最も直接的な解決策です。
Solana RPC ノードプロバイダーの比較
ほとんどの本番 dApp にとって、問題はマネージド RPC プロバイダーを使用するかどうかではなく、どのプロバイダーがワークロードに適しているかということです。この表は、Solana Foundation の無料パブリックエンドポイントをベースラインとして、4つの主要なオプションをカバーしています。
| プロバイダー | Solanaネイティブ | 無料ティア | 有料ティア (概算) | 専用ノード | WebSocket | リージョン | 主な差別化要因 |
|---|---|---|---|---|---|---|---|
| Helius | はい | はい | ~$49〜$499/月 | はい | はい | 米国、EU | 拡張API:Webhooks、トランザクション解析、NFT API |
| QuickNode | いいえ (マルチチェーン) | はい (トライアル) | ~$49〜$399/月 | はい | はい | 米国、EU、アジア+ | アドオンマーケットプレイス;広範なマルチチェーンカバレッジ |
| Alchemy | いいえ (マルチチェーン) | はい | ~$49〜$399/月 | はい | はい | 米国、EU | エンタープライズ開発者ツール;Notify Webhooks |
| Triton One | はい | いいえ | カスタム/エンタープライズ | はい | はい | 米国、EU、アジア | 機関グレードのパフォーマンス;価格についてはお問い合わせください |
| Solana Foundation (公開) | はい | 無料(レート制限あり) | N/A | いいえ | はい(レート制限あり) | 米国 | 開発とテストのみ |
この表の価格情報は公開時点のもので正確です。プロバイダーのプラン、価格、機能は頻繁に変更されます。選択を行う前に、各プロバイダーのウェブサイトで最新の詳細を確認してください。
最終更新日: 2025年7月
Helius は、Solanaに特化したRPCメソッド、Webhooks、トランザクション解析機能を宣伝しています。機能、クォータ、価格、リージョン、サービス条件は helius.dev で直接確認し、意図するワークロードでテストしてください。
QuickNode は、マルチチェーンRPCインフラストラクチャ、リージョンエンドポイント、オプションのアドオンを宣伝しています。現在のSolanaカバレッジ、クォータ、価格、サービス条件は quicknode.com で確認し、必要なメソッドとリージョンをベンチマークしてください。
Alchemy は、Solanaサポートを含むマルチチェーン開発者インフラストラクチャを宣伝しています。それを他のプロバイダーと同等と見なす前に、alchemy.com で現在のメソッドカバレッジ、WebSocketの動作、制限、リージョン、価格を確認してください。
Triton One は、高スループットのワークロード向けのSolanaインフラストラクチャを宣伝しています。そのレイテンシ、可用性、地理的カバレッジ、制限、商用条件は、triton.one で直接確認し、ワークロード固有のテストを行う必要があります。
GenesysGoは以前、ShadowブランドでSolana RPCサービスを運営していました。評価する前にgenesysgo.comで現在の状況を確認してください。
すべての大手プロバイダーは、開発とテストに十分な無料ティアまたはトライアルプランを提供しています。レート制限は、アプリケーションが大規模に実際のユーザーにサービスを提供する場合にのみ、本番環境での懸念事項となります。
Solana RPCプロバイダーの評価方法
適切なプロバイダーは、ワークロードによって異なります。
| ご自身の状況 | 評価の開始点 |
|---|---|
| 予算の限られた個人開発者または小規模チーム | Heliusの無料ティアまたはQuickNodeの無料トライアル;レート制限に達したらアップグレード |
| Solanaのみの本番dApp | Helius (Solanaネイティブ、拡張API) またはTriton One (p99レイテンシが最優先事項の場合) |
| マルチチェーンチーム (SolanaおよびEthereumなど) | QuickNodeまたはAlchemy (どちらも1つのアカウントで複数のチェーンをサポート) |
| 厳格なSLA要件を持つエンタープライズ | QuickNode (エンタープライズティア) またはAlchemy (エンタープライズとしての評判) |
| 高頻度取引 DeFi プロトコルまたはMEV運用 | Triton One (機関向け) またはセルフホストRPCノード |
| 最大限の制御、レート制限なし、大規模DevOpsチーム | セルフホストRPCノード (ハードウェア要件とセットアップ概要を参照) |
プロバイダーのレイテンシ主張は互換性がありません。p50は中央値応答時間ですが、p99はリクエストの最も遅い1%を捉え、時間制約のある操作では重要になる可能性があります。実際のパフォーマンスは、メソッドの組み合わせ、負荷、地理的な近さ、キャッシング、プランの制限によって異なります。したがって、有料プランを選択する前に、意図するリクエストパターンをベンチマークしてください。
@solana/web3.js を使用してアプリケーションを Solana RPC ノードに接続する
Solana Foundation の公開エンドポイントからプライベートプロバイダーに切り替えるには、アプリケーション内の1行を変更するだけで済みます。それは Connection コンストラクタに渡されるURL文字列です。
バージョン注記: このセクションのコード例では、現在の本番標準である @solana/web3.js v1.x を使用しています。Solana Labs は大幅に異なるAPIを持つv2.0を開発中です。v2.0を使用している場合は、同等のメソッドについて公式のv2.0ドキュメントを参照してください。
インストールと接続
ステップ 1: パッケージをインストール
npm install @solana/web3.jsステップ 2: Connection をインスタンス化して残高をクエリする
import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";
// 環境変数からエンドポイントを取得します — プライベートURLをハードコードしないでください
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";
const connection = new Connection(RPC_ENDPOINT, "confirmed");
async function getWalletBalance(address: string): Promise<void> {
const publicKey = new PublicKey(address);
// getBalance は lamports を返します。SOL にするには LAMPORTS_PER_SOL (10^9) で割ってください
const balanceLamports = await connection.getBalance(publicKey);
const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;
console.log(`残高: ${balanceSOL} SOL`);
}
**ステップ 3: アカウントデータを読み取る**
async function getAccountData(address: string): Promise<void> {
const publicKey = new PublicKey(address);
// アカウントが存在しない場合、getAccountInfo は null を返します
const accountInfo = await connection.getAccountInfo(publicKey);
if (!accountInfo) {
console.log("アカウントが見つかりません");
return;
}
console.log("オーナープログラム:", accountInfo.owner.toBase58());
console.log("データ長 (バイト):", accountInfo.data.length);
console.log("Lamports:", accountInfo.lamports);
}
**ステップ 4: トランザクションを送信する**
import {
Transaction,
SystemProgram,
Keypair,
sendAndConfirmTransaction,
} from "@solana/web3.js";
async function transferSOL(
sender: Keypair,
recipientAddress: string,
amountSOL: number
): Promise<string> {
const recipient = new PublicKey(recipientAddress);
const lamports = amountSOL * LAMPORTS_PER_SOL;
const transaction = new Transaction().add(
SystemProgram.transfer({
fromPubkey: sender.publicKey,
toPubkey: recipient,
lamports,
})
);
// sendAndConfirmTransaction は「confirmed」コミットメントが完了するまで待機します
const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
return signature;
}
**ステップ 5: 環境ベースのエンドポイント切り替えを設定する**
アプリケーションコードを変更せずに、環境変数でクラスターを切り替えるための設定モジュールをセットアップします。
// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
"mainnet-beta": "https://api.mainnet-beta.solana.com",
"devnet": "https://api.devnet.solana.com",
"private": process.env.PRIVATE_RPC_URL ?? "",
};
const NETWORK = process.env.SOLANA_NETWORK ?? "devnet";
export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");
**セキュリティ上の注意:** プライベートRPCエンドポイントURLをクライアントサイドJavaScriptにハードコードしないでください。ブラウザに公開されたURLは、ネットワークトラフィックを検査するすべての人にAPIキーを漏洩させます。サーバーサイドプロキシまたはバックエンドAPIルートを経由させてください。
完全な @solana/web3.js APIリファレンスについては、[solana-labs.github.io/solana-web3.js](https://solana-labs.github.io/solana-web3.js/).
### HTTP vs WebSocket RPC接続:どちらを使用するか
| シナリオ | HTTPを使用 | WebSocketを使用 |
|---|---|---|
| ウォレットの残高を一度だけ取得する | はい | いいえ |
| トランザクションを送信する | はい | いいえ |
| リアルタイムの変更のためにアカウントを監視する | いいえ | はい |
| プログラムのトランザクションログをストリームする | いいえ | はい |
| 特定の署名の確認を追跡する | いいえ | はい |
WebSocket接続は `https://` の代わりに `wss://` を使用します。ほとんどのマネージドプロバイダーは、同じプランの下で両方のエンドポイントを提供しています。
// WebSocketサブスクリプション:アカウント変更をリアルタイムで監視
const publicKey = new PublicKey("YourAccountPublicKeyHere");
const connectionWithWS = new Connection(
process.env.RPC_URL ?? "https://api.devnet.solana.com",
{
commitment: "confirmed",
wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
}
);
// onAccountChangeは、後でクリーンアップに使用されるサブスクリプションIDを返します
const subscriptionId = connectionWithWS.onAccountChange(
publicKey,
(accountInfo, context) => {
console.log("アカウントがスロットで変更されました:", context.slot);
console.log("新しいlamport残高:", accountInfo.lamports);
},
"confirmed"
);
// 不要になったらサブスクリプションを削除します:
// connectionWithWS.removeAccountChangeListener(subscriptionId);レート制限と429エラーの処理
パブリックなSolanaエンドポイントからの429 Too Many Requestsエラーは、アプリケーションがIPごとのレート制限を超過したことを意味します。これに対処する3つの戦略があります:
- マネージドプライベートプロバイダーに切り替えます。 Helius、QuickNode、Alchemy、Triton Oneは、本番トラフィックに対応できるプランを提供しています。プライベートSolana RPCプロバイダーの比較を参照してください。
- 指数関数的バックオフを実装します。 429エラー応答があった場合、試行ごとに遅延が倍増する(以下のコードを参照)ようにリトライします。
getMultipleAccountsでアカウントの読み取りをバッチ処理します。 1回の呼び出しで20個のアカウントを取得すると、20回の要求ではなく1回の要求で済みます。
// あらゆるRPC呼び出しのための指数関数的バックオフラッパー
async function withRetry<T>(
fn: () => Promise<T>,
maxRetries: number = 5
): Promise<T> {
let attempt = 0;
while (attempt < maxRetries) {
try {
return await fn();
} catch (error: any) {
const is429 = error?.message?.includes("429");
if (is429 && attempt < maxRetries - 1) {
// 500ms、次に1秒、次に2秒、次に4秒、次に8秒待機します
const waitMs = 500 * Math.pow(2, attempt);
await new Promise((resolve) => setTimeout(resolve, waitMs));
attempt++;
} else {
throw error;
}
}
}
throw new Error("Max retries exceeded");
}Solana RPCメソッド:クエリできること
SolanaのJSON-RPC APIは80以上のメソッドを公開しています。以下の表は、dApp開発者が定期的に使用するメソッドを網羅しています。
HTTP RPCメソッド
| カテゴリ | メソッド | 説明 | 一般的なユースケース |
|---|---|---|---|
| アカウントデータ | getAccountInfo | アカウントに保存されているすべてのデータを返します | プログラム所有のアカウント状態の読み取り |
| アカウントデータ | getBalance | パブリックキーのSOL残高(lamports単位)を返します | ウォレット残高の表示 |
| アカウントデータ | getTokenAccountBalance | トークンアカウントのSPLトークン残高を返します | トークンウォレット残高 |
| アカウントデータ | getMultipleAccounts | 複数のアカウントのデータを1回の呼び出しで返します | バッチ読み取り(レート制限への露出を低減) |
| トランザクション | sendTransaction | 署名済みのトランザクションをネットワークに送信します | あらゆる書き込み操作 |
| トランザクション | simulateTransaction | ブロードキャストせずにトランザクションをシミュレートします | 事前チェック検証 |
| トランザクション | getTransaction | シグネチャによって確認済みのトランザクション詳細を返します | トランザクション履歴の検索 |
| ブロック / スロット | getSlot | 現在のスロットの高さを返します | チェーンの進行状況監視 |
| ブロック / スロット | getLatestBlockhash | 最新のブロックハッシュと最終有効スロットを返します | あらゆるトランザクション送信前に必要 |
| ブロック / スロット | getBlock | 指定されたスロット内のすべてのトランザクションを返します | オンチェーン分析とインデックス作成 |
getRecentBlockhashは非推奨です。代わりにgetLatestBlockhashを使用してください。この置換メソッドはlastValidBlockHeightも返すため、信頼性の高いトランザクション期限切れの処理が可能になります。
WebSocketサブスクリプションメソッド
| メソッド | 機能 | 一般的なユースケース |
|---|---|---|
accountSubscribe | 特定のアカウントが変更されたときにプッシュ通知します | リアルタイム残高監視 |
logsSubscribe | フィルターに一致するトランザクションログをストリーミングします | DeFiイベント監視、NFTミント検出 |
signatureSubscribe | トランザクションシグネチャが確認されたときに通知します | トランザクション確認追跡 |
WebSocketサブスクリプションは、ポーリングせずにオンチェーンイベントに反応する必要があるあらゆるdAppに適しています。accountSubscribeは特定のアカウントのデータが変更されたときにトリガーされ、ユーザーのウォレットやSolanaプログラム(Ethereumのスマートコントラクトに相当)の状態アカウントの追跡に役立ちます。logsSubscribeはプログラムIDフィルターに一致するトランザクションログをストリーミングし、JupiterやRaydiumのようなDeFiプロトコルがスワップイベント発生時に検出するために使用されます。
最も広く使用されているSolanaプログラム開発フレームワークであるAnchorは、内部で@solana/web3.jsを介してこれらのメソッドを呼び出すTypeScriptクライアントを生成します。RPC設定はAnchorベースのdAppにも同様に適用されます。
パラメータ、戻り値の型、エラーコードを含む完全なメソッドリファレンスについては、Solana RPC APIドキュメント.)を参照してください。
独自のSolana RPCノードの実行方法:要件とセットアップ概要
Solana RPCノードを自己ホスティングすることで、完全な制御、レート制限の排除、および最大限のデータプライバシーが得られます。ハードウェア投資は数千ドルに達し、ノードを健全に保つには専用のDevOps能力が必要です。このパスの対象は、大規模なプロトコル、取引所、および既存のインフラストラクチャ能力を持つチームです。
| コンポーネント | 最小 | 本番環境向け推奨 |
|---|---|---|
| CPU | 12コア、3.5 GHz以上 | 24コア、高クロックスピード |
| RAM | 256 GB DDR4 ECC | 512 GB DDR4 ECC |
| ストレージ | 2 TB NVMe SSD | 2x 2 TB NVMe SSD(レジャーとアカウントで別ボリューム) |
| ネットワーク | 1 Gbps専用、低遅延 | 10 Gbps専用 |
| オペレーティングシステム | Ubuntu 20.04 LTS | Ubuntu 22.04 LTS |
ハードウェア要件は、ネットワークの成長に伴って変化します。ハードウェアを調達する前に、公式Solanaドキュメント(docs.solana.com/running-validator))で最新の仕様を確認してください。
Solanaのアカウントベースモデルは、すべてのプログラム状態を個々のアカウントに格納します。フルRPCノードは、高速なクエリ応答のために、すべてのアクティブなアカウントの現在の状態をRAMに保持し、さらに履歴レジャーデータをNVMe SSDに保存する必要があります。メインネットベータでは1日あたり100〜200GBのストレージ増加が発生するため、オペレーターは継続的なレジャーローテーションを計画する必要があります。
セットアッププロセスの概要
7つのステージが必要です。各ステップは、完全な設定詳細について公式Solanaドキュメントにリンクしています。
- 上記の仕様を満たすか、それを超えるハードウェアをプロビジョニングします。
- オペレーティングシステムをインストールし、Linuxカーネルパラメータを設定します:ulimitファイルディスクリプタ制限を引き上げ、Solanaの高UDPトラフィック量に対応するためsysctlネットワーク設定を調整します。
- 公式Solana Labsリリースチャンネルから、Solana CLIおよび
agaveバリデーターバイナリ(旧solana-validator)をインストールします。 - コンセンサス参加を無効にするために
--no-votingフラグを渡し、--rpc-port 8899(HTTP)および--rpc-pubsub-port 8900(WebSocket)を設定して、ノードをRPCモードで設定します。 - ジェネシスからリプレイするのではなく、最近の状態から同期を開始するために、Solana Foundationのスナップショットリポジトリからスナップショットをダウンロードします。
- ノードを起動し、同期の進行状況を監視します。
solana catchupを使用して、ノードがクラスターの先端からどのくらい遅れているかを追跡します。 - ファイアウォールルールを設定して、ポート8899および8900を承認されたIPアドレスのみに公開します。認証なしでRPCポートを公開しないでください。
推奨ハードウェアでのスナップショット同期には1〜3日かかります。ジェネシスからの同期には大幅に時間がかかり、推奨されません。
ベアメタルは通常、仕様とデータセンターの地理的条件に応じて、月額500〜1500ドルかかります。クラウドの同等品は、ストレージ集約型のワークロードでの仮想化オーバーヘッドにより、より高価になります。1日あたり100〜200GBのストレージ増加により、大規模なボリュームを事前割り当てするか、レジャーのプルーニングを自動化するかを選択する必要があります。
構築対購入の意思決定を評価しているチームは、ハードウェア調達をコミットする前に、プロバイダー比較セクションでマネージドプロバイダーのコストを比較してください。
一般的なSolana RPCエラーと修正方法
429 Too Many Requests
お使いのアプリケーションが、パブリックなSolanaエンドポイントのIPごとのレート制限を超過しました。修正方法は以下の通りです:
- マネージド・プライベート・プロバイダーに切り替える。 Helius、QuickNode、Alchemy、Triton Oneなどは、商用トラフィックに合わせたプランを提供しています。プライベートSolana RPCプロバイダーの比較をご覧ください。
- エクスポネンシャル・バックオフを実装する。 429レスポンスを受け取った際、試行のたびに待機時間を2倍にして再試行します。コード例はレート制限処理セクションにあります。
getMultipleAccountsでアカウントの読み取りをバッチ化する。 1回の呼び出しで20のアカウントを取得すれば、20回ではなく1回分のリクエスト消費で済みます。
トランザクション承認のタイムアウト
sendTransaction経由で送信されたトランザクションが反映されません。ブロックハッシュの期限が切れているか、ネットワークが混雑している可能性があります。修正方法は以下の通りです:
- トランザクションを作成する直前に
getLatestBlockhashを呼び出します。getRecentBlockhash(非推奨)は使用しないでください。 - レスポンスから
lastValidBlockHeightを確認し、その高さに達する前に再試行してください。 - 一時的な失敗に対して自動再試行を行うには、生の
sendTransactionではなくsendAndConfirmTransactionを使用してください。
getProgramAccountsのレート制限エラー
getProgramAccountsは、最もリソースを消費するRPC呼び出しの1つです。パブリックエンドポイントでは、共有インフラへの負荷を理由に、この呼び出しを制限または完全に拒否することがよくあります。これらの呼び出しで特に403エラーやタイムアウトが発生する場合は、大規模なプログラムアカウントクエリを明示的にサポートしているプライベートRPCプロバイダーにアップグレードしてください。
よくある質問:Solana RPCノード
Solana RPCノードとは何ですか?
Solana RPCノードは、Solana JSON-RPC APIを実装したサーバーであり、クライアントアプリケーションからのリクエストを受け取り、ブロックチェーンの状態データを返します。dApp、ウォレット、ブロックエクスプローラーなどは、レジャー(台帳)のローカルコピーを実行することなく、これらを使用してアカウント残高の読み取り、トランザクション履歴の取得、署名済みトランザクションのネットワークへの送信を行います。
Solana RPCノードとバリデータノードの違いは何ですか?
この2つは異なる役割を担います。RPCノードはJSON-RPC APIを介して外部クライアントにデータを提供し、コンセンサスには参加せず、ステーキング報酬も得られません。バリデータノードはスロットごとにブロックの有効性に投票し、SOLのステーキングが必要で、正しい投票に対してSOL報酬を獲得します。一部のオペレーターは同じハードウェアで両方を実行していますが、役割は論理的に分かれたままです。
SolanaのパブリックRPCエンドポイントは無料で利用できますか?
はい。Solana Foundationが提供する api.mainnet-beta.solana.com、api.devnet.solana.com、api.testnet.solana.com のパブリックエンドポイントは無料です。これらにはIPアドレスごとに10秒間で約100リクエストのレート制限が適用されます。これらのエンドポイントは開発やテストには十分ですが、実際のユーザーにサービスを提供する本番環境のdAppには適していません。
SolanaのパブリックRPCでレート制限を回避するにはどうすればよいですか?
3つのアプローチを組み合わせます:商用トラフィック用にマネージド・プライベートRPCプロバイダーに切り替えること、失敗したリクエストを待機間隔を延ばしながら再試行するエクスポネンシャル・バックオフを実装すること、そしてアカウントごとにgetAccountInfoを発行するのではなく、複数のアカウント読み取りを単一のgetMultipleAccounts呼び出しにバッチ化することです。
自前でホストするSolana RPCノードにはどのようなハードウェアが必要ですか?
最小要件:12コアCPU、256GB DDR4 RAM、2TB NVMe SSD、および1Gbpsの専用ネットワーク接続。本番環境の推奨スペック:24コアCPU、512GB RAM、2TB NVMe SSD x 2、および10Gbpsネットワーク。ネットワークの成長に伴い要件も増大するため、最新の仕様についてはSolanaバリデータドキュメント,)を確認してください。
Solana RPCノードの同期にはどのくらい時間がかかりますか?
推奨ハードウェアで最新のスナップショットを使用した場合、1〜3日を見込んでください。ジェネシス(創世記)からの同期にはかなり長い時間がかかります。Solana Foundationはプロセスを加速させるために公式のスナップショットを提供しています。
SolanaにおけるHTTPとWebSocketのRPC接続の違いは何ですか?
HTTP RPCはステートレスなリクエスト・レスポンスモデルを使用します。アプリケーションが1回のリクエストを送り、1回のレスポンスを受け取る形式で、getBalanceやsendTransactionのような単発のクエリに適しています。WebSocket RPCはサブスクリプションモデルによる永続的な接続を使用します。アプリケーションはオンチェーンイベントをサブスクライブし、それらのイベントが発生したときにプッシュ通知を受け取ります。dAppのリアルタイム機能にはWebSocketを使用してください。
本番環境のdAppはSolana RPCプロバイダーをどのように評価すべきですか?
HeliusとQuickNodeはよく議論される2つのオプションですが、コミュニティでの知名度が必ずしも適合性やパフォーマンスの証明にはなりません。Heliusは、Solanaネイティブの拡張APIを必要とする、Solanaに特化して構築を行うチームに適しています。QuickNodeは、1つのアカウントで複数のブロックチェーンをサポートするチームに向いています。Triton Oneは、p99レイテンシが主要な制約となる機関レベルのワークロードに適した選択肢です。適切な選択は、ワークロード、およびSolana特有の機能かマルチチェーンサポートのどちらを重視するかによって決まります。
関連するSolanaガイド
Bybit でSOLを探索する
読者は現在のSOL市場情報)やSOL/USDTの現物市場.)を確認できます。これらのリンクは市場情報とアクセスを提供するものであり、技術的な主張を検証したり、SOLがあらゆる読者に適していることを示唆したりするものではありません。
ユースケースに合ったSolana RPC戦略の選択
3つの道があり、ほとんどのチームは現在のステージにどれが適しているかすぐに判断できるでしょう。
| 状況 | 選択する道 |
|---|---|
| ローカルでの構築またはテスト | devnetまたはtestnetにあるSolana Foundationの無料パブリックエンドポイントを使用する |
| ユーザーに提供する本番用dApp | ワークロードに基づいて、Helius、QuickNode、Alchemy、またはTriton Oneなどのマネージド・プライベートプロバイダーを使用する |
| DevOps能力を持つ大規模プロトコル、取引所、またはチーム | セルフホスティングを検討する:完全な制御が可能でレート制限もないが、多額のハードウェアコストと運用コストがかかる |
RPCの信頼性はアプリケーションの読み取りとトランザクションの送信に影響しますが、ターゲットのスロット期間は承認の保証ではなく、RPCのレイテンシはトランザクションが反映されるかどうかの1つの要因に過ぎません。現在の規模に合ったティアを選択し、レート制限がユーザー側の問題になる前にアップグレードを計画してください。
次のステップ:
- 無料の開発ティアに登録する: helius.dev または quicknode.com
- Solana JSON-RPCメソッドのリファレンス全文を確認する: docs.solana.com/api
- セルフホスティングのプロビジョニング前にハードウェア仕様を確認する: 独自のSolana RPCノードを実行する方法