Solana Stream SDK、Solana v3 アップグレードへの正式対応を完了

オープンソースの「Solana Stream SDK」は、このたび Solana v3 系アップグレードへの正式対応を完了し、Rust 版・TypeScript 版の両方で新バージョンを公開

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）と Validators DAO が開発・運営する Solana 向けオープンソースストリームクライアント「Solana Stream SDK」は、このたび Solana v3 系アップグレードへの正式対応を完了し、Rust 版・TypeScript 版の両方で新バージョンを公開しました。

Rust Crate「solana-stream-sdk」はバージョン 0.6.1 にて Solana v3 に対応しており、TypeScript / Node.js 向け npm パッケージ「@validators-dao/solana-stream-sdk」はバージョン 0.12.0 にて同様の対応を完了しています。いずれも Shreds および Geyser gRPC のストリームに対応し、Solana v3 および今後の新コンセンサス Alpenglow 時代に向けたリアルタイムデータ処理基盤としてご利用いただけます。

背景 – Solana v3 と Alpenglow 移行に向けた「クライアント側のアップデート」

Solana v3 は、新しいコンセンサス「Alpenglow」に向けた重要な移行フェーズとして位置づけられています。Alpenglow は、従来の TowerBFT と Proof of History を置き換えるかたちで再設計されたコンセンサスアーキテクチャであり、これまで約 12 秒前後であったファイナリティを、およそ 100〜150 ミリ秒級まで短縮することを目標としています。ファイナリティが二桁ミリ秒オーダーまで短縮されると、ブロックの「刻み」とネットワーク上のデータ伝搬のテンポが根本から変わります。

一方で、バリデータや RPC ノードは v3 系への追随のためにビルドやバージョン管理の頻度が増え、運用の難易度が上がっています。Validators DAO は SLV などのツールを通じて、このサーバー側の自動化・最適化を進めてきましたが、同時に「クライアント SDK 側も v3 に対応していなければ、ネットワーク側の進化を十分に生かせない」という課題が浮き彫りになっていました。

特に Shreds や Geyser gRPC のようなストリームインターフェースでは、プロトコルやスキーマの変更に追随していないクライアントは、レイテンシやデータ整合性の面でボトルネックとなります。バリデータ・RPC が v3 へ移行していく中で、クライアントソフトウェアも同時に v3 対応を完了させることが、これまで以上に重要です。

今回の Solana Stream SDK v3 対応は、このギャップを埋め、Alpenglow 時代のストリーム処理を見据えたクライアント基盤を整えるためのアップデートです。

Solana Stream SDK v0.6.1（Rust）と v0.12.0（TypeScript）の対応内容

Solana Stream SDK は、当初から Shreds と Geyser gRPC の両方を対象としたストリームクライアントとして設計されています。今回のリリースでは、Solana v3 および今後の Alpenglow を見据え、特に次の点を中心に更新を行いました。

Rust Crate v0.6.1

Rust 版は、最高性能を求めるトレーダーやインデクサー向けのリファレンス実装として位置づけています。主なポイントは次のとおりです。

• Solana v3 系のプロトコル変更への対応

• Shreds および Geyser gRPC の v3 対応ストリームを Rust の非同期ランタイム上で高効率に処理

• Shreds 用 protobuf 定義のラッパを提供し、ストリーム処理ロジックを実装しやすい構造に整理

• マルチスレッド前提の実装により、高スループット環境でもレイテンシの蓄積を抑制

Rust 版は、Shreds や Geyser gRPC をほぼ限界まで使い切りたいご利用者の皆様に向けた選択肢であり、Solana v3 時代のストリームクライアントとして、まず検証いただきたい実装です。

TypeScript / Node.js 版 v0.12.0

TypeScript / Node.js 版は、JavaScript エコシステムにおける使いやすさと、Rust エンジンによる高性能を両立することを目的に設計されています。今回の v0.12.0 では、次の点を維持・強化しながら Solana v3 に対応しました。

• 既存のイベント駆動インターフェース（emitter.on など）をそのまま利用できるよう、API 署名は従来から継続

• 内部の接続エンジンに Rust と NAPI-RS を採用し、Node.js 単体では処理しきれなかった Shreds も安定して受信可能

• Geyser gRPC と Shreds の双方について、Solana v3 対応後のストリームを扱えるよう調整

多くのご利用者にとっては、package.json のバージョンを 0.12.0 に更新し、既存のイベントハンドリングコードをそのまま再利用するだけで、Solana v3 対応と Node.js 環境での性能向上を同時に得られる構成となっています。

なぜ Node.js だけでは Shreds を受け切れないのか

ShredStream は、Solana の中でも最も低レイテンシで情報量の多いストリームですが、その分だけクライアント側に要求される処理能力も高くなります。フィルターなしで利用した場合、短時間に大量の Shreds が流れ込み、クライアントの実装次第ではレイテンシが少しずつ蓄積し、最終的にはストリームがほとんど進まなくなる現象が発生します。

従来、Node.js 環境では @grpc/grpc-js を用いて gRPC ストリームを処理するケースが一般的でしたが、この構成には構造的な限界があります。

• Node.js のイベントループが単一スレッドであり、protobuf デシリアライズとユーザーコールバックの実行が同じスレッドで行われる

• 大量のメッセージが短時間に到着すると、JavaScript スレッドが処理待ちメッセージで埋まる

• HTTP/2 のフロー制御により、クライアント側のウィンドウサイズが尽きるとサーバーが送信を一時停止し、見かけ上「ネットワークが遅い」「サーバーが止まっている」かのような状態に陥る

表面上はネットワークやサーバー側の問題に見えても、実際にはクライアントが処理しきれず、内部でバックプレッシャーが連鎖的に発生しているだけ、というケースが多く存在します。ShredStream レイテンシに関する既存の記事でも示してきたとおり、Node.js 単体でフィルターなしの Shreds を処理し続けることには本質的な限界があります。

この限界を超えるために採用しているのが、Rust と NAPI-RS を組み合わせるアプローチです。

Rust と NAPI-RS による Node.js 高速化の仕組み

Solana Stream SDK の TypeScript 版では、Node.js 側から見たときの使い勝手を変えずに、内部の重い処理を Rust に任せる構造を採用しています。

• gRPC 接続管理、ストリーム受信、protobuf デシリアライズなど CPU 負荷の高い処理は Rust 側で非同期に実行する

• Node.js 側は、Rust から渡されるストリームを標準的なストリームやイベントエミッターとして扱い、従来どおり emitter.on("event", callback) の形で利用できる

• NAPI-RS により、Node.js と Rust の間のデータ受け渡しを小さいオーバーヘッドで行い、マルチスレッド処理のメリットをそのまま取り込む

これにより、表面的には以前と同じ書き方の TypeScript コードを維持しながら、実際のストリーム処理は Rust の非同期ランタイム上で実行されます。同じマシン・同じネットワーク条件でも、@grpc/grpc-js のみで処理した場合と比べて、Shreds や Geyser gRPC のような高頻度ストリームに対して、レイテンシの蓄積やバックプレッシャーの発生を大きく抑えられる構成になっています。

Shreds と Geyser gRPC の両方をカバーする SDK であることの意味

Solana のリアルタイムデータは、大きく分けて Shreds と Geyser gRPC の二つの層で考えることができます。

Shreds はリーダーに近い位置から送出される非常に低レイテンシの断片的ストリームであり、最も早いタイミングでチェーンの変化を捉えられる一方、データ量が多くクライアント実装の品質がそのまま性能に影響します。Geyser gRPC は、スロットやトランザクション、アカウント更新などを構造化された形で提供するストリームであり、最速ではないが扱いやすいという特長があります。

Solana Stream SDK は、この二つを同じ SDK の中で扱えるように設計されています。

• 最初は Geyser gRPC を用いてストリーム構造やデータ内容を理解する

• さらに低レイテンシや情報量を求める段階で、同じ SDK を用いたまま Shreds 側を活用する

という段階的な開発パスを取ることができます。Alpenglow によってブロック生成とファイナリティのテンポが変わっていく中で、こうした二層構造のストリーム設計を単一の SDK 群でカバーできることは、開発・運用双方にとって大きな利点です。

すぐに試せるリソースと検証環境

Solana Stream SDK は、Rust と TypeScript の両方でオープンソースとして公開されており、GitHub には Shreds と Geyser gRPC の双方に対するサンプルコードやクイックスタートが用意されています。

Rust Crate（v0.6.1）: https://crates.io/crates/solana-stream-sdk 

npm（TypeScript, v0.12.0）: https://www.npmjs.com/package/@validators-dao/solana-stream-sdk 

GitHub - Solana Stream SDK: https://github.com/ValidatorsDAO/solana-stream 

また、ERPC では ShredStream を含む高速ストリームを 1 日無料で試せるトライアルプランを提供しており、実運用に近い環境で Solana Stream SDK の挙動や性能改善を検証することが可能です。

ERPC 公式サイト（日本語）: https://erpc.global/ja 

Validators DAO コミュニティへの参加と今後の展開

Solana Stream SDK に関するご質問や改善要望、Solana v3 / Alpenglow 時代のストリーム設計に関するディスカッションは、Validators DAO 公式 Discord にて受け付けております。実プロジェクトで Shreds や Geyser gRPC を活用されている皆様のフィードバックは、SDK の品質向上にとって極めて重要です。

Validators DAO 公式 Discord:  https://discord.gg/C7ZQSrCkYR 

Solana v3 と Alpenglow により、Solana ネットワークはこれまで以上に高速でリアルタイム性の高いインフラへと進化していきます。Validators DAO と ELSOUL LABO は、その変化を最大限活用できるオープンソースツール群を継続的に提供し、開発者の皆様とともに次世代のリアルタイムアプリケーションを支える基盤づくりに取り組んでまいります。

引き続きのご支援を、どうぞよろしくお願いいたします。