データストリームとプロトコルから考える、Solana アプリ速度改善のヒント（WS / gRPC / UDP / Shreds）
データストリームとプロトコルから考える、Solana アプリ速度改善のヒント（WS / gRPC / UDP / Shreds）
Solana 上でアプリケーションやトレーディング戦略の高速化を考えるとき、最初に整理すべきなのは次の二点です。
一つ目は、Solana ノードとの距離です。
アプリケーションがどのリージョンに存在し、そこからバリデータまで何ミリ秒で到達できるかが、すべての基礎になります。距離が正しく確保できていない構成では、どれだけソフトウェアやハードウェアを最適化しても、本来得られるはずの性能には届きません。
アプリケーションがどのリージョンに存在し、そこからバリデータまで何ミリ秒で到達できるかが、すべての基礎になります。距離が正しく確保できていない構成では、どれだけソフトウェアやハードウェアを最適化しても、本来得られるはずの性能には届きません。
二つ目は、リーダーバリデータの位置が時間とともに移動することです。
フランクフルトがリーダーの時間帯にはフランクフルト近傍が有利になり、東京がリーダーの時間帯には東京近傍が有利になります。Solana のリーダーは世界中を巡回しながらブロック生成を行っており、この性質がある限り、単一リージョンのみの構成では物理的に不利になる時間帯が必ず生じます。
フランクフルトがリーダーの時間帯にはフランクフルト近傍が有利になり、東京がリーダーの時間帯には東京近傍が有利になります。Solana のリーダーは世界中を巡回しながらブロック生成を行っており、この性質がある限り、単一リージョンのみの構成では物理的に不利になる時間帯が必ず生じます。
したがって、距離とリーダー位置に対応する現実的な戦略はマルチリージョン構成です。
Frankfurt、Amsterdam、New York、Chicago、Tokyo、Singapore など複数拠点でデータを扱うことで、どの時間帯でもリーダーに近い地点からチェーンの変化を捉えやすくなります。
Frankfurt、Amsterdam、New York、Chicago、Tokyo、Singapore など複数拠点でデータを扱うことで、どの時間帯でもリーダーに近い地点からチェーンの変化を捉えやすくなります。
本記事では、この前提を踏まえたうえで、Solana でよく登場するデータストリーム
- WebSocket（WS）
- Geyser gRPC
- Shredstream（UDP Shreds）
がそれぞれどのタイミングのデータを扱い、どのような通信特性を持ち、どの用途に向いているのかを整理します。
「名前がそれっぽいから」ではなく、Solana の仕組みと通信レイヤーの両方から理解することで、アプリの速度と UX 向上にどう活かせるかを具体的に説明します。
「名前がそれっぽいから」ではなく、Solana の仕組みと通信レイヤーの両方から理解することで、アプリの速度と UX 向上にどう活かせるかを具体的に説明します。
Solana のデータが流れるタイミングの違い
まず、Solana のデータがどのタイミングでどのように扱われているかを整理します。
大まかには、次の三段階として捉えるとイメージしやすくなります。
大まかには、次の三段階として捉えるとイメージしやすくなります。
一つ目は、Shreds の段階です。
Solana のバリデータ同士は、ブロックを構成するための Shreds を UDP でやりとりしています。このとき運ばれているのは、まだブロックとして完全にまとまる前のデータです。この段階の情報を取得できれば、チェーン上の変化に最も早いタイミングで気づくことができます。その代わり、UDP で流れている以上、欠損や順序の入れ替わりが起こり得ることを前提に設計する必要があります。
Solana のバリデータ同士は、ブロックを構成するための Shreds を UDP でやりとりしています。このとき運ばれているのは、まだブロックとして完全にまとまる前のデータです。この段階の情報を取得できれば、チェーン上の変化に最も早いタイミングで気づくことができます。その代わり、UDP で流れている以上、欠損や順序の入れ替わりが起こり得ることを前提に設計する必要があります。
二つ目は、Geyser gRPC の段階です。
バリデータが Shreds を受け取り、ブロックとして確認したあと、その内容を構造化して外部に通知する仕組みが Geyser gRPC です。ブロックやログ、アカウント更新などがイベントとしてまとめて配信されます。Shreds より一段遅いタイミングですが、その分データが整理されており、アプリケーション側から扱いやすくなっています。
バリデータが Shreds を受け取り、ブロックとして確認したあと、その内容を構造化して外部に通知する仕組みが Geyser gRPC です。ブロックやログ、アカウント更新などがイベントとしてまとめて配信されます。Shreds より一段遅いタイミングですが、その分データが整理されており、アプリケーション側から扱いやすくなっています。
三つ目は、HTTP RPC / WebSocket の段階です。
Geyser やノード内部の処理を経て保存されたデータを、後から問い合わせるための API として公開しているのが JSON-RPC や WebSocket 通知です。getBalance や getProgramAccounts、ログの購読などは、この保存済みデータを参照しています。Geyser の通知からさらに一段後ろのタイミングであり、アプリケーション向けの最上位層と考えることができます。
Geyser やノード内部の処理を経て保存されたデータを、後から問い合わせるための API として公開しているのが JSON-RPC や WebSocket 通知です。getBalance や getProgramAccounts、ログの購読などは、この保存済みデータを参照しています。Geyser の通知からさらに一段後ろのタイミングであり、アプリケーション向けの最上位層と考えることができます。
まとめると、
- Shreds は「伝わった直後に近い、生のデータ」
- Geyser gRPC は「ブロックを確認したタイミングの構造化データ」
- RPC / WebSocket は「保存済みデータを API として取得する層」
というタイミングの違いがあります。
どの段階のデータを見ているかによって、「どれだけ早く変化に気づけるか」は根本的に変わります。
どの段階のデータを見ているかによって、「どれだけ早く変化に気づけるか」は根本的に変わります。
通信特性としての UDP / gRPC / WebSocket / TLS
次に、これらの段階で実際にどのようにデータが運ばれているか、通信特性の観点から整理します。
Shreds では UDP が使われています。
UDP はヘッダが軽く、コネクション確立の手順も不要です。再送や順序保証を行わない代わりに、レイテンシを最小限に抑えられます。Shreds のように、多数のノード間で冗長にデータを流すことが前提になっている用途では、このシンプルさと速さが合理的です。
UDP はヘッダが軽く、コネクション確立の手順も不要です。再送や順序保証を行わない代わりに、レイテンシを最小限に抑えられます。Shreds のように、多数のノード間で冗長にデータを流すことが前提になっている用途では、このシンプルさと速さが合理的です。
Geyser gRPC は TCP 上で動作するバイナリプロトコルを使います。
ストリーミング RPC、ヘッダ圧縮、バイナリ形式などにより、一般的な HTTP+JSON と比べて効率良くデータを運ぶことができます。構造化されたイベントを継続的に受け取りたいバックエンド処理や監視・分析には適しています。
ストリーミング RPC、ヘッダ圧縮、バイナリ形式などにより、一般的な HTTP+JSON と比べて効率良くデータを運ぶことができます。構造化されたイベントを継続的に受け取りたいバックエンド処理や監視・分析には適しています。
WebSocket は、多くの場合 TCP + TLS の上で JSON をやりとりします。
ブラウザから直接扱えることが大きな利点で、dApp フロントエンドや軽量な bot などで広く利用されています。一方で、テキスト形式の JSON をパースする必要があり、ヘッダや暗号化も含めると三つの中では最も重くなりやすい構成です。
ブラウザから直接扱えることが大きな利点で、dApp フロントエンドや軽量な bot などで広く利用されています。一方で、テキスト形式の JSON をパースする必要があり、ヘッダや暗号化も含めると三つの中では最も重くなりやすい構成です。
ここにさらに TLS のオーバーヘッドが加わります。
https、wss、gRPC-TLS など暗号化通信を行う場合、ハンドシェイクや暗号化・復号の処理が必ず挟まります。通常の Web アプリケーションでは問題にならないことが多いですが、数十ミリ秒単位の差が UX や損益に直結する戦略では無視できません。
https、wss、gRPC-TLS など暗号化通信を行う場合、ハンドシェイクや暗号化・復号の処理が必ず挟まります。通常の Web アプリケーションでは問題にならないことが多いですが、数十ミリ秒単位の差が UX や損益に直結する戦略では無視できません。
大切なのは、
- どのタイミングでデータを受け取るか（Shreds / Geyser / RPC）
- どういった通信特性で運ぶか（UDP / gRPC / WebSocket / TLS）
は別の軸ですが、最終的な速度と UX に対してはどちらも強く影響する、という点です。
速さの整理：タイミングと通信方式から見た関係
ここまでの整理を踏まえると、技術的な意味での速さは、おおよそ次のように理解できます。
タイミングという観点では、
- Shreds がもっとも早い段階
- 次に Geyser gRPC
- さらにその後ろに RPC / WebSocket
という順番になります。
通信方式という観点では、
- UDP がもっとも軽くて速い
- 次に TCP 上でバイナリを使う gRPC
- 最後に JSON + TLS になりがちな WebSocket
という関係になります。
まとめて短く並べると、次のようなイメージです。
タイミングの違い
Shreds → Geyser gRPC → RPC / WebSocket
Shreds → Geyser gRPC → RPC / WebSocket
通信特性の違い
UDP → gRPC（TCP） → WebSocket（TCP + JSON + TLS）
UDP → gRPC（TCP） → WebSocket（TCP + JSON + TLS）
同じリージョン、同じハードウェア、同じネットワーク経路という条件を揃えたとき、技術的な速さの序列は
- UDP（Shreds）
- gRPC（Geyser）
- WebSocket（JSON-RPC 通知）
という順番になります。
ただし、これは速度だけを見た場合の話です。
実際の構成を考える際には、信頼性や実装コストといった別の軸も併せて考える必要があります。
実際の構成を考える際には、信頼性や実装コストといった別の軸も併せて考える必要があります。
信頼性と実装コスト：なぜ現場では WS > gRPC > UDP になるのか
データストリームの導入順は、多くのプロジェクトで
- まずは WebSocket
- 次に Geyser gRPC
- 最後に Shreds / UDP
という順番になります。これは単なる慣習ではなく、構造上の理由があります。
Shreds（UDP）は最速ですが、欠損や順序の入れ替わりを前提にした設計が必要です。
すべてのパケットがきれいに届くわけではないため、ロジック側で補正し、必要に応じて他のストリームと組み合わせて整合性を取る必要があります。最速を狙う代わりに、実装と運用の難易度は高くなります。
すべてのパケットがきれいに届くわけではないため、ロジック側で補正し、必要に応じて他のストリームと組み合わせて整合性を取る必要があります。最速を狙う代わりに、実装と運用の難易度は高くなります。
Geyser gRPC は、ノード内部で確認・構造化されたデータをそのまま受け取れるため、扱いやすく欠損も少ない構成です。
イベント駆動でバックエンドを動かしたり、監視・アラート・インデックスを構築したりする用途では、速度と安定性、実装のしやすさのバランスが良く、多くのプロジェクトが「次の一手」として採用します。
イベント駆動でバックエンドを動かしたり、監視・アラート・インデックスを構築したりする用途では、速度と安定性、実装のしやすさのバランスが良く、多くのプロジェクトが「次の一手」として採用します。
WebSocket は、ブラウザや既存の Web スタックから直接扱えることが最大の利点です。
dApp フロントエンドからそのまま利用でき、サンプルやライブラリも豊富なため、最初にプロダクトを成立させる段階では最も現実的な選択になります。
dApp フロントエンドからそのまま利用でき、サンプルやライブラリも豊富なため、最初にプロダクトを成立させる段階では最も現実的な選択になります。
このように、技術的な速さの序列は UDP > gRPC > WS でありながら、
開発現場で採用されやすい順番は WS > gRPC > UDP になる、という二つの軸が存在します。
どちらか一方を絶対視するのではなく、自分たちのフェーズと目的に合わせて、どこまで踏み込むかを決めることが重要です。
開発現場で採用されやすい順番は WS > gRPC > UDP になる、という二つの軸が存在します。
どちらか一方を絶対視するのではなく、自分たちのフェーズと目的に合わせて、どこまで踏み込むかを決めることが重要です。
Shreds と Geyser gRPC の役割分担
高速化を本格的に考える段階では、Shreds と Geyser gRPC をどう組み合わせるかが鍵になります。
Shreds は、「誰よりも早く変化に気づく」ためのレイヤーです。
リーダーに近い場所で Shreds を受信することで、同じ戦略を使っていても、数十ミリ秒から数百ミリ秒単位で早くシグナルを検知できます。その代わり、欠損や揺れを許容し、最速検知を優先する設計が求められます。
リーダーに近い場所で Shreds を受信することで、同じ戦略を使っていても、数十ミリ秒から数百ミリ秒単位で早くシグナルを検知できます。その代わり、欠損や揺れを許容し、最速検知を優先する設計が求められます。
Geyser gRPC は、「確認とロジックを安定させる」ためのレイヤーです。
ブロック確定タイミングでログやアカウントの更新を受け取り、戦略ロジックやリスク管理、インデックス、監視・アラートなどに利用します。Shreds より遅い代わりに、整った情報を受け取れます。
ブロック確定タイミングでログやアカウントの更新を受け取り、戦略ロジックやリスク管理、インデックス、監視・アラートなどに利用します。Shreds より遅い代わりに、整った情報を受け取れます。
実際の構成としては、
- Shreds からシグナルを受け取って素早く候補トランザクションを組み立てる
- 並行して Geyser gRPC でブロックやログを確認し、戦略や監視ロジックを安定させる
という役割分担がよく使われています。
最速検知と確実な確認を分離することで、速度と安定性の両立がしやすくなります。
最速検知と確実な確認を分離することで、速度と安定性の両立がしやすくなります。
TLS と共有エンドポイント / 専有ノードの違い
ここまでの話に、共有エンドポイントと専有ノードという視点を加えると、構成の差がよりはっきりします。
共有エンドポイントは、複数のユーザーが同じノード群を利用する仕組みです。
公衆インターネットからアクセスされることを前提にしているため、通信の暗号化は必須であり、TLS を外すことはできません。暗号化・復号・ハンドシェイクの処理は、通常の dApp では許容範囲でも、HFT や 0 スロットを狙う戦略では無視できない差を生むことがあります。
公衆インターネットからアクセスされることを前提にしているため、通信の暗号化は必須であり、TLS を外すことはできません。暗号化・復号・ハンドシェイクの処理は、通常の dApp では許容範囲でも、HFT や 0 スロットを狙う戦略では無視できない差を生むことがあります。
専有ノードは、サーバーを一人で使う構造です。
IP ホワイトリストでアクセス元を限定できるため、TLS を外した http や平文 gRPC を選択することができます。また、CPU・メモリ・I/O・ネットワーク帯域を他ユーザーと共有しないため、他人の負荷による揺れがほとんどありません。
IP ホワイトリストでアクセス元を限定できるため、TLS を外した http や平文 gRPC を選択することができます。また、CPU・メモリ・I/O・ネットワーク帯域を他ユーザーと共有しないため、他人の負荷による揺れがほとんどありません。
専有ノード上で Shreds、Geyser gRPC、RPC をまとめて運用することで、これらすべてのストリームが「他テナントの負荷や TLS の揺れから切り離された環境」で動作する構成を取ることができます。
この結果、
- 共有ノードでは避けられない揺れ
- TLS によるオーバーヘッド
をまとめて削ることができ、同じハードウェアでも到達できる速度帯が大きく変わります。
共有ノードは広範なユーザーに十分な性能を提供するための仕組みであり、専有ノードは「限界まで速さを取りにいく」ための選択肢だと整理できます。
共有ノードは広範なユーザーに十分な性能を提供するための仕組みであり、専有ノードは「限界まで速さを取りにいく」ための選択肢だと整理できます。
マルチリージョンと専有 Shreds（UDP Forwarding）
距離とリーダー位置の前提に戻ると、Solana のリーダーが世界中を巡回している以上、単一リージョンだけで全時間帯最速を維持することは物理的に不可能です。
そこで重要になるのが、複数リージョンで Shreds を扱う構成です。
専有 Shreds（Premium Shreds / Standard Shreds / Metal Shreds / Limited Edition など）は、UDP による最速ストリームと専有サーバーによる揺れの少ない挙動を組み合わせたサービスです。
Frankfurt、Amsterdam、New York、Chicago、Tokyo、Singapore など複数リージョンに専有 Shreds を展開することで、各時間帯でリーダーに近い場所から Shreds を受け取ることができます。
Frankfurt、Amsterdam、New York、Chicago、Tokyo、Singapore など複数リージョンに専有 Shreds を展開することで、各時間帯でリーダーに近い場所から Shreds を受け取ることができます。
現場では、複数リージョンから専有 Shreds を同時購読し、最初に届いたものだけを採用する構成がよく使われています。
これにより、距離や時間帯による不利を抑えながら、グローバルに最速を狙うことができます。
これにより、距離や時間帯による不利を抑えながら、グローバルに最速を狙うことができます。
専有 Shreds のマルチリージョン展開を後押しするため、ERPC では複数リージョン利用時のディスカウントクーポンも提供しています。
- 2 リージョンで 5% OFF
- 3 リージョンで 8% OFF
- 5 リージョンで 10% OFF
- 全リージョンで 15% OFF
といった形で、必要なリージョンを組み合わせながらグローバルカバレッジを拡大しやすくする仕組みです。
競争の激しい地域では Premium Shreds や Metal Shreds を採用し、それ以外の地域では Standard Shreds などでコストを抑える、といった使い分けも可能です。
競争の激しい地域では Premium Shreds や Metal Shreds を採用し、それ以外の地域では Standard Shreds などでコストを抑える、といった使い分けも可能です。
Shared Shredstream Bundle で Shreds を広く試す
専有構成に踏み込む前のステップとして、Shared Shredstream のマルチリージョン構成も現実的な選択肢です。
Shared Shredstream Bundle では、複数リージョンの共有 Shreds をまとめて利用できます。
共有 Shredstream は、元の Shreds（UDP）レイヤーから取得したデータを gRPC で配信する構成になっています。内部的なデータソースは Shreds なので、Geyser gRPC よりも一段早いタイミングの情報を受信できます。
共有 Shredstream は、元の Shreds（UDP）レイヤーから取得したデータを gRPC で配信する構成になっています。内部的なデータソースは Shreds なので、Geyser gRPC よりも一段早いタイミングの情報を受信できます。
Shreds そのもの（専有 UDP Forwarding）は最速で、Shared Shredstream はその一つ上の「gRPC で扱いやすくした Shreds 由来ストリーム」、Geyser gRPC はさらにその後ろの確認タイミングという位置づけになります。
Shared Shredstream Bundle では、IP ホワイトリスト、10 コネクション、最寄りエッジへの自動接続など、コストと利便性を両立した構成になっており、アジア・北米・欧州といった各地域で Shreds を同時に活用できます。
専有 Shreds をいきなり全リージョンで導入するのではなく、
- まず Shared Shreds Bundle で Shreds レイヤーを試す
- 実際のログと結果を見ながら、重要度の高いリージョンから専有 Shreds に移行する
という段階的な導入も取りやすくなります。
開発フェーズ別の現実的なステップ
ここまでの内容を、開発フェーズごとに整理します。
フェーズ 1 では、距離とリージョン選定を正しく行ったうえで、RPC と WebSocket を使って dApp や bot を成立させます。
dApp フロントエンドから直接扱える WebSocket は、プロダクトをまずリリースする段階では非常に合理的です。Solana ノードへの距離が適切であれば、この時点でも大きく UX を改善できます。
dApp フロントエンドから直接扱える WebSocket は、プロダクトをまずリリースする段階では非常に合理的です。Solana ノードへの距離が適切であれば、この時点でも大きく UX を改善できます。
フェーズ 2 では、Geyser gRPC を導入し、バックエンドや監視・分析基盤を強化します。
Geyser gRPC によって、ブロックやログ、アカウント更新のイベントを効率的に取得し、インデックスやアラート、外部 API を安定して構築しやすくなります。速度・信頼性・開発コストのバランスが良く、多くのプロジェクトで「次の一歩」になります。
Geyser gRPC によって、ブロックやログ、アカウント更新のイベントを効率的に取得し、インデックスやアラート、外部 API を安定して構築しやすくなります。速度・信頼性・開発コストのバランスが良く、多くのプロジェクトで「次の一歩」になります。
フェーズ 3 では、Shreds / UDP Forwarding を導入し、損益や UX に直接効いてくるレベルの最速検知に踏み込みます。
複数リージョンで専有 Shreds を展開し、マルチリージョンディスカウントも活用しながら、HFT・MEV・0 スロット戦略に必要な速度帯に入っていく段階です。
複数リージョンで専有 Shreds を展開し、マルチリージョンディスカウントも活用しながら、HFT・MEV・0 スロット戦略に必要な速度帯に入っていく段階です。
重要なのは、「理論上速いから全部 UDP にしよう」という発想ではなく、自分たちのプロジェクトのフェーズと利益構造を踏まえて、どの順番で投資するかを決めることです。
ERPC Bundle と VPS で土台を揃える
ERPC の Bundle プランは、
- RPC（HTTP / WebSocket）
- Geyser gRPC
- Shredstream gRPC（共有）
をまとめて利用できる構成です。
本番環境ではこれまでどおり RPC や WebSocket をメインに使いつつ、同じネットワーク内で Geyser gRPC や Shredstream を併用・検証できます。
本番で動いているアプリと、新しく導入するデータストリームを同一の土台で比較できるため、どこまで踏み込むかを実測ベースで判断しやすくなります。
本番で動いているアプリと、新しく導入するデータストリームを同一の土台で比較できるため、どこまで踏み込むかを実測ベースで判断しやすくなります。
さらに、ERPC と同一ネットワーク内で動作する VPS（EPYC VPS / Premium Ryzen VPS）を組み合わせることで、
- Solana ノードへの距離
- データストリームの種類
- ハードウェア性能
をまとめてチューニングできます。
距離とリーダー位置の前提を満たしたうえで、WS / gRPC / Shreds のすべてにアクセスできる土台を先に用意し、必要になった順に高速レイヤーを解放していく、というアプローチが現実的です。
まとめ：タイミング × 通信特性 × 距離で Solana の速度を設計する
Solana アプリの速度と UX は、
- どのリージョンにサーバーを置き
- どの時間帯にどのリーダーに近い位置を確保し
- どのタイミングのデータを
- どの通信特性で受け取り
- どのようなロジックで処理するか
という複数の要素で決まります。
距離とリーダー位置の前提があり、その上に
- Shreds（もっとも早い段階のデータ）
- Geyser gRPC（確認タイミングの構造化データ）
- RPC / WebSocket（保存済みデータへの API アクセス）
というタイミングの違いがあり、さらに
- UDP
- gRPC（TCP）
- WebSocket（TCP + JSON + TLS）
という通信特性が重なっています。
マーケティング的な名称や印象だけで選ぶのではなく、この三つの軸から自分たちの用途に合う構成を選ぶことで、Solana アプリの速度と UX を設計できます。
ERPC と Validators DAO は、Solana 用途に特化したネットワーク、RPC / gRPC / Shredstream、VPS、専有 Shreds のマルチリージョン割引などを通じて、こうした構成を現実的なコストで実現できるよう支援しています。
データストリーム設計やネットワーク距離の最適化、専有 Shreds / Shared Shreds / Bundle プランや VPS の組み合わせについては、Validators DAO 公式 Discord からいつでもご相談ください。
- ERPC 公式サイト: https://erpc.global/ja
- SLV 公式サイト: https://slv.dev/ja
- elSOL 公式サイト: https://elsol.app/ja
- Epics DAO 公式サイト: https://epics.dev/ja
- Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR
