SEOに関連するニュースリリースを公開しております。
最新のサービス情報を、御社のプロモーション・マーケティング戦略の新たな選択肢としてご活用下さい。
Validators DAO、Solana Stream SDK v1.1.1 を公開 ― 最速 UDP Shreds 向け Rust クライアントのスターターコードをオープンソース化
[25/12/18]
提供元：PRTIMES
提供元：PRTIMES
Solana ネットワーク上で最速レイヤーに位置する UDP Shreds を直接扱う Rust 製クライアントのスターターコードを、新たにオープンソースとして提供開始
[画像1: https://prcdn.freetls.fastly.net/release_image/105962/337/105962-337-932893ab3db478a3b16f2c979a8ba212-2400x1260.jpg?width=536&quality=85%2C75&format=jpeg&auto=webp&fit=bounds&bg-color=fff ]
ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）と Validators DAO が開発・運営する Solana 向けオープンソースストリームクライアント「Solana Stream SDK」は、このたび最新版 v1.1.1 を公開し、Solana ネットワーク上で最速レイヤーに位置する UDP Shreds を直接扱う Rust 製クライアントのスターターコードを、新たにオープンソースとして提供開始しました。
本リリースでは、RPC や WebSocket、gRPC といった後段の API 層を経由せず、バリデータ間で流通する Shreds を UDP で受信し、復元・検知までを最短経路で行うための実装例を提示しています。低レイテンシがそのまま価値に直結する用途において、最速レイヤーを実運用で扱うための具体的な出発点を提供するものです。
検知タイミングの違いという前提
Solana では、同じ出来事であっても、Shreds、Geyser gRPC、RPC / WebSocket のどこから観測するかによって、検知できるタイミングが大きく異なります。検知できるタイミングという観点では、Shreds が最も早く、次に Geyser gRPC、その後に RPC / WebSocket が続きます。
Shreds は、ブロックを構成する断片がバリデータ間で直接やり取りされる段階の情報です。Geyser gRPC は、Shreds を受け取った後、ノード内部で整理されたブロック、ログ、アカウント更新などをイベントとして配信します。RPC / WebSocket は、すでに保存・整理されたデータを問い合わせ・購読するための最上位層に位置します。
UDP Shreds が最速レイヤーとなる理由
Shreds は UDP で配信されます。UDP はコネクション確立や再送制御、順序保証といった付帯処理を持たず、プロトコルとしてのオーバーヘッドが最小限に抑えられています。そのため、同一条件下では TCP を前提とする gRPC や WebSocket よりも早くデータが到達します。
Solana において最速の検知を狙う場合、UDP Shreds がファーストチョイスとなるのは、この通信特性とネットワーク設計による必然です。
なぜ pump.fun を例にしているのか
UDP Shreds を用いた最速検知について、Validators DAO にはこれまで数多くの問い合わせが寄せられてきました。その中でも特に多かったのが、pump.fun におけるトークンミントや初動の売買を、可能な限り早く検知したいという要望です。
トークンミントや初動トレードは、数十ミリ秒単位の差が結果に影響します。pump.fun は、最速レイヤーの性質と価値が最も分かりやすく現れる対象であり、需要が集中している具体例でもあります。今回公開したスターターコードでは、この実運用上の需要を踏まえ、pump.fun を例にした検知ロジックをデフォルト構成として用意しています。これは用途を限定するものではなく、最速検知を現実的に再現できる形で示すための実例です。
すべてを見るのではなく、意味のあるものに反応する
UDP Shreds を扱うと、非常に大量のトランザクションが流れ込みます。その中には、戦略や UX 上の判断に影響しない、極めて小さな取引も含まれます。
本スターターコードでは、こうしたノイズを抑えるため、金額の閾値を設定し、それ以上の取引のみを検知対象とすることのできる設計を採用しています。このフィルタは RPC による後段確認ではなく、Shreds を復元した直後の検知評価段階で適用されます。なお、この閾値は任意であり、0 を指定すれば、すべての取引を拾う構成にすることも可能です。用途に応じて、どこまで拾うかを利用者自身が定義できます。
[画像2: https://prcdn.freetls.fastly.net/release_image/105962/337/105962-337-661e6131e987bdf853021c78597166a8-1404x2240.jpg?width=536&quality=85%2C75&format=jpeg&auto=webp&fit=bounds&bg-color=fff ]
上記は、pump.fun に関連するトークンミントや売買のうち、1 SOL 以上の取引のみを検知しているログ例です。必要な情報だけを、最速レイヤーで高密度に捉えている状態を示しています。
速さの代償としての未確定情報
UDP Shreds は、ブロックとして完全に確定する前の情報を含みます。そのため、失敗トランザクションが混ざることや、情報が欠損・前後する可能性は前提として存在します。これは欠点ではなく、最速レイヤーの性質そのものです。
確定や整形を待たずに流れてくる情報を扱うからこそ、他のどのレイヤーよりも早く変化を捉えることができます。本スターターコードは、この前提を明示したうえで、RPC に依存せず Shreds のみで検知を成立させる実装例を示しています。
理解しやすさを重視した構成
内部処理は、受信する → ためる → 復元する → 判定する → 出力する、という流れで整理されています。UDP 受信、FEC バッファ、deshred、ウォッチロジック、出力という役割を分離し、それぞれを独立した構成要素として扱えるよう設計されています。最初はそのまま動かし、必要になった部分から段階的に手を入れていくことができます。
提供情報
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
Solana Stream SDK v1.1.1 および UDP Shreds クライアントに関する質問やフィードバックは、Validators DAO 公式 Discord にて受け付けています。
[画像1: https://prcdn.freetls.fastly.net/release_image/105962/337/105962-337-932893ab3db478a3b16f2c979a8ba212-2400x1260.jpg?width=536&quality=85%2C75&format=jpeg&auto=webp&fit=bounds&bg-color=fff ]
ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）と Validators DAO が開発・運営する Solana 向けオープンソースストリームクライアント「Solana Stream SDK」は、このたび最新版 v1.1.1 を公開し、Solana ネットワーク上で最速レイヤーに位置する UDP Shreds を直接扱う Rust 製クライアントのスターターコードを、新たにオープンソースとして提供開始しました。
本リリースでは、RPC や WebSocket、gRPC といった後段の API 層を経由せず、バリデータ間で流通する Shreds を UDP で受信し、復元・検知までを最短経路で行うための実装例を提示しています。低レイテンシがそのまま価値に直結する用途において、最速レイヤーを実運用で扱うための具体的な出発点を提供するものです。
検知タイミングの違いという前提
Solana では、同じ出来事であっても、Shreds、Geyser gRPC、RPC / WebSocket のどこから観測するかによって、検知できるタイミングが大きく異なります。検知できるタイミングという観点では、Shreds が最も早く、次に Geyser gRPC、その後に RPC / WebSocket が続きます。
Shreds は、ブロックを構成する断片がバリデータ間で直接やり取りされる段階の情報です。Geyser gRPC は、Shreds を受け取った後、ノード内部で整理されたブロック、ログ、アカウント更新などをイベントとして配信します。RPC / WebSocket は、すでに保存・整理されたデータを問い合わせ・購読するための最上位層に位置します。
UDP Shreds が最速レイヤーとなる理由
Shreds は UDP で配信されます。UDP はコネクション確立や再送制御、順序保証といった付帯処理を持たず、プロトコルとしてのオーバーヘッドが最小限に抑えられています。そのため、同一条件下では TCP を前提とする gRPC や WebSocket よりも早くデータが到達します。
Solana において最速の検知を狙う場合、UDP Shreds がファーストチョイスとなるのは、この通信特性とネットワーク設計による必然です。
なぜ pump.fun を例にしているのか
UDP Shreds を用いた最速検知について、Validators DAO にはこれまで数多くの問い合わせが寄せられてきました。その中でも特に多かったのが、pump.fun におけるトークンミントや初動の売買を、可能な限り早く検知したいという要望です。
トークンミントや初動トレードは、数十ミリ秒単位の差が結果に影響します。pump.fun は、最速レイヤーの性質と価値が最も分かりやすく現れる対象であり、需要が集中している具体例でもあります。今回公開したスターターコードでは、この実運用上の需要を踏まえ、pump.fun を例にした検知ロジックをデフォルト構成として用意しています。これは用途を限定するものではなく、最速検知を現実的に再現できる形で示すための実例です。
すべてを見るのではなく、意味のあるものに反応する
UDP Shreds を扱うと、非常に大量のトランザクションが流れ込みます。その中には、戦略や UX 上の判断に影響しない、極めて小さな取引も含まれます。
本スターターコードでは、こうしたノイズを抑えるため、金額の閾値を設定し、それ以上の取引のみを検知対象とすることのできる設計を採用しています。このフィルタは RPC による後段確認ではなく、Shreds を復元した直後の検知評価段階で適用されます。なお、この閾値は任意であり、0 を指定すれば、すべての取引を拾う構成にすることも可能です。用途に応じて、どこまで拾うかを利用者自身が定義できます。
[画像2: https://prcdn.freetls.fastly.net/release_image/105962/337/105962-337-661e6131e987bdf853021c78597166a8-1404x2240.jpg?width=536&quality=85%2C75&format=jpeg&auto=webp&fit=bounds&bg-color=fff ]
上記は、pump.fun に関連するトークンミントや売買のうち、1 SOL 以上の取引のみを検知しているログ例です。必要な情報だけを、最速レイヤーで高密度に捉えている状態を示しています。
速さの代償としての未確定情報
UDP Shreds は、ブロックとして完全に確定する前の情報を含みます。そのため、失敗トランザクションが混ざることや、情報が欠損・前後する可能性は前提として存在します。これは欠点ではなく、最速レイヤーの性質そのものです。
確定や整形を待たずに流れてくる情報を扱うからこそ、他のどのレイヤーよりも早く変化を捉えることができます。本スターターコードは、この前提を明示したうえで、RPC に依存せず Shreds のみで検知を成立させる実装例を示しています。
理解しやすさを重視した構成
内部処理は、受信する → ためる → 復元する → 判定する → 出力する、という流れで整理されています。UDP 受信、FEC バッファ、deshred、ウォッチロジック、出力という役割を分離し、それぞれを独立した構成要素として扱えるよう設計されています。最初はそのまま動かし、必要になった部分から段階的に手を入れていくことができます。
提供情報
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
Solana Stream SDK v1.1.1 および UDP Shreds クライアントに関する質問やフィードバックは、Validators DAO 公式 Discord にて受け付けています。
SEO関連
