ミリ秒競争を制する：Shred、LaserStream、そしてSolanaの優位性

Shredとは？

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

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

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

Shredには2つの種類があります。

Data Shred

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

Coding Shred

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

Solanaでshredはどのように伝播されるのか？

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

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

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

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

Shredはどのようにブロックへ再構成されるのか？

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

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

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

Shredが重要な理由 

タイミングが何より重要なネットワークにおいて、shredは反応可能な時間を短縮するからこそ重要です。 

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

多くの他のブロックチェーンでは、アプリケーションはブロックの生成と確認が完了するまで待つ必要があり、数百ミリ秒から数秒の遅延が生じることがあります。一方、shredを使用すれば、発生しつつあるオンチェーンイベントを最も早く把握できます。 

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

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

しかし、保留中のトランザクションやアカウント更新を「先取り」できることは、他に類を見ない優位性をもたらし、競争の激しい状況で成功率を直接高めます。

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

同様に、市場の非効率性を特定する裁定取引業者や、価格を提示する低レイテンシのDEXアグリゲーターも、このレイテンシ上の優位性から恩恵を得られます。収益性は数ミリ秒の差で決まるためです。

Shredレイテンシの階層

Shredのレイテンシは、すべてのソースで一様ではない点に注意が必要です。

高ステークのバリデータ

大量のステークを持つバリデータには、Turbineの伝播ツリーで最も高い優先度が与えられます。多くの場合、リーダーから直接、またはファンアウトの上位階層でshredを取り込み、ステーク加重Quality of Service（SWQoS）の恩恵を受けます。

ステーク済みバリデータ

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

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

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

ツリーの上位にいるほど、ネットワークの他の部分が追いつくまでに対応できる時間が長くなります。 

グローバルな変動 

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

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

この地理的な分散は、最適化の機会を生み出します。単一の高ステークバリデータはローカルでは優れた性能を発揮しても、最適な場所に配置されていなければグローバルでは遅れる可能性があります。分散型shredネットワークを使い、さまざまなソースから可能な限り最速のshredを集約すれば、この問題を軽減できます。これにより、ばらつきを抑え、一貫した取り込み速度を実現できます。このようなシステムなら、グローバルな環境で最上位のステークを持つバリデータを一貫して上回ることも可能です。

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

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

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

Webhook

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

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

標準WebSockets

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

ただし、Webhookと同様に、WebSocketsはshredの再構成後（つまり、processed、confirmed、またはfinalizedのコミットメントレベル）にデータを配信するため、コミットメントレベルに応じて400msから30秒のレイテンシが加わります。 

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

Enhanced WebSockets

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

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

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

Yellowstone gRPC

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

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

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

1. インフラ運用の負担

Yellowstone gRPCの能力を最大限に活用するには、独自の専用ノードが必要です。そのため、ハードウェアの確保、適切な設定、継続的な管理に加え、ハードウェア関連の問題をデバッグできる専門知識も求められます。

2. レイテンシの変動

Yellowstone gRPCがshredレベルでデータを配信できるからといって、常に最適な方法で配信されるとは限りません。レイテンシはプロバイダーに加え、専用ノードがshredに最適化されたソース（高ステークのバリデータなど）と接続されているかどうかによっても変動します。中程度から低ステークのバリデータと接続した場合、それらのバリデータはTurbineの第1階層へ常に配置されるわけではないため、多くのshredで引き続き下流に位置することになります。

3. 障害リスク

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

4. リソース要件

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

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

LaserStream

LaserStreamは、shredレベルで取り込む速度と、グローバルに分散したサービスの信頼性および到達範囲を両立します。複数の専用ノードを運用するコストや負担はありません。 

LaserStreamは、次の仕組みによってこれを実現します。

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

要するに、LaserStreamはYellowstone gRPCとWebSocketsを、スケーラブルかつ低レイテンシで耐障害性に優れた形へ進化させたものです。数百万規模のステークを保有したり、高性能インフラを自ら運用したりすることなく、ネットワーク上で発生したオンチェーンイベントを常に即座に提供します。 

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

クライアントと性能

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

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データへアクセスしてください。 

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

関連リソース

• LaserStream
• AgaveのShredモジュール
• SolanaのShred仕様