見出し画像

Turbine:Solanaでのブロック伝搬

camao

原題：https://www.helius.dev/blog/turbine-block-propagation-on-solana

Solanaのブロック伝搬について、イーサリアムとの比較について学び、ブロック伝搬とデータの可用性に関する今後の研究の可能性を探る。

執筆者

ライアン・チャーン

公開日

2023年10月26日

この記事について

データの可用性はブロックチェーンにとって極めて重要である。検証のために必要なすべての情報にノードが容易にアクセスできるようにすることで、ネットワークの完全性とセキュリティを維持することができる。しかし、高水準のパフォーマンスを維持しながらデータの可用性を確保することは、特にネットワークの規模が拡大するにつれて、大きな課題となっている。

Solanaは、継続的なブロックの作成と伝搬を容易にする独自のアーキテクチャ設計によって、この課題に立ち向かった。これは、リーダー選択、ガルフストリーム（メンプールの必要性を排除）、タービン（ブロック伝搬メカニズム）といったいくつかの重要な革新技術によって実現されている。

Solanaの継続的な性質上、すべてのバリデータが最新の状態を迅速に受信できるような、効率的なシステムが必要となる。単純化したアプローチでは、リーダーがすべてのブロックを他のすべてのバリデータに直接送信することになる。しかし、Solanaのスループットが高いことを考えると、この方法では帯域幅やその他のリソース要件が著しく肥大化し、分散化が損なわれてしまう。

帯域幅は希少なリソースであり、Turbineは、指定されたブロックのリーダーから残りのネットワークへの情報伝播を最適化するSolanaの独創的なソリューションです。Turbineは、リーダーからネットワークへのイグレス（データ送信）のストレスを軽減するために特別に設計された。

本稿では、Turbineの仕組みと、Solanaのトランザクション・インクルージョンにおける重要な役割について解説する。また、Turbineと他のデータ・アベイラビリティ・ソリューションとの比較や、この分野における研究の可能性についても考察する。

タービンとは？

Turbineは、Solanaクラスタが台帳エントリを全ノードにブロードキャストするために使用する、マルチレイヤーのブロック伝搬メカニズムである。Turbineの中核となるアイデアは、2004年に発表されたこの論文や、最近の研究でも明らかなように、長年にわたって研究者の頭の中にあった。

ブロックがすべてのノードに順次送信されたり、フラッディング方式で送信されたりする従来のブロックチェーンとは異なり、Turbineは通信のオーバーヘッドを最小限に抑え、個々のノードの負荷を軽減するため、より構造化されたアプローチを採用しています。Turbineは、ブロックを小さな断片に分解し、その断片をノードの階層構造を通じて配信します。個々のノードは、他のすべてのノードと通信する必要はなく、一部のノードと通信すればよい。これは、ネットワークの規模が大きくなるにつれて、必要な通信量が膨大になり、従来の伝搬方法では対応できなくなるため、ますます重要になってくる。このように、Turbineは、Solana全体への高速かつ効率的なデータ伝送を保証する。ブロックの伝搬と検証の速度は、Solanaの高いスループットとネットワークセキュリティを維持する上で極めて重要である。

さらに、Turbineはデータの可用性の問題に対処しており、すべてのノードが効率的な方法でトランザクションを検証するために必要なデータにアクセスできるようにしている。これは、他のブロックチェーン・ネットワークで一般的なボトルネックとなっている膨大な帯域幅を必要とすることなく実現されている。

Turbineは、帯域幅のボトルネックを緩和し、迅速なブロック伝搬を確保することにより、大量のトランザクションを処理し、無駄のない効率的なネットワーク構造を維持するSolanaの能力に大きく貢献しています。この革新的なプロトコルは、Solanaが高速で安全かつスケーラブルなネットワークとしての約束を果たすことを可能にする礎石の1つです。

では、Turbineの仕組みと、ソラーナネットワーク全体にブロックを伝播させる仕組みについて、さらに掘り下げてみよう。

タービンはどのようにブロックを推進するのか？

