Turbine：Solanaにおけるブロック伝播
この記事で扱う内容
データ可用性はブロックチェーンに不可欠です。検証に必要なすべての情報へノードが容易にアクセスできるようにし、ネットワークの完全性とセキュリティを維持します。しかし、高いパフォーマンスを保ちながらデータ可用性を確保することは、特にネットワークの規模が拡大するにつれて大きな課題となります。
Solanaは、継続的なブロックの作成と伝播を可能にする独自のアーキテクチャ設計で、この課題に対応しています。これは、リーダー選出、Gulf Stream（mempoolを不要にする仕組み）、Turbine（ブロック伝播メカニズム）など、複数の重要なイノベーションによって実現されています。
Solanaは継続的に動作するため、すべてのバリデータが最新の状態を迅速に受信できる効率的なシステムが必要です。単純な方法としては、リーダーがすべてのブロックを他の各バリデータへ直接送信することが考えられます。しかし、Solanaはスループットが高いため、この方法では帯域幅などのリソース要件が大幅に膨らみ、分散化も損なわれます。
帯域幅は限られたリソースです。Turbineは、特定のブロックのリーダーからネットワークのほかの部分への情報伝播を最適化する、Solanaの優れたソリューションです。Turbineは、リーダーからネットワークへのエグレス（データの外部送信）の負荷を軽減するために設計されています。
この記事では、Turbineの仕組みと、Solanaにおけるトランザクション取り込みの全体像でTurbineが果たす重要な役割を詳しく解説します。また、Turbineをほかのデータ可用性ソリューションと比較し、この分野で今後研究すべき課題についても説明します。
Turbineとは
Turbineは、Solanaクラスターが台帳エントリをすべてのノードへブロードキャストするために使用する、多層型のブロック伝播メカニズムです。Turbineの中核となるアイデアは、2004年に発表された論文や、より最近の研究からも分かるように、長年にわたり研究者によって検討されてきました。
ブロックをすべてのノードへ順番に送信したり、フラッディング方式で送信したりする従来のブロックチェーンとは異なり、Turbineはより構造化されたアプローチを採用し、通信オーバーヘッドを最小限に抑えて個々のノードの負荷を軽減します。大まかに言えば、Turbineはブロックを小さな断片に分割し、階層化されたノードを通じてそれらを配布します。個々のノードはほかのすべてのノードと接続する必要がなく、選ばれた少数のノードとのみ通信します。ネットワークの規模が拡大すると、必要な通信量が膨大になり、従来の伝播方式では維持できなくなるため、この特性はますます重要になります。このように、TurbineはSolana全体でデータを高速かつ効率的に配布します。ブロックの伝播と検証の速度は、Solanaの高いスループットとネットワークセキュリティを維持するうえで極めて重要です。
さらにTurbineはデータ可用性の問題にも対応し、すべてのノードがトランザクションの検証に必要なデータへ効率的にアクセスできるようにします。ほかのブロックチェーンネットワークで一般的なボトルネックとなる、膨大な帯域幅を必要とせずに実現します。
Turbineは、帯域幅のボトルネックを緩和してブロックを迅速に伝播することで、Solanaが大量のトランザクションを処理し、無駄のない効率的なネットワーク構造を維持する能力に大きく貢献しています。この革新的なプロトコルは、高速、安全、かつスケーラブルなネットワークというSolanaの約束を実現する基盤の一つです。
ここからは、Turbineの仕組みと、Solanaネットワーク全体にブロックを伝播する方法を詳しく見ていきます。
Turbineはどのようにブロックを伝播するのか
ブロックが伝播される（つまり、ネットワーク内のほかのバリデータへ送信される）前に、リーダーは受信するトランザクションストリームを基にブロックを構築し、順序付けします。ブロックの構築が完了すると、Turbineを介してネットワークのほかの部分へ送信できる状態になります。このプロセスをブロック伝播と呼びます。 その後、投票メッセージがバリデータ間で渡されます。これらのメッセージはブロックデータにカプセル化され、コミットメントステータスの「confirmed」または「finalized」を満たします。confirmedブロックとは、台帳投票の圧倒的多数を獲得したブロックです。一方、finalizedブロックとは、confirmedとなり、その対象ブロックの上に31個以上のconfirmedブロックが構築されたブロックです。コミットメントステータスの違いについては、こちらで詳しく説明しています。コンセンサスのこの部分については、今後の記事で解説します。
リーダーはブロック全体を構築して提案しますが、実際のデータはシュレッド（ブロックの一部）としてネットワーク内のほかのバリデータへ送信されます。シュレッドは、バリデータ間で送信される最小単位です。
大まかに言えば、Turbineはシュレッドをあらかじめ決められたバリデータ群に送信し、それらのバリデータが新たなバリデータ群へシュレッドを中継します。次の図は、継続的なシュレッド伝播のプロセスを示しています。
この例では、Validator 1が指定されたスロットリーダーです。自身のスロット中（バリデータは連続する4スロットのリーダーに割り当てられます）、Validator 1はブロックを構築して提案します。Validator 1はまず、shreddingと呼ばれるプロセスを通じて、ブロックをシュレッドと呼ばれるサブブロックに分割します。Shreddingでは、ブロックデータをMaximum Transmission Unit（MTU）サイズのデータシュレッド（より小さな単位に断片化せず、あるノードから次のノードへ送信できるデータの最大量）に分割し、Reed-Solomon消失訂正符号方式を用いて対応するリカバリーシュレッドを生成します。この方式はデータ復旧を支援し、送信中のデータ整合性を確保します。これは、ネットワークのセキュリティと信頼性を維持するうえで極めて重要です。
このshreddingと伝播のプロセスにより、Solana全体へブロックデータを迅速かつ効率的に配布し、高いスループットとネットワークセキュリティを維持できます。
消失訂正符号
シュレッドはTurbine Treeを通じて伝播される前に、まず多項式ベースの誤り検出・訂正方式であるReed-Solomon消失訂正符号を使ってエンコードされます。消失訂正符号は、送信中に一部が失われたり破損したりしても元のデータを復元できるようにするデータ保護手法です。Reed-Solomon消失訂正符号は、前方誤り訂正（FEC）アルゴリズムの一種です。
Turbineは基本的に、下流のバリデータによる一連のパケット再送に依存しています。そのため、それらのバリデータが不正なデータの再ブロードキャストを選ぶ悪意のあるノード（敵対的なビザンチンノード）であったり、不完全なデータを受信したりする可能性があります（ネットワークパケットロス）。Turbineの再送ツリー構造では、ネットワーク全体のパケットロスが累積し、ホップを重ねるたびにパケットが宛先へ到達できない確率が高まります。
大まかに言えば、リーダーがブロックのパケットの33%を消失訂正符号として送信すれば、ネットワークではブロックを失うことなく、任意の33%のパケットを欠落させることができます。リーダーは、直近に観測されたネットワーク全体のパケットロスやツリーの深さなどの変数を考慮し、ネットワーク状況に応じてこの値（FECレート）を動的に調整できます。
分かりやすくするため、FECレートが4:4のシュレッドグループを見てみましょう。
データシュレッドはリーダーが構築した元のブロックの一部であり、リカバリーシュレッドはReed-Solomonによって生成された消失訂正符号化ブロックです。
Solanaのブロックは、通常32:32のFECを使用します（64個のパケットのうち32個が欠落しても、再送は不要です）。Solanaのドキュメントに記載されている、保守的なネットワーク前提は次のとおりです。
- パケットロス率15%
- 50k TPSで毎秒6400個のシュレッドを生成
FECレートが32:32の場合、ブロックの成功率は~99%になります。さらにリーダーは、ブロックの成功確率を高めるため、必要に応じてFECレートを引き上げることができます。
現在、Turbineはブロック伝播にUDPを使用しており、レイテンシを大幅に短縮しています。あるバリデータ運用者によると、UDPを使用してus-east-1からeu-north-1へ6 MBと消失訂正符号分のデータを送信する場合は100msかかるのに対し、TCPでは900msかかります。
Turbine Tree
Turbine Treeは、バリデータ間でシュレッド（エンコードされたブロックデータ）を効率的に伝播するためにSolanaが使用する、構造化されたネットワークトポロジーです。シュレッドがそれぞれのシュレッドグループへ正しくエンコードされると、Turbine Treeを通じて配布できる状態になり、ネットワーク内のほかのバリデータへ最新の状態を伝えます。
各シュレッドグループは、どのバリデータを第1レイヤー（1ホップ先）に含めるかを管理する特別なルートノードへ、ネットワークパケットとして送信されます。その後、次の手順が実行されます。
- リストの作成： ルートノードは、すべてのアクティブなバリデータを一つのリストにまとめ、各バリデータがネットワークで保有するステークに基づいて並べ替えます。ステークウェイトの高いバリデータが優先的にシュレッドを受信するため、コンセンサスに必要な自身の投票メッセージをより早く返せます。
- リストのシャッフル： 次に、このリストを決定論的にシャッフルします。これにより、各シュレッドについて、スロットリーダーID、スロット、シュレッドインデックス、シュレッドタイプから派生したシードを使用し、バリデータノードの集合から「Turbine Tree」が生成されます。静的なツリー構造に伴う潜在的なセキュリティリスクを軽減するため、シュレッドグループごとに実行時に新しいツリーが生成されます。
- レイヤーの形成： 次に、リストの先頭からノードをレイヤーに分割します。分割は
DATA_PLANE_FANOUTの値に基づき、この値によってTurbine Treeの幅と深さが決まります。この値は、ネットワーク全体でシュレッドを伝播できる速度に影響します。現在のDATA_PLANE_FANOUTは200です。そのため、ほとんどのバリデータは2～3ホップ先にあります（leader -> root -> L1 -> L2）。
Turbine Treeは全員に共有されているため、各バリデータは、そのシュレッドをどこへ中継する責任があるかを正確に把握できます。現在のDATA_PLANE_FANOUT値が200であることから、Turbine Treeは通常、2ホップまたは3ホップのツリーです（アクティブなバリデータ数によって異なります）。
さらにノードは、十分なシュレッドを取得できない場合や、損失率がFECレートを超えた場合、gossipとrepairにフォールバックできます。現在の実装では、ブロックの再構築に十分なシュレッドを持たないノードは、リーダーへ再送をリクエストします。決定論的Turbineでは、完全なブロックを受信した任意のノードが、リクエスト元のノードに必要なrepairシュレッドを送信できます。これにより、データを要求しているツリー内の領域へ、データ送信をさらに下流まで進められます。
SolanaとEthereumのブロック伝播を比較
Solanaのブロック伝播はEthereumとは異なります。主な違いは次のとおりです。
- Solanaの理想的な帯域幅要件（>1 Gbps）は、Ethereum（gethは>25 Mbpsを推奨）より大幅に高くなっています。この高い帯域幅要件は、Solanaのブロックサイズが大きく、ブロック時間が短いことに起因します。Solanaの設計では、帯域幅全体を効果的に活用してデータ送信を高速化し、レイテンシを短縮できます。帯域幅が最大1 Gbpsまで急増することはありますが、常に1 Gbpsを使用するわけではありません。Solanaのアーキテクチャは、帯域幅需要の急増に対応できるよう設計されています。
- Solanaがブロックデータの伝播にTurbineを使用するのに対し、Ethereumは標準的なgossipプロトコルを使用します。Ethereumでは、ブロックデータは単純な方法で伝播されます。各ノードがネットワーク内のほかのすべてのフルノードと通信します。新しいブロックが生成されると、クライアントはそれをピアへ送信し、ブロック内のトランザクションを承認することで検証します。EthereumはSolanaよりブロックサイズが小さく、ブロック時間が長いため、このメカニズムが適しています。Ethereum L2のロールアップデータ（validiumを除く）についても、伝播にはgossipプロトコルが使用され、ブロックデータはEthereum L1ブロックの「calldata」フィールドに保存されます。
- Ethereumはブロック伝播にTCP（DevP2Pプロトコル経由）を使用しますが、SolanaはUDPを使用します（QUICへの移行を支持するコミュニティの動きもあります）。UDPとQUICには、考慮すべきトレードオフがいくつかあります。
- UDPは単方向であるため、QUICストリームを必要とするQUICよりレイテンシが低くなります。QUICに単方向ストリームを実装することについて、現在も議論が続いています。
- QUICの支持者は、UDP上でも独自のフロー制御を実装できるものの、多大なエンジニアリング作業が必要であり、QUICはこうした機能をネイティブにサポートすることで、その負担を軽減すると主張しています。最終的な目標は同じですが、QUICのパフォーマンス（レイテンシ、スループットなど）の上限は、現在の純粋なUDPの水準です。
こうした違いは、SolanaとEthereumが採用する固有のアーキテクチャ上の判断を浮き彫りにしています。それぞれのパフォーマンス、スケーラビリティ、ネットワークの堅牢性は、これらの判断によって実現されています。TCP、UDP、QUICの詳細な分析については、SolanaとQUICの記事をご覧ください。
今後の研究課題
ブロック伝播とデータ可用性は、依然として未解決の研究分野であり、多数のチームがそれぞれ独自のアプローチを開発しています。指標は今後変化する可能性がありますが、ここでは各アプローチと、それに伴うトレードオフの概要を示します。
- Turbineが「データ可用性」（DA）メカニズムとしてどのような位置付けにあるかについて、いくつかの議論が起きています。Turbineではブロックデータ全体が公開され、Solana上のほかのすべてのバリデータによってダウンロードされるため、その意味ではデータ可用性メカニズムとして機能します。しかしTurbineは、ハードウェア要件を抑えながらライトノードによる状態検証を支援するデータ可用性サンプリング（DAS）をサポートしていません。これはCelestiaなどのチームが積極的に開発している分野です。Turbineと同様にDASも消失訂正符号を使用しますが、データ秘匿攻撃の検出と防止を明確な目的としています。
- Solana Virtual Machine（SVM）を使用するEclipseなどのL2では、データを受け渡すバリデータセットが存在しないため、Turbineの重要性は低下します。Eclipseでは、データ可用性を確保するためにブロックデータがCelestiaへ公開されます。これにより、外部の観測者は不正証明を実行し、正しい実行と状態遷移を確認できます。Eclipseは、Solanaネットワーク自体の外部におけるSVMの最初期の実装の一つとなります。Pythも「Pythnet」と呼ばれる独自のオラクルネットワーク向けにSVMをフォークしており、実質的に独自のサイドチェーンとして動作しています。
- Solanaでは、フルノードがブロック伝播を管理すると同時に、トランザクションの順序付けやコンセンサスなど、統合型ブロックチェーンスタックのほかの領域にも関与します。Turbineを専用ハードウェア上のモジュール型コンポーネントとして運用した場合、定量的な指標はどのようになるでしょうか。
- Turbineは、ステークウェイトの高いノードがブロックデータを先に受信できるよう優先します。これは時間の経過とともに、MEVのさらなる中央集権化につながるでしょうか。
- EigenDA（水平方向にスケーラブルな単一ユニキャストリレイヤー）やCelestia（データ可用性サンプリング）などのデータ可用性アプローチは、本番環境において、生のスループットと信頼最小化の面でTurbineと比べてどのような結果になるでしょうか。
- Firedancerはデータ伝播をさらに向上させることを目指し、堅牢な10 Gbpsの帯域幅接続に最適化されています。Turbineを中心に施されたシステムレベルの最適化は、一般消費者向けハードウェアとプロフェッショナル向けハードウェアの本番環境で、どのようなパフォーマンスを発揮するでしょうか。
- 現在、Solana上のすべてのノードはフルノードです（ライトクライアントの実装はまだ開発中です）。Sreeram Kannan（EigenLayer）は最近、Turbine上に構築するDAS-Sの実装について説明しました。Turbine向けのDASがサポートされることはあるでしょうか。DASを備えたライトクライアントを実装し、高いデータスループットを維持しながら、リソース要件がはるかに低いライトクライアントで信頼最小化を実現できるでしょうか。
まとめ
お疲れさまでした。この記事では、Turbineと、Solanaにおけるトランザクション取り込みの全体像の中でTurbineがどのように機能するかを解説しました。Turbineをほかのデータ可用性ソリューションと比較し、この分野で開かれているさまざまな研究の方向性についても説明しました。SolanaのTurbineプロトコルは、構造化されたネットワークトポロジーを活用してバリデータ間でブロックデータを効率的に配布し、高いスループットと低いレイテンシを実現しようとする、ネットワークの強い姿勢を示しています。
データ可用性を高め、ブロック伝播を効率化する方法の探求は、より広範なブロックチェーンコミュニティのイノベーションを推進します。SolanaとEthereumのブロック伝播メカニズムを比較分析することで、それぞれの強みとトレードオフが明らかになります。また、EigenDA、Celestia、Firedancerなどの新たなブロックチェーンソリューションが、今後このエコシステムをどのように形作るかについて、より深い議論を促します。
効率的なデータ伝播とデータ可用性を実現するソリューションは、まだ完成にはほど遠い段階です。しかし、セキュリティと信頼最小化を損なうことなくネットワークパフォーマンスを最適化しようとするSolanaのアプローチと揺るぎない姿勢は、大いに歓迎されます。
レビューとコメントを寄せてくださった@dubbel06と@jon_charbに感謝します。
追加リソース・参考資料
関連記事
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます