SolanaのGulf Stream：Mempoolが増えれば、問題も増える

実践的なポイント

• 「Gulf Stream」という用語は、ノードがネットワーク上でトランザクションを取得した時点から、現在のスロットのリーダーに到達し、TPU（Transaction Processing Unit）のFetch Stageで受信されるまでに行われるプロセス、と大まかに定義できます。
• Solanaは当初からMempoolなしで動作するよう設計されている点で際立っています。ゴシッププロトコルを使用してトランザクションをネットワーク全体に広く伝播する従来型のブロックチェーンとは異なり、Solanaはスロットごとに、リーダーと呼ばれる事前に決められた先行バリデータへすべてのトランザクションを転送します。リーダーは4スロットごとに交代し、リーダースケジュールはすべての稼働中のネットワークノードに事前に共有されるため、効率的にトランザクションを転送できます。
• Solanaのトランザクションには、デフォルトで直近のブロックハッシュを含める必要があります。開発者は簡単なAPI呼び出しで取得できます。直近のブロックハッシュは最大150スロット（約1分間）有効です。この期間を過ぎると古くなり、それを参照するトランザクションはネットワークによって破棄されます。これにより、未処理のトランザクションが残り続けることを防ぎます。直近のブロックハッシュは、トランザクションの重複排除にも役立ちます。開発者が永続的なnonceを追加する方法も用意されています。
• Gulf Streamでは、トランザクションがエンコードされ、QUICストリームを介してリーダーへ送信されます。2022年後半のQUIC導入は、従来のUDP接続を置き換える重要なネットワークアップグレードでした。この変更の主な目的は、ネットワークがスパムをフィルタリングする能力を高めることでした。しかし、Solanaでは2024年を通じて前例のない規模のアクティビティが発生し、QUICへの移行については議論が続いています。
• 2024年初頭に導入されたステーク加重Quality of Service（SWQoS）は、Gulf Streamを介してトランザクションがリーダーへ到達する仕組みに大きな変化をもたらしました。現在、リーダーはステークされた他のバリデータを経由するトランザクションメッセージを優先します。具体的には、リーダーの処理容量の80%（2,000接続）がステーク済みピア向けに予約され、残りの20%（500接続）がステークされていないノードからのトランザクションメッセージに割り当てられます。
• 現在、Solana上のステークの80%以上が、元のAgaveクライアントではなくJito-Solanaクライアントを実行するバリデータにロックされています。Jitoはプロトコル外のブロックスペースオークションを導入し、トランザクションがリーダーへ到達する仕組みをさらに複雑にしています。具体的には、Jitoリレイヤーが200ミリ秒の「スピードバンプ」を追加して受信トランザクションメッセージの流れを遅らせ、サーチャーがバンドルを送信するための十分な時間を確保します。

はじめに

「Gulf Stream」という用語は、Solanaの創設チームが2019年に執筆した一連の入門ブログ記事に由来します。これらの記事では、Solanaの革新的な仕組みの多くに航空をテーマとした名称が付けられました。記事内でGulf Streamは、Solanaの「Mempoolを持たないトランザクション転送プロトコル」と定義されています。しかし、現在のSolanaコードベースで「Gulf Stream」を検索しても、重要ではない言及が1件見つかるだけです。

Solanaのトランザクションライフサイクルという広い文脈では、「Gulf Stream」は、トランザクションがネットワークノード（通常はRPC）によって取得された時点から、現在のスロットのリーダーに到達するまで、つまりTPUの「Fetch Stage」で取得されるまでのプロセス全体と理解できます。また、Gulf StreamはSolanaのブロック伝播メカニズムであるTurbineを鏡写しにしたものとも捉えられます。Gulf Streamはトランザクションがリーダーへ到達する仕組みであり、Turbineは処理済みトランザクションがリーダーから離れていく仕組みだからです。

まず、SolanaにおけるRPC（Remote Procedure Call）ノードを定義しておくと分かりやすいでしょう。RPCノードは、ネットワークとのやり取りやデータの読み取りを行うためのゲートウェイと考えられます。ユーザーとSolanaのバリデータの間を仲介します。RPCはフルバリデータと同じソフトウェアを異なる設定で実行するため、トランザクションを正確にシミュレーションし、現在の状態（バンク）を最新に保てます。ただし、RPCノードにはステークがなく、コンセンサスには参加しません。ステークがないため、投票もブロックの構築もできません。この構成は、バリデータとRPCノードが通常は同一である他の多くのブロックチェーンとは異なります。Gulf StreamにおけるRPCの役割は、HTTP経由でトランザクションを受信し、トランザクションをQUICに変換し（詳しくは後述します）、リーダースケジュールを使用して現在のリーダーのアドレスとポート情報を検索し、現在および次のリーダーへトランザクションを転送すること、と要約できます。

ネットワークの開始以来、Gulf Streamには少なくとも2つの大規模なアップグレード、QUICとステーク加重QoSが導入されました。これらについては本記事で後ほど詳しく説明します。また、Solanaで前例のない量のネットワークトラフィックが発生したため、近年最も大きな負荷に直面してきたコアプロトコルの一部とも言えます。その規模を示すと、バリデータがリーダーになるとネットワーク全体からパケットが集中し、受信トラフィックが急増して毎秒1ギガバイトを超える場合があります。これほど大量のデータ流入を処理することは、非常に難しいエンジニアリング上の課題です。

Mempoolが増えれば、問題も増える

創設チームによるGulf Streamの当初の定義では、Mempoolが存在しないことが強調されています。Mempool（文字どおりには「メモリプール」）は、ユーザーが送信し、ネットワークによる処理を待っているトランザクションの集合と定義できます。これらのトランザクションは、公開状態で待機している間、通常は暗号化も秘匿化もされません。トランザクションはゴシッププロトコルを使用してネットワーク全体へ伝播されます。ネットワークによっては、署名済みトランザクションが実行条件を満たすまでMempoolに無期限で残る可能性があります。特に、トランザクション手数料（コンピュート単位当たりの価格）が通常の市場相場より大幅に低く設定されているトランザクションが該当します。極端なケースでは、ネットワークの状況がブロックへの取り込みに適していない場合、実行まで数日または数週間かかることがあります。

Solanaでは、このような状況は発生しません。ネイティブなMempoolの概念が存在しないだけでなく、すべてのトランザクションメッセージに直近のブロックハッシュを含める必要があるためです。開発者は、getLatestBlockhashメソッドへのJSON RPC API呼び出しを使用して、直近のブロックハッシュを簡単にリクエストできます。このブロックハッシュはトランザクションメッセージに埋め込まれ、最大150スロットにわたって有効です。各スロットの目標時間が400ミリ秒であることを考慮すると、約1分間です。150スロットが経過するとブロックハッシュは古くなり、それを参照するトランザクションはネットワークによって破棄されます。デフォルトでは、RPCは2秒ごとにトランザクションの転送を試みますが、直近のブロックハッシュが期限切れになるとトランザクションは破棄され、オンチェーンで実行されないことが保証されます。

直近のブロックハッシュは、重複したトランザクションを検出して削除する手段でもあります。他のネットワークでは、nonce（一度しか使用しない数値）を含めることを必須にすることで実現されます。特定の限定的なシナリオでSolanaのトランザクションに永続的なnonceを追加する方法も開発者向けに用意されていますが、標準的なSolanaトランザクションにnonceを含める必要はありません。

SolanaのGulf Streamシステムが成り立つのは、稼働中のすべてのノードがリーダースケジュールを常に事前に把握しているためです。スロット高がエポックの境界を越えるたびに、ノードはリーダースケジュールを更新します。これはおよそ2日ごとです。各エポックのリーダースケジュールは、前のエポック開始時点の台帳状態から計算されます。リーダースケジュールを生成するアルゴリズムのプロセスは次のとおりです。

• Proof of History（PoH）のティック高（単調増加するカウンター）を定期的に使用し、安定した疑似乱数アルゴリズムのシードとします。
• その高さで、リーダーIDを持ち、クラスターで設定されたティック数以内に投票したすべてのステーク済みアカウントをバンクからサンプリングします。このサンプルをアクティブセットと呼びます。
• アクティブセットをステークの重みで並べ替えます。
• ランダムシードを使用し、ステークで重み付けされたノードを選択して、ステーク加重の順序を作成します。
• この順序は、クラスターで設定されたティック数の経過後に有効になります。

出典：Solana公式ドキュメント

ステークによる重み付けにより、ステーク量が多い信頼されたノードほどリーダーに選ばれる確率と頻度が高くなり、ステーク量が少ないノードは選ばれる頻度が低くなるか、まったく選ばれなくなります。 