ブロックが伝搬（ネットワーク内の他のバリデータに送信）される前に、リーダーは受信するトランザク ションのストリームからブロックを構築し、発注する。ブロックが構築されると、そのブロックはTurbineを経由して他のネットワークに送信される。このプロセスをブロックプロパゲーションと呼ぶ。投票メッセージはバリデータ間でやり取りされ、これらのメッセージはブロックデータ内にカプセル化され、コミットメントステータスの「confirmed」または「finalized」を満たす。確定ブロックとは、台帳の投票で超多数を獲得したブロックのことで、確定ブロックとは、確定され、ターゲットブロックの上に31以上の確定ブロックが構築されたブロックのことです。コミットメントステータスの違いについては、こちらで詳しく説明している。コンセンサスのこの部分については、今後の投稿で検討する予定である。


SolanaトランザクションのライフサイクルにおけるTurbineの位置づけの可視化

リーダーはブロック全体を構築して提案するが、実際のデータは細片（部分ブロック）としてネットワーク内の他のバリデータに送信される。細片はバリデータ間で送信される原子単位である。
Turbineはシュレッダーを受け取り、あらかじめ決められたバリデーターに送り、バリデーターはそのシュレッダーを新しいバリデーターにリレーする。以下の図は、細片の連続的な伝播プロセスの概要を示している：


ブロック伝搬」と呼ばれるが、データは上図のように細片レベルで伝搬される。

この例では、バリデータ 1 が指定されたスロットリーダである。そのスロットの間(バリデータは連続する4スロットのリーダーを割り当てられる)、 バリデータ1はブロックを構築し、提案する。バリデータ1はまず、シュレッディングと呼ばれる処理によって、ブロックをシュレッドと呼ばれるサブブロックに分割する。シュレッディングはブロック・データをMTU（Maximum Transmission Units）サイズのデータ・シュレッド（あるノードから次のノードへ、より小さなユニットに断片化することなく送信できるデータの最大量）に分割し、リード・ソロモン消去符号化方式によって対応するリカバリ・シュレッドを生成する。この方式はデータ復元を助け、ネットワークのセキュリティと信頼性を維持するために重要な伝送中のデータの完全性を保証する。

この細断と伝播のプロセスにより、Solana全体のブロックデータの迅速かつ効率的な配布が保証され、高いスループットとネットワークセキュリティが維持される。

消去符号化

細片がタービン・ツリーを通して伝搬される前に、まず多項式ベースのエラー検出・訂正方式であるリード・ソロモン消去符号化を用いて符号化される。消去符号化は、伝送中に一部が失われたり破損したりしても、元のデータを復元できるようにするためのデータ保護方法として使用される。リード・ソロモン消去符号化は、前方誤り訂正（FEC）アルゴリズムの特定のタイプである。

Turbineは、基本的に下流の検証者による一連のパケット再送信に依存しているため、それらの検証者が悪意のあるノード（敵対的なビザンチンノード）である可能性があり、不正なデータの再送信を選択したり、不完全なデータ（ネットワークパケット損失）を受信したりする可能性がある。Turbineの再送ツリー構造により、ネットワーク全体のパケットロスは複合的に発生し、パケットが宛先に到達しない確率はホップごとに増加する。

高いレベルでは、リーダーがブロックの33%のパケットを消去コードとして送信する場合、ネットワークはブロックを失うことなく33%のパケットをドロップすることができる。リーダーには、最近観測されたネットワーク全体のパケットロスやツリーの深さなどの変数を考慮することで、ネットワークの状況に応じてこの数値（FECレート）を動的に調整する能力があります。

簡単のため、FECレートが4:4の細断グループを検証してみよう。


細断グループの例。8つのパケットのうち4つは、元のデータに影響を与えることなく、改ざんまたは紛失される可能性がある。

データ・シュレッドは、リーダーによって構築されたオリジナル・ブロックの部分ブロックであり、一方、リカバリ・シュレッドは、リード・ソロモンによって生成された消去符号化ブロックである。
Solanaのブロックは通常、32:32のFECを利用している（64パケットのうち32パケットは再送信の必要なく失われる可能性がある）。Solanaのドキュメントに記載されているように、これは以下の保守的なネットワークの仮定です：

  • パケットロス率15

  • 毎秒6400枚のシュレッダーを生成する50k TPS

FEC率を32：32にすると、ブロック成功率は99％になる。さらに、リーダーは、ブロック成功の確率を上げるためにFECレートを上げることができる。
Turbineは現在、ブロック伝搬にUDPを利用しており、レイテンシに大きなメリットをもたらしている。あるバリデーター・オペレーターによると、us-east-1からeu-north-1へ6MB＋消去符号化相当のデータを送信するのに、TCPでは900msかかるのに対し、UDPでは100msで済むという。

タービンの木

タービンツリーとは、バリデータ間で細片(エンコードされたブロックデータ)を効率的に伝達 するためにSolanaが使用する、構造化されたネットワークトポロジーである。細片がそれぞれの細片グループに適切にエンコードされると、ネットワーク内の他のバリデ ータに最新の状態を通知するために、細片はタービンツリーを通じて拡散される。

各シュレッダーグループは、どのバリデーターが第1レイヤー（1ホップ先）に属するかを管理する特別なルートノードに、ネットワークパケットを介して送信される。その後、以下のステップが実行される：

  1. リストの作成：ルートノードはすべてのアクティブなバリデータをリストに集約し、各バリデータがネットワーク内で持つステークに基づいてソートする。ステークウェイトの高いバリデータは、より早く細片を受け取ることができるように優先され、より早くコンセンサスのために自身の投票メッセージで応答できるようになる。

  2. リストのシャッフル：このリストは決定論的な方法でシャッフルされる。これは、スロットリーダID、スロット、細片インデックス、細片タイプに由来するシードを使用して、各細片のバリデータノードのセットから生成される「タービンツリー」を作成する。新しいツリーは、静的なツリー構造に関連する潜在的なセキュリティリスクを軽減するために、細片グループごとに実行時に生成される。

  3. レイヤーの形成：ノードはリストの先頭からレイヤーに分割される。この分割はDATA_PLANE_FANOUT値に基づいて行われ、タービ ンツリーの幅と深さを決定する。この値は、細片がネットワークを通じて伝播される速度に影響する。現在のDATA_PLANE_FANOUTは200なので、ほとんどのバリデータは2-3ホップしか離れていない(リーダー -> ルート -> L1 -> L2)。

Turbineツリーは、すべてのバリデータが知っているため、各バリデータは、そのシュレッダーの中継を担当する場所を正確に知ることができる。現在のDATA_PLANE_FANOUTの値が200の場合、タービンツリーは通常2ホップか3ホップのツリーである(アクティブなバリデータの数によって異なる)。
さらに、ノードは十分な細片を得られなかったり、損失率がFEC率を超えたりした場合、ゴシップや修復にフォールバックすることができる。現在の実装では、ブロックを再構築するのに十分な細片がないノードは、リーダーに再送要求を送る。決定論的タービンの下では、完全なブロックを受信したノードは、要求ノードが必要とする修復細片を送信することができるため、データを要求しているツリーの領域までデータ伝送を押し下げることができる。

Solanaとイーサリアムのブロック伝播の比較

Solana上のブロック伝搬はイーサリアムとは異なる。以下はハイレベルな違いである：

  • Solanaの理想的な帯域幅要件（>1 Gbps）は、イーサリアムの要件（gethは>25 Mbpsを推奨）よりも大幅に高い。この高い帯域幅要件は、Solanaの大きなブロックサイズと迅速なブロック時間に起因する。Solanaの設計では、データ伝送を迅速化するために帯域幅全体を効果的に利用できるため、待ち時間が短縮される。最大1Gbpsの帯域幅スパイクはあるが、一貫して1Gbpsを使用しているわけではない。Solanaのアーキテクチャは、特に帯域幅需要のスパイクを可能にする。

  • Solanaはブロックデータの伝播にTurbineを採用しているのに対し、Ethereumは標準的なゴシッププロトコルを利用している。イーサリアムでは、ブロックデータの伝播は単純な方法で行われる。各ノードは、ネットワーク内の他のすべてのフルノードと通信する。新しいブロックができると、クライアントはそれをピアに送信して検証し、ブロック内のトランザクションを承認する。この仕組みは、Solanaと比較してブロックサイズが小さく、ブロック時間が長いため、イーサリアムに適している。イーサリアムのL2ロールアップデータ（バリウムを除く）に関しては、伝播は同様にゴシッププロトコルに従い、ブロックデータはイーサリアムL1ブロックの「calldata」フィールドに格納される。

  • イーサリアムはブロックの伝播に（DevP2Pプロトコルを介して）TCPを使用し、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)をサポートしていない。DASは、ハードウェア要件を低減して状態の検証を行うライトノードを支援する機能である。これは、Celestiaのようなチームが積極的に開発を進めている機能である。Turbineと同様に、DASも消去コードを利用しますが、これはデータ保留攻撃を検出・防止するという明確な目的を持っています。

  • EclipseのようなSolana Virtual Machine (SVM)L2の場合、データ受け渡しのためのバリデータがないため、Turbineは意味を失う。Eclipseの場合、ブロックデータはCelestiaにパブリッシュされ、データの可用性を確保する。これにより、外部のオブザーバーが不正プルーフを実行し、正しい実行と状態遷移を確認することができる。Eclipseは、Solanaネットワーク以外でのSVMの最初の実装のひとつとなる。Pythはまた、"Pythnet "と呼ばれる独自のオラクルネットワーク用にSVMをフォークしており、事実上独自のサイドチェーンとして稼働している。

  • Solanaでは、フルノードがブロック伝搬を管理すると同時に、トランザクションの順序付けやコンセンサスなど、統合ブロックチェーンスタックの他のセグメントにも関与します。Turbineをモジュール式コンポーネントとして専用のハードウェアで運用する場合、定量的な指標はどのようになりますか？

  • Turbineは、ステークウェイトの高いノードから優先的にブロックデータを受信する。これは、時間の経過とともにMEVの集中化につながるのでしょうか？

  • EigenDA（水平スケーラブルな単一ユニキャストリレーヤー）やCelestia（データ可用性サンプリング）といったデータ可用性に対するさまざまなアプローチは、生のスループットと信頼最小化に関して、本番のTurbineとどのように比較されるのでしょうか？

  • Firedancerは、データの伝搬をさらに高めることを目指しており、堅牢な10Gbpsの帯域幅接続に最適化されている。Turbineを中心としたシステムレベルの最適化は、コンシューマーグレードのハードウェアだけでなく、プロフェッショナルグレードのハードウェアでも本番でどのように機能するのだろうか？

  • 現在、Solana上のすべてのノードはフルノードである（ライトクライアントの実装はまだ開発中）。Sreeram Kannan氏（EigenLayer）は最近、Turbine上でのDAS-Sの実装について説明しました。DASのTurbine向けバージョンのサポートはあるのでしょうか？DASを搭載したライトクライアントを実装することで、高いデータスループットを維持しつつ、ライトクライアント（必要なリソースがはるかに少ない）はトラストの最小化を満たすことができますか？

結論

おめでとう！本稿では、Turbineと、それがSolanaのトランザクション・インクルージョンという広い視野の中でどのように機能するかを検討した。また、Turbineを他のデータ可用性ソリューションと比較し、この領域に開かれているさまざまな研究の道筋について議論した。SolanaのTurbineプロトコルは、構造化されたネットワークトポロジーを活用し、バリデータ間でブロックデータを効率的に拡散することで、高スループットと低レイテンシーを実現するというネットワークのコミットメントを証明するものです。

データの可用性を高め、ブロック伝搬をより効率的にする方法を見つけることは、より広範なブロックチェーンコミュニティにおけるイノベーションを促進します。SolanaとEthereumのブロック伝播メカニズムの比較分析は、それぞれの長所とトレードオフに光を当てるとともに、EigenDA、Celestia、Firedancerなどの新たなブロックチェーン・ソリューションが将来的にこのエコシステムをどのように形成するかについて、より深い対話を促します。

効率的なデータ伝播とデータの可用性に対するソリューションは、完成には程遠い。しかし、セキュリティと信頼の最小化に妥協することなく、ネットワーク・パフォーマンスを最適化するというSolanaのアプローチと揺るぎないコミットメントは、暖かく歓迎されている。

レビューとコメントを寄せてくれた@dubbel06と @jon_charbに感謝する。

その他のリソース／参考文献


この記事が気に入ったらサポートをしてみませんか？