Solana Stream SDK v1.1.1公開：UDP Shreds直受信のRustクライアント

最速レイヤーに直接触れる：Solana Stream SDK v1.1.1 が公開される背景と狙い

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）と Validators DAO が共同で開発・運営するオープンソースの Solana 向けストリームクライアント「Solana Stream SDK」が、最新版 v1.1.1 を公開し、UDP Shreds を直接受信する Rust 製クライアントのスターターコードをオープンソース化しました。リリース日時は 2025年12月18日 00時35分 です。

この公開は、RPC や WebSocket、gRPC といった上位 API 層を経由せず、バリデータ間で流通する Shreds を UDP で受信し、復元・検知までを最短経路で行う手法の実装例を提示することを目的としています。低レイテンシが直接的に価値に繋がる用途に対して、実運用で利用可能な出発点を提供します。

公表元と配布先

公開ソースコードや配布物は以下の URL で入手できます。開発・配布元の連絡や問い合わせは Validators DAO 公式 Discord 上で受け付けています。

• GitHub（Solana Stream SDK）：https://github.com/ValidatorsDAO/solana-stream
• Rust Crate：https://crates.io/crates/solana-stream-sdk
• ERPC ホームページ：https://erpc.global/ja
• Validators DAO 公式 Discord：https://discord.gg/C7ZQSrCkYR
• リリース原文（関連リンク）：https://labo.elsoul.nl/ja/news/2025/12/17/validators-dao-solana-stream-sdk-v111-udp-shreds-rust-client/

開発は Validators DAO と ELSOUL LABO B.V. の協働によって行われており、公開されたスターターコードは実運用を想定した設計が反映されています。

UDP Shreds を選ぶ理由と検知タイミングの違い

Solana では同一の出来事でも、どのレイヤーから観測するかにより「検知可能なタイミング」が大きく異なります。Shreds、Geyser gRPC、RPC / WebSocket の順で検知が遅くなりますが、最も早く観測できるのは Shreds（UDP）です。

Shreds はブロックを構成する断片がバリデータ間で直接やり取りされる段階の情報で、Geyser gRPC はノード内部で整理されたイベント（ブロック、ログ、アカウント更新など）を配信します。RPC / WebSocket は保存・整理されたデータを問い合わせる最上位層に相当します。

UDP が最速となる技術的要因

Shreds は UDP で配信されます。UDP はコネクション確立や再送制御、順序保証といった付帯処理を持たないためプロトコルのオーバーヘッドが最小限です。これに対し、gRPC や WebSocket は TCP を前提とした設計で、接続確立や再送、順序保証のための処理により到達時間が相対的に長くなります。

そのため、同一条件下では UDP Shreds の受信が最も早い観測手段となり、最速検知が求められる用途では UDP Shreds がファーストチョイスとなります。

Shreds（UDP）

最速。未確定・断片的な情報を含むが、最短で変化を検知できる。

Geyser gRPC

ノード内で整理されたイベントを配信。Shreds より遅いが、ある程度整形された情報を受け取れる。

RPC / WebSocket

保存・整理済みデータを問い合わせる最上位層。最も確定的だが検知は遅い。

実装の構成と設計方針：復元から判定までの流れ

公開されたスターターコードは、UDP 受信から最終的な検知出力までを明確なステップに分解して示しています。内部処理は 受信する → ためる → 復元する → 判定する → 出力する という流れで整理されており、役割ごとに独立したコンポーネントとして実装されています。

それぞれの役割は段階的に手を入れられるよう設計されており、まずはそのまま動かして挙動を把握し、必要な部分だけ調整してカスタマイズする運用が想定されています。

各コンポーネントの役割

• UDP 受信：バリデータ間で流通する Shreds を UDP で受け取る部分。高速な受信が最優先。
• FEC バッファ：Forward Error Correction（FEC）に基づくバッファリング。欠損や順序ずれを補正するための一時保管領域。
• deshred（復元）：Shreds の断片からトランザクションデータやブロック情報を再構成する処理。
• ウォッチロジック（判定）：復元した情報に対して条件判定やフィルタリングを適用する部分。閾値による絞り込み等を含む。
• 出力：検知結果をログ、イベント、または外部システムに渡すための出力処理。

これらの分離により、開発者は個々のパーツを独立して改善・置換でき、実運用に即した段階的な導入が可能です。

pump.fun を例にした検知ロジックと運用上の注意点

Validators DAO には、UDP Shreds を利用した最速検知に関する問い合わせが多く寄せられてきました。特に多かったのが pump.fun におけるトークンミントや初動トレードを可能な限り早く検知したいという要望です。これらは数十ミリ秒単位の差が結果に影響するため、最速レイヤーの価値が最もわかりやすく現れる対象です。

今回公開されたスターターコードでは、pump.fun を例にした検知ロジックをデフォルト構成として組み込んでいます。これは用途を限定するためのものではなく、最速検知を現実的に再現できる実例として提供されています。

ノイズ対策とフィルタリング

UDP Shreds を扱うと大量のトランザクションが流れ込み、その中には戦略や UX に影響しない小規模トランザクションも多く含まれます。本スターターコードはノイズを抑えるために、金額の閾値を設定し、それ以上の取引のみを検知対象とする設計を採用しています。

閾値は 任意設定であり、0 を指定すればすべての取引を拾う構成にすることも可能です。デフォルト例としては、pump.fun に関連するトークンミントや売買のうち 1 SOL 以上 の取引のみを検知しているログが示されています。フィルタは Shreds を復元した直後の検知評価段階で適用され、RPC による後段確認を必須としない点が特徴です。

ただし、UDP Shreds はブロックとして完全に確定する前の情報を含むため、失敗トランザクションや情報の欠損・順序の前後が混在する可能性があります。これは最速レイヤーの性質そのものであり、確定情報が必要な場合は別途 RPC 等による追確認が必要です。

問い合わせとフィードバックの窓口

Solana Stream SDK v1.1.1 および UDP Shreds クライアントに関する質問やフィードバックは、Validators DAO の公式 Discord で受け付けています。実装の詳細や運用上の注意点については GitHub のリポジトリと Crates.io のページを参照のうえ、必要に応じて開発者コミュニティに相談する運用が推奨されます。

配布元と連絡先情報の一覧は次の通りです。

• GitHub：https://github.com/ValidatorsDAO/solana-stream
• Crates.io：https://crates.io/crates/solana-stream-sdk
• ERPC：https://erpc.global/ja
• Discord：https://discord.gg/C7ZQSrCkYR

公開情報の整理と重要ポイントのまとめ

以下は本記事で触れたリリース内容、提供物、技術的留意点を整理した表です。実際に導入を検討する際のチェックリストとして活用できます。

上記表は、今回公開された Solana Stream SDK v1.1.1 と UDP Shreds 向け Rust クライアントの主要な要点を整理したものです。実運用にあたっては、最速検知のメリットと未確定情報を扱うリスクを踏まえ、閾値設定や後段確認の要否を検討する必要があります。提供されている GitHub リポジトリや Crates.io のパッケージ、公式 Discord を通じて詳細なドキュメントやサンプルコードを確認することが推奨されます。

最後に、プレスリリース素材として使用された画像ファイルがダウンロード可能である旨が明記されています。配布物や詳細は上記の関連リンクを参照してください。