‍リソースのステーク加重配分は、投票報酬、Turbineツリー、リーダースケジュール、ゴシップネットワーク*など、Solanaのコアプロトコル全体に繰り返し登場するテーマです。本記事で後述するように、Gulf Streamもステーク加重を採用しています。

QUICに関する補足

Gulf Streamへの最初の大規模なアップデートは、リーダーへのトランザクションメッセージ送信を処理するため、2022年後半にQUICネットワークプロトコルを導入したことです。このアップグレードは、NFTミント時にチェーンへ殺到したDDoS攻撃やスパムトランザクションによるネットワーク障害を受けて実施されました。リリース1.13.4でQUICがMainnet-Betaに完全統合された後、ネットワークの安定性は向上しました。

以前、SolanaはRPCノードから現在のリーダーへトランザクションを送信するために、UDP（User Datagram Protocol）ネットワークプロトコルを使用していました。UDPは高速で効率的ですが、コネクションレスであり、フロー制御も受信確認もありません。そのため、不正利用を抑止または軽減する有効な方法がありませんでした。ネットワークトラフィックを制御するため、バリデータのトランザクション取り込みプロトコル（TPUのFetch Stage）はQUICで再実装されました。

QUICは2012年にGoogleによって最初に開発され、TCPとUDP双方の長所を提供することを目指しています。UDPのような高速で非同期の通信を実現しながら、TCPの安全なセッションと高度なフロー制御戦略も備えています。これにより、個々のトラフィック送信元に制限を設け、ネットワークが正当なトランザクションの処理に集中できるようになります。また、独立したストリームという概念もあり、1つのトランザクションが破棄されても残りのトランザクションをブロックしません。Web2全体でQUICの導入を主導してきたのはGoogleです。Googleサーバーへの接続にはQUICが使用されるため、Hangouts、Gmail、YouTubeなど、Google傘下の多くのアプリがQUICを基盤としています。なお、QUICは頭字語ではなく、プロトコルの正式名称です。 

とはいえ、SolanaにおけるQUIC実装の有効性については議論の余地があります。ネットワークトラフィックが急増すると、バリデータがQUICハンドシェイクに圧倒される場合があります。ネットワークレベルの輻輳問題を解決するために当初期待されたような決定打にはなっていないと言えるでしょう。また、Solanaの実装を除くと、ブロックチェーン業界におけるQUICの採用率は低いことにも注意が必要です。Solanaのバリデータコミュニティの一部は、QUICの導入は誤りだったと考え、このプロトコルを公然と批判しています。

ステーク加重Quality of Service（SWQoS）

2024年初頭、スパムを防止し、シビル耐性を高めるための仕組みとしてステーク加重Quality of Service（SWQoS）が導入されました。このシステムにより、リーダーはステーク済みバリデータを経由するトランザクションメッセージを優先できます。ステーク量が多いバリデータには、それに比例して、トランザクションメッセージパケットをリーダーへ送信するための大きな容量が与えられます。これにより、ネットワーク全体でステークのないノードやステーク量の少ないノードからのシビル攻撃を効果的に軽減できます。この分離が可能なのは、QUICを介してIPアドレスを検証できるためです。バリデータは特定の接続のトラフィックを優先し、制限できます。 

SWQoSでは、バリデータがステーク量に応じた容量をRPCノードへ貸し出せます。その見返りとしてRPCノードは帯域幅が拡大し、トランザクションがブロックに取り込まれる確率を高められます。特に、リーダーの処理容量の80%（2,000接続）がステーク加重QoS向けに予約され、残りの20%（500接続）が他のノードからのトランザクションメッセージに割り当てられます。この配分戦略は、渋滞を避けるためにドライバーが通行料金を支払う、高速道路の優先レーンのような仕組みです。

ステーク済みピアとして認められるために必要な最低ステーク量は、現在、総ステーク量の0.04%です。執筆時点の総ステーク量は3億8,400万SOLであり、最低要件は15,360 SOLとなります。‍

SWQoSは、リーダーへトランザクションを転送するための要件を引き上げ、スパム攻撃の有効性を低下させたことで、Solanaエコシステムに大きな影響を与えました。この変更により、トラフィック量の多いアプリケーションには、運用を垂直統合するインセンティブが生まれました。独自のバリデータノードを運用することで、アプリケーションはリーダーへの優先アクセスを確保し、トランザクション処理能力を高められます。Heliusは、ステーク量でネットワーク上位のバリデータの1つを運用しており、トランザクションが取り込まれる確率を高められることを誇りに思います。Heliusでのステーキングについては、詳しいステーキングガイドをこちらからご覧ください。

Jitoのスピードバンプ

執筆時点でネットワークのステークの80%以上がJitoバリデータクライアントを使用しており、トランザクションが通常リーダーへ到達する仕組みにさらなる複雑さを加えているため、本記事でJitoに触れないわけにはいきません。Jito-Solanaバリデータクライアント（Github）は、元はSolana LabsクライアントだったAgaveクライアント（Github）のフォークです。プロトコル外のブロックスペースオークションを導入し、バリデータがチップという形で追加の経済的インセンティブを受け取れるようにします。

Jitoクライアントの包括的な検証は本記事の範囲を超えるため、ここではJitoクライアントがGulf Streamを通る通常のトランザクションフローにどのような影響を与えるかに絞って分析します。トランザクションには2つの経路があります。RPCからペアリングされたバリデータを経由して現在のリーダーへ流れる経路（ステーク加重経路）と、リーダーへ直接転送される経路（オープン接続経路）です。どちらの場合も、リーダーがJito-Solanaクライアントを実行していれば、トランザクションは最初に、トランザクションのプロキシルーターとして機能するオープンソースソフトウェアのJito-Relayer（Github）へ送信されます。 

他のネットワークノードはJito-Relayerの存在を認識していません。リーダーがingress_socketとしてゴシップネットワーク上でブロードキャストするよう選択したアドレスとポート設定に、トランザクションを送信するだけです。リレイヤーは、トランザクションをリーダーへ転送する前に200ミリ秒遅延させます。この「スピードバンプ」の仕組みによって受信トランザクションメッセージの流れを遅らせ、効率的な離散時間オークションを可能にします。200ミリ秒後、リレイヤーはオークション結果にかかわらず、楽観的にトランザクションを解放します。

Jitoは以前、標準的なプロトコル外Mempoolサービスを運用していましたが、現在は廃止されています。Jito-Solanaバリデータがリーダーの場合、サーチャーは、アービトラージトランザクションや清算など、Mempoolに依存しない他の種類のMEVトランザクション向けに、バンドルと呼ばれるアトミックに実行されるトランザクショングループを引き続き送信できます。

詳しくは、Solana MEVの概要を説明したHeliusのブログ記事をこちらからご覧ください。

まとめ

本記事では、QUICネットワークプロトコル、ステーク加重QoS、Jitoバリデータの構成など、SolanaのGulf Streamに関するさまざまな側面を検証しました。Gulf Streamと従来型のMempoolアーキテクチャを比較し、効率の向上とレイテンシの短縮という観点からSolanaのアプローチの利点を説明しました。 

Gulf Streamが今後も進化し続けることは間違いありません。Solanaプロトコルとその広範なエコシステムは急速に進歩しており、大規模なアップグレードが見込まれています。一例として、Solana共同創設者のAnatoly Yakovenko氏は、複数の同時リーダーの実装を強く提唱しています。複数の同時リーダーにより、世界中の複数のノードがユーザーのトランザクションを同時に順序付けできるようになります。これによりレイテンシが短縮され、トランザクションがブロックチェーンへ追加される前に、最悪の場合で世界を完全に一周する通信が必要になる状況を解消できます。

Solanaが立ち止まることはありません。Gulf Streamを含むプロトコル全体に、刺激的な未来が待っています。そのため、開発者は今後も多くのアップデートと最適化が行われることを想定しておく必要があります。

ここまでお読みいただき、ありがとうございます！Discordでコミュニティに参加する、Xをフォローする、または以下のメーリングリストに登録することをご検討ください。‍

本記事の以前のバージョンをレビューしてくださったJacob Creech氏と0xIchigo氏に深く感謝します。‍

その他のリソース

• Gulf Stream：SolanaのMempoolを持たないトランザクション転送プロトコル
• QUIC：UDP上の多重化トランスポート
• HTTP/3とQUICの包括的なガイド
• SWQoSリンク集
• Solanaにおけるステーク加重Quality of Serviceのガイド
• Solanaバリデータ教育 — ステーク加重QoS
• Jito Relayerドキュメント
• 非同期実行とエンドゲームアーキテクチャ

‍