Validators DAO、Solana Stream SDK の TypeScript 版 Yellowstone Geyser gRPC クライアントを更新。NAPI-RS 対応により、高頻度ストリーム処理の性能と安定性を強化
gm! Validators DAO の kishi.sol です。
ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）および Validators DAO は、Solana 向けオープンソースストリーミング基盤「Solana Stream SDK」において、TypeScript 版クライアントのメジャーバージョンアップデートをリリースし、Yellowstone Geyser gRPC の TypeScript クライアントで NAPI-RS（Rust ネイティブ）を利用できる構成へ対応したことをお知らせいたします。
本更新により、TypeScript の開発体験を維持したまま、高頻度ストリーム処理における処理余力と安定性を引き上げ、ピーク時のトラフィックや連続イベントの局面でも破綻しにくい基盤として扱える状態へ近づけています。あわせて、スターターコードについても、単に接続確認ができる段階に留めず、Production-Ready として運用と拡張を前提に据えた構造へ整理しました。
TypeScript でリアルタイムストリームを扱う現実的な条件
Solana のストリームは、トレード、監視、分析、運用判断など、リアルタイム性が価値に直結する領域で利用されます。一方で、実際の開発現場では Web ベースの構成が前提となる場面が多く、TypeScript は開発速度、保守性、チーム編成の柔軟性、引き継ぎの現実性という観点で強い選択肢です。したがって重要なのは、TypeScript で書けるという表層ではなく、TypeScript のまま高頻度ストリームを現実的に処理でき、長期運用で崩れない形に整えることです。
Node.js のシングルスレッドで詰まりやすい理由と、ピーク時に顕在化する問題
高頻度ストリームでは、受信の連続性、処理の追従、フィルタ適用、デコード、下流ロジックの実行が同時に走り続けます。このとき、Node.js 単体のシングルスレッド処理経路は、ピーク時のバーストや短時間の集中負荷でバックプレッシャーが発生しやすく、結果として遅延の増大、処理の滞留、取りこぼしの増加、再接続の頻発といった形で問題が顕在化しがちです。
TypeScript は開発しやすく、保守もしやすく、実装も早く進みます。しかし、リアルタイムストリームのピーク局面では、この利点を維持したまま処理余力を確保できるかが、実運用における分水嶺になります。今回の更新は、この現実的な条件を満たすための改善です。
これまでの NAPI-RS 適用範囲と、今回の更新で広がった範囲
これまで Solana Stream SDK では、TypeScript 側で NAPI-RS を活用していた領域は主として Shreds gRPC TypeScript クライアントでした。今回の更新により、利用者の多い選択肢である Yellowstone Geyser gRPC の TypeScript クライアントでも、NAPI-RS（Rust ネイティブ）を利用できる構成へ対応しました。
これにより、TypeScript のまま Rust ネイティブの低オーバーヘッドな処理経路を取り込める領域が拡大し、ストリーム処理全体としての安定性と追従性を引き上げやすくなります。社内計測では、ピーク負荷を与えた際のバックプレッシャー耐性が大幅に改善しており、最大で約 4 倍程度の余力改善が確認されています。ここでの要点は数値そのものではなく、ピーク時に「詰まって壊れる」挙動を避け、運用の前提として扱える範囲を押し上げた点にあります。
このNAPIという技術は類似のWASM（WebAssembly）と比較しても、ネイティブコードとして直接動作するため、より低いレイテンシと高いスループットを実現します。Solana Stream SDK における NAPI-RS の活用は、TypeScript の開発体験を維持しつつ、リアルタイムストリームの処理性能を引き上げるための重要な要素です。
Yellowstone Geyser gRPC を TypeScript のまま扱う意味
Geyser gRPC は、トランザクション、アカウント更新、スロットなどを低遅延で受け取るための中核インターフェースです。イベント検知の遅延や欠落は、トレードでは機会損失に直結し、監視や運用では判断の遅延を生み、プロダクト側では信頼性と開発コストに跳ね返ります。
この中核を TypeScript のまま、ピーク時も含めて現実的に運用できる状態へ近づけることは、単なる速度の話ではありません。開発と運用の両方で現場の負担を下げ、継続的に改善できる基盤として成立させるための条件整理です。
スターターコードを Production-Ready として再定義した理由
これまでのスターターコードは、導入初期に「すぐにつなぐ」ことを優先する入口として機能してきました。一方で、実運用では、切断、再接続、ストリームの連続性、欠落や重複、不要通信を抑えた購読設計、ピーク時の負荷制御といった論点を避けて通れません。入口が軽すぎるほど、後から現実要件を継ぎ足す際に構造の歪みが生まれ、結果として改修コストが増えます。
今回の更新では、この入口を「運用に耐える土台」として扱えるよう、構造と導線を整理しました。これにより、導入直後から本番運用へ向けた実装を一直線に進められ、必要な拡張に集中できる状態を目指しています。
構造整理により、どこを触ればよいかを明確化
TypeScript 側では、処理の責務を分離し、拡張時に触るべき箇所が明確になる構成へ整理しています。具体的には、起動や配線に寄せた最小限のエントリに対し、処理は handlers に分離し、利用者がロジックを挿入するポイントを hooks（onTransaction / onAccount など）として見える形に整理しています。これにより、トレードロジックや検知ロジック、フィルタ方針、出力先の差し替えといった現実的な改変が、局所的に行える形になります。
購読定義についても、JSON の運用を前提とした形を避け、TypeScript コードでフィルタを定義する方式へ統一しています。CommitmentLevel.PROCESSED のような読みやすい指定や、型の恩恵を前提にした保守が可能になり、設定と実装の乖離を抑えやすくなります。
安定運用に直結する機構を入口から前提化
高頻度ストリームでは、速さと同じくらい「壊れないこと」が重要です。本更新では、バックプレッシャー対策（bounded queue、drop logging）、受信・処理・ドロップの可視化のためのメトリクス、接続維持（ping / pong）、指数バックオフ、再接続時の from_slot を用いたギャップリカバリなど、運用で問題化しやすい論点を入口から前提として扱える形で継続提供しています。
これらは追加機能ではなく、ストリームを本番で扱うなら最初から必要になる現実条件です。スターターコードを Production-Ready として扱う上で、この前提を外さずに整理することを重視しています。
想定する利用者像
本アップデートは、TypeScript で Solana のリアルタイムストリームを本番運用したい開発者の皆様、Yellowstone Geyser gRPC を用いた高速検知・トレード・監視システムを構築するチームの皆様、ならびにピーク時の処理余力や再接続挙動に課題を感じている開発者の皆様を想定しています。TypeScript の利点を保ったまま、ストリーム基盤の実運用性を引き上げるための更新です。
リファレンス
Solana Stream SDK の更新内容は GitHub にて公開しています。フィードバックについては GitHub 上または Validators DAO 公式 Discord にて受け付けています。
また、ERPC では Solana ストリーミング基盤を複数リージョンで提供しており、Solana Stream SDK のスターターコードを用いて、実際の Geyser gRPC 環境で挙動を確認しながら導入を進めることができます。ERPC の無料トライアルを通じて、SDK とストリーミング基盤を組み合わせた実運用に近い形での検証も可能です。詳細は ERPC 公式ページにて案内しています。
