ミリ秒単位の競争を制する：シュレッド、LaserStream、そしてSolanaでの優位性

シュレッドとは？

シュレッドはSolanaの高性能なデータ伝播を支える基本単位であり、オンチェーンの状態変化へ早期にアクセスできるようにします。

Solanaは、速度とスループットを最大化するよう設計されています。そのため、ブロックを単一の大きな単位としてネットワーク全体に送信することはできません。代わりに、ブロックはシュレッドと呼ばれる小さなパケットに分割されます。これはSolanaにおけるデータ伝播の最小単位です。 

これらのシュレッドは、ブロックに組み立てられる前のトランザクションデータの一部を表します。各シュレッドのサイズは約1.2 KBで、標準的なネットワークパケットの最大伝送単位（MTU）内に収まるよう最適化されています。これにより、断片化を起こさず極めて高速に配信できます。 

シュレッドには2つの種類があります。

データシュレッド

データシュレッドは、ブロックの中核となるトランザクションデータを固定サイズに分割して格納します。効率的に処理できるよう、件数を示す値が先頭に付いたトランザクショングループである、シリアライズ済みのエントリバッチが含まれます。

コーディングシュレッド

コーディングシュレッドは、パリティデータを生成する前方誤り訂正技術であるReed-Solomon消失訂正符号を使用して冗長性を提供します。これにより、欠落または破損したシュレッドを復元できます。コーディングシュレッドは、データシュレッドとともに前方誤り訂正（FEC）セットにまとめられます。通常は最大50%のパケット損失に耐えられるよう、均等な比率（例：データシュレッド32個に対してコーディングシュレッド32個）で構成されます。リーダーはネットワーク状況に応じてこの比率を調整し、高い信頼性を維持できます。

Solanaでシュレッドはどのように伝播されますか？

このプロセスは、リーダー（現在ブロック生成を担当しているバリデータ）がトランザクションをバッチ化し、エントリへシリアライズするところから始まります。その後、これらのエントリはシュレッドと呼ばれる小さなセグメントに分割、つまりシュレッド化されます。Solanaのシュレッド仕様に定義されているとおり、すべてのシュレッドは従来方式（各シュレッドへ個別に署名）またはMerkleベースの方式（FECセット全体のMerkleルートへ署名）のいずれかでリーダーによって署名されます。これにより、真正性とデータの完全性が確保されます。 

シュレッドは、Solanaの多層型ファンアウト伝播システムであるTurbineを使用して他のバリデータへ送信されます。Turbineでは、リーダーがシュレッドをルートノードへ送信し、ルートノードがツリー状の構造で後続層のバリデータへ配信します。各層は、1層あたり200ノードのファンアウトで次の層へ転送します。通常、アクティブなバリデータ数に応じて2～3ホップにわたります。このツリー構造により、帯域幅を抑えながら、数ミリ秒でネットワーク全体へトランザクションを配信できます。

ステーク加重シャッフルでは、ステーク量の多いバリデータへの配信が優先されます。Turbineはまず、保有するステーク量（ステークウェイト）に基づいてバリデータを並べ替えます。ステーク量の多いバリデータほどリストの上位に配置され、決定論的シャッフルの後もリーダーに近いツリーの早い層に配置される傾向があります。つまり、ホップ数が少ないほどレイテンシも低くなります。そのため、ステーク量の多いバリデータほどシュレッドを早く受信します。   

注： Alpenglowの実装後、Turbineは将来的にRotorへ置き換えられます。こうした変更後も、バリデータのステーク量は、そのバリデータがどのピアへブロードキャストするかに影響します。

シュレッドはどのようにブロックへ再構築されますか？

バリデータがシュレッドを受信すると、まず署名を検証して真正性を確認します。次にReed-Solomon消失訂正符号を使用し、FECセット内の利用可能なコーディングシュレッドから、欠落または破損したデータシュレッドを復元します。 

その後、復元されたデータシュレッドをデシュレッドします。つまり、シュレッドインデックスを使用してペイロードを順番に連結し、シリアライズ済みのエントリバッチを再構成します。 

次に、これらのバッチを個々のトランザクションとエントリへデシリアライズし、完全なブロックへ組み立てます。

シュレッドが重要な理由 

タイミングが最重要となるネットワークで、反応できる時間を短縮するため、シュレッドは重要です。 

シュレッドは、Solanaの高性能という利点を引き出すうえで不可欠です。特に、高頻度取引、見積依頼（RFQ）デスク、清算エンジン、オラクル更新など、レイテンシに敏感なアプリケーションで重要です。 

他の多くのブロックチェーンでは、完全なブロックの生成と確認を待つ必要があり、数百ミリ秒から数秒の遅延が発生する場合があります。一方、シュレッドを使用すると、発生しつつあるオンチェーンイベントを最も早い段階で把握できます。 

生のシュレッドは扱いにくい場合があります。受信側で真正性を検証し、欠落したデータシュレッドを復元し、デシュレッドとデシリアライズによってトランザクションとエントリへ変換したうえで、最終的にスワップやアカウント変更などの実行可能なイベントを解析する必要があるためです。

このパイプラインを構築せずにシュレッドの低レイテンシという優位性を得たい場合、Preprocessed Transactionsが代わりにデシュレッドを行い、processedコミットメントレベルより最大8ms早く、署名済みトランザクションをWebSocket経由でストリーミングします。

ただし、保留中のトランザクションやアカウント更新を「先読み」できることは比類のない優位性となり、競争の激しい場面での成功率向上に直結します。

たとえば、担保比率を監視する清算ボットは、WebSocketsなどの遅い手法を使用する競合よりもはるかに早く、シュレッドを使って脆弱なポジションを検出して対応し、清算を獲得できます。 

シュレッドレイテンシの階層

シュレッドのレイテンシは、すべてのソースで一様ではない点に注意することが重要です。

ステーク量の多いバリデータ

多額のステークを持つバリデータは、Turbineの伝播ツリーで最優先されます。ステーク加重Quality of Service（SWQoS）の恩恵を受け、多くの場合、リーダーまたは早い段階のファンアウト層からシュレッドを直接取り込みます。

ステーク済みバリデータ

一定量のステークを持つバリデータでは、伝播キュー内の優先度が低く、シュレッドが追加のホップを経由する必要があるため、中程度の遅延が発生します。コンセンサスへ参加することで信頼性の高いアクセスは確保されますが、ネットワーク上の位置や現在のステーク分布によってレイテンシが多少変動する可能性があります。ステーク量の少ないバリデータは、ステーク量の多いバリデータと比べ、競争が極めて激しく時間に敏感な処理には適していません。

ステークなしのバリデータ

ステークを持たないバリデータには、ステーク済みノードが持つQuality of Service上の利点がありません。そのため、レイテンシが極めて重要な処理向けにSolanaのリアルタイムデータをストリーミングする用途には適していません。Turbineのファンアウトでシュレッドを最後に受信します。

ツリー内で早い位置にいるほど、ネットワークの他の部分が追いつくまでに対応できる時間が増えます。 

グローバルな変動性 

重要なのは、Turbineがロケーションに依存しないことです。物理的な距離やネットワーク状況によってTurbineのホップ以外にも遅延が加わるため、グローバルな伝播ではレイテンシの変動が大きくなる可能性があります。 

たとえば、リージョン間を移動するシュレッド（米国のリーダーからアジア太平洋地域のバリデータへ送信される場合など）では、大陸間ルーティング、パケット再送、さらにはピアリングの問題によって遅延が発生する可能性があります。これはTurbineの早い層にいるステーク量の多いバリデータでも同様です。

この地理的な分散には、最適化の余地があります。単一の高ステークバリデータがローカルでは優れていても、配置が最適でなければグローバルでは遅れる可能性があります。分散型シュレッドネットワークで複数のソースから可能な限り高速なシュレッドを集約すれば、この問題を軽減できます。これにより変動を抑え、一貫した取り込み速度を実現できます。このようなシステムは、グローバルな状況で最上位のステークを持つバリデータを一貫して上回る可能性があります。

レイテンシが極めて重要なシステムを構築する開発者が競争優位性を維持するには、最適化されたソースからシュレッドへ確実にアクセスできることが不可欠です。ただし、復旧、検証、グローバル配信を効果的に処理するには、堅牢なインフラストラクチャが必要です。また、Solanaで広く使われているリアルタイムデータストリーミングツールの多くは、現在シュレッドを活用していません。

Solanaでのデータストリーミング

Solanaでリアルタイムデータをストリーミングする場合、開発者にはいくつかの選択肢があります。それぞれ、レイテンシ、信頼性、複雑さの面で異なるトレードオフがあります。

webhook

webhookではイベント駆動型の更新が可能で、特定のアカウントやプログラムに変更が発生したときに、アプリケーションへデータをプッシュします。プログラムから簡単に統合できるほか、Helius Dashboardからコードを一切書かずに設定することもできます。開発者は、特定のトランザクションタイプについて人間が読める形式に解析されたデータや、生のトランザクションペイロードをストリーミングできます。さらに、これらの更新を整形済みメッセージとして特定のDiscordチャンネルへ直接ストリーミングすることもできます。

webhookは信頼性が高く、Solana上の多くの有名企業で使用されていますが、通知が送信されるのはトランザクションの確認後です。つまり、webhookはシュレッドレベルのデータより数百ミリ秒遅れる可能性があり、高頻度取引や清算など、レイテンシが極めて重要な処理には遅すぎます。

標準WebSockets

SolanaのJSON RPC APIは、アカウント変更用のaccountSubscribe、トランザクションログ用のlogSubscribe、プログラムイベント用のprogramSubscribeなどのWebSocketサブスクリプションをサポートしています。WebSocketsはクライアントとRPCプロバイダー間の接続を維持し、トランザクションやアカウント変更が処理されると同時に更新をストリーミングします。WebSocketsは双方向通信に対応しており、ポーリングのオーバーヘッドを抑えながら、特定のアカウントやイベントをリアルタイムで監視するのに適しています。

ただし、webhookと同様に、WebSocketsはシュレッドの再構築後（つまり、processed、confirmed、finalizedのいずれかのコミットメントレベル）にデータを配信します。そのため、コミットメントレベルに応じて400ms～30秒のレイテンシが加わります。 

WebSocketsは接続が不安定になりやすい方式とも見なされており、さまざまな問題で接続が切断される可能性があるため、独自の再試行ロジックが必要です。ポーリングで補完しない限り、切断によってデータが永久に失われる可能性があり、リアルタイム性の信頼性が損なわれます。 

Enhanced WebSockets

Enhanced WebSocketsは標準WebSocketsを大幅に改善し、複数のパフォーマンス最適化と強化されたフィルタリング機能を提供します。特に、イベント解析の改善とノイズの削減により、本番環境で開発者が扱いやすくなっています。

Enhanced WebSocketsは標準WebSocketsよりレイテンシを短縮でき、一般的なストリーミングアプリケーションに最適です。たとえば、標準WebSocketsやwebhookと比較すると、Enhanced WebSocketsでPump AMMデータをストリーミングする場合には明確なパフォーマンス差があります。 

ただし、Enhanced WebSocketsも基本的にはシュレッドの再構築後にデータを配信します。そのため、1ミリ秒単位の差が重要となるアプリケーションでは、やはり有用性が制限されます。また、機能は強化されているものの、自動リプレイやフェイルオーバーがないため、データ欠損を手動で処理する必要があります。 

Yellowstone gRPC

Yellowstone gRPCは、バリデータからクライアントへデータをストリーミングする低レイテンシのプロトコルで、シュレッドレベルのデータへアクセスできます。それぞれのコミットメントレベルで更新をより高速に配信できるため、WebSocketsやwebhookより大幅に高速です。 

Yellowstoneは、サブスクリプションを即座に作成・解除できる双方向ストリーミングに加え、特定のトランザクション、アカウント、プログラムの更新に応じて受信するデータを正確に制御できる高度なフィルタリング機能を提供します。

Yellowstoneは、レート制限やクレジットがなく、カスタムノード構成向けの専用ハードウェアが保証される環境を求めるユーザーに最適です。ただし、いくつかの大きなトレードオフがあります。

1. インフラストラクチャの負担

Yellowstone gRPCの能力を最大限に活用するには、独自の専用ノードが必要です。これには、ハードウェアへのアクセス、適切な構成、そのハードウェアの継続的な管理、ハードウェア関連の問題をデバッグするための専門知識が必要です。

2. レイテンシの変動

Yellowstone gRPCがシュレッドレベルでデータを配信できるからといって、常に最適な方法で配信されるとは限りません。レイテンシはプロバイダーだけでなく、専用ノードがシュレッド向けに最適化されたソース（ステーク量の多いバリデータ）とペアリングされているかどうかによっても変わります。ステーク量が中程度または少ないバリデータとペアリングすると、常にTurbineの最初の層に入るわけではないため、多くのシュレッドで引き続き下流に位置することになります。

3. 障害リスク

単一の専用ノードへ依存すると、単一障害点が生じます。Yellowstone gRPCにはネイティブのリプレイ機能がないため、この問題はさらに深刻になります。

4. リソース要件

Yellowstoneでデータをストリーミングしながら、負荷の高いRPC呼び出しで専用ノードを過負荷にすると、パフォーマンスが低下する可能性があります。 

長年にわたり、多くのチームにとってYellowstone gRPCはSolanaのリアルタイムデータを扱う定番のストリーミングサービスでした。高速で上級ユーザーに適していますが、世界各地に専用ノード群を用意しなければ、一貫したグローバルかつ低レイテンシのカバレッジを運用することは困難です。

LaserStream

LaserStreamは、シュレッドレベルの取り込み速度と、グローバルに分散されたサービスの信頼性および到達範囲を組み合わせています。複数の専用ノードを運用するコストや運用上の負担はありません。 

LaserStreamは、次の機能によってこれを実現します。

• マルチソース取り込み：LaserStreamは最もレイテンシの低いシュレッドを取り込み、世界中で競合を一貫して上回ります。
• グローバルカバレッジ：LaserStreamは世界各地の複数リージョンで利用でき、開発者は自身のインフラストラクチャに最も近いエンドポイントを使用できます。各リージョンでは冗長化のため複数のサーバーが稼働し、自動フェイルオーバーも備えています。
• データ欠損ゼロ：LaserStreamの履歴リプレイにより、最大48時間前までの最近のブロックチェーンデータを再生できます。これは切断への対応やデータの連続性確保に役立ちます。 
• 開発者に優しい体験：LaserStreamはYellowstone gRPCからそのまま置き換えられます。移行も、新しい構文も、面倒な作業も必要ありません。

要するに、LaserStreamはYellowstone gRPCとWebSocketsを、スケーラビリティ、低レイテンシ、耐障害性の面で改善したサービスです。数百万規模のステークを保有したり、高性能インフラストラクチャを自ら運用したりすることなく、オンチェーンイベントがネットワークで発生すると同時に一貫して取得できます。 

LaserStreamは、Solanaで超低レイテンシのデータストリーミングを実現するためにシュレッドの力を活用する、最も簡単な方法です。

クライアントとパフォーマンス

LaserStreamのクライアントは、Go、Rust、JavaScript/TypeScriptで利用できます。これらのクライアントは、ストリーミング済みのスロットを継続的に追跡し、切断時の自動リプレイを処理します。何らかの理由で切断が発生した場合、クライアントは自動的に再接続し、最後に処理されたスロットからストリーミングを再開します。

LaserStreamのJavaScriptクライアントは、ネイティブRustバインディングを使用している点で特に注目に値します。これにより、クライアントは1.3 GB/sのスループットを実現します。これは、最大30 MB/sの現行Yellowstone gRPC JavaScriptクライアントと比べて40倍の改善です。 

Solanaが今後もスケールを続けるにつれ、Yellowstone gRPC JavaScriptクライアントは対応が難しくなります。LaserStreamのJavaScriptクライアントには十分なパフォーマンス余力があるため、需要が増えてもアプリケーションをネットワークとともに安全にスケールできます。 

実環境での成果

低レイテンシのDEXアグリゲーターであるDFlowは、価格エンジンへデータを供給するため、最近LaserStreamを統合しました。専用ノードを気にすることなくグローバルにスケールでき、エンジニアリングのリソースを節約してルーティングやビジネスロジックへ集中できる点が、統合の決め手となりました。 

統合後、DFlowは繰り返し発生していたエンジニアリング作業を8時間以上削減し、データストリーミングを中断することなく100%の稼働率を維持し、トランザクション確認の高速化によって見積速度を向上させたと報告されています。 

今すぐ、より高速なストリーミングを。

ミリ秒は単なるレイテンシではなく、機会そのものです。LaserStreamなら、ネットワークに追随するだけではありません。常にその先を進めます。 

取引、清算、オラクル向けに1秒未満でデータを取得したいですか？LaserStreamを使用して、利用可能な最速のSolanaデータへアクセスしてください。 

また、パワーユーザー向けに、生のシュレッド配信へ関心がある場合は、こちらのフォームへ入力してお問い合わせください。

関連リソース

• LaserStream
• Agaveのシュレッドモジュール
• Solanaのシュレッド仕様