原題:「Turbine: Block Propagation on Solana」
原作者: ライアン・チャーン
オリジナルコンピレーション: Sharon、BlockBeats
著者について: この記事の著者である Ryan Chern は、Solana の元エンジニアリング インターンであり、Quantum Labs の共同創設者です。現在、暗号通貨研究センターであるブラックホークリサーチに勤務。
ノードが検証に必要なすべての情報に簡単にアクセスできるようにするため、ブロックチェーンにとってデータの可用性が重要であり、それによってネットワークの整合性とセキュリティが維持されます。ただし、高レベルのパフォーマンスを維持しながらデータの可用性を確保することは、特にネットワークが拡大するにつれて、大きな課題になります。
Solana は、ブロックの継続的な作成と伝達を容易にする独自のアーキテクチャ設計を通じてこの課題に対処します。これは、リーダーの選択、Gulf Stream (メモリプールの必要性を排除)、Turbine (ブロック伝播メカニズム) などのいくつかの重要な革新によって実現されています。
Solana の継続性には、すべてのバリデーターが最新のステータスをタイムリーに受信できるようにする効率的なシステムが必要です。簡単なアプローチは、リーダーにすべてのブロックを他のすべてのバリデーターに直接送信させることです。ただし、Solana の高いスループットを考慮すると、このアプローチでは帯域幅やその他のリソース要件が大幅に増加すると同時に、分散化が損なわれることになります。
帯域幅は希少なリソースです。Turbine は、特定のブロックのリーダーからネットワークの残りの部分への情報の伝播を最適化するための Solana の独創的なソリューションです。 Turbine は、リーダーからネットワークへの出力 (データ送信) の圧力を軽減するように特別に設計されています。
この記事では、Turbine の仕組みと、Solana の広範なトランザクション インクルージョン環境におけるその重要な役割について詳しく見ていきます。また、Turbine を他のデータ可用性ソリューションと比較し、この分野におけるオープンな研究の道についても説明します。
タービンとは何ですか?
Turbine は、Solana クラスターが元帳エントリをすべてのノードにブロードキャストするために使用する多層ブロック伝播メカニズムです。この 2004 年の論文や最近の研究で証明されているように、Turbine の背後にある中心的なアイデアは長年にわたって学術的な議論に存在していました。
すべてのノードに順次またはフラッディング方式で送信される従来のブロックチェーンとは異なり、Turbine はより構造化されたアプローチを採用して、通信オーバーヘッドを最小限に抑え、個々のノードの負荷を軽減します。高レベルでは、Turbine はチャンクをより小さなチャンクに分割し、これらのチャンクをノード階層全体に伝播します。ここで、単一のノードは他のすべてのノードと通信する必要はなく、選択された少数のノードとのみ通信します。
ネットワークのサイズが大きくなるにつれて、必要なトラフィック量が膨大になるため従来の伝播方法が持続不可能になるため、これはますます重要になります。その結果、Turbine は Solana 内でのデータの迅速かつ効率的な配布を保証します。ブロックの伝播と検証の速度は、Solana の高スループットとネットワーク セキュリティを維持するために重要です。
さらに、Turbine はデータの可用性の問題を解決し、すべてのノードがトランザクションを効果的に検証するために必要なデータにアクセスできるようにします。これは、他のブロックチェーン ネットワークでよくあるボトルネックである大量の帯域幅を必要とせずに実行されます。
Turbine は、帯域幅のボトルネックを緩和し、高速なブロック伝播を保証することで、大量のトランザクションを処理し、無駄のない効率的なネットワーク構造を維持する Solana の能力を大幅に向上させます。この革新的なプロトコルは、Solana が約束する高速、安全、スケーラブルなネットワーキングの基礎の 1 つです。
ここで、Turbine の仕組みと、Turbine が Solana ネットワーク上でブロックを伝播する方法を詳しく見てみましょう。
Turbine はブロックをどのように伝播しますか?
ブロックを伝播する (つまり、ネットワーク内の他のバリデータに送信する) 前に、リーダーは受信トランザクション フローに基づいてブロックを構築し、順序付けします。ブロックが構築されると、Turbine 経由でネットワークの残りの部分に送信できます。このプロセスはブロック伝播と呼ばれます。 『
その後、投票メッセージがバリデーター間で受け渡され、これらのメッセージはブロック データにカプセル化されて、「確認済み」または「確定済み」のコミットメント ステータスを満たすようになります。確認済みブロックは台帳投票の過半数を受け取ったブロックであり、最終ブロックはターゲット ブロックの上に 31 個を超える確認済みブロックが構築された確認済みブロックです。コミットメントステータスの違いについては、ここで詳しく説明します。コンセンサスのこの部分については、今後の記事で説明します。
Solana トランザクション ライフ サイクルにおける Turbine の位置の視覚化
リーダーがブロック全体を構築して提案する一方で、実際のデータはシャード (部分ブロック) としてネットワーク内の他のバリデーターに送信されます。シャードは、バリデーター間で送信されるアトミックな単位です。
高レベルでは、Turbine はシャードを取得して、事前に設定されたバリデーターのセットに送信し、その後、そのシャードを新しいバリデーターのセットに転送します。以下の図は、デブリの伝播の連続性をまとめたものです。
上図にあるように、「ブロック伝播」と呼ばれていますが、データはフラグメントレベルで伝播されます。
この例では、バリデータ 1 が指定されたスロット リーダーです。そのスロット中 (バリデーターは 4 つの連続スロットのリーダーとして指定されます)、バリデーター 1 はブロックを構築して提案します。バリデータ 1 はまず、シュレッディングと呼ばれるプロセスを通じてブロックをシャードと呼ばれるサブブロックに分割します。
シュレッディングでは、ブロック データが最大送信単位 (MTU) サイズのデータ フラグメント (より小さい単位に分割することなく、あるノードから次のノードに送信できる最大量のデータ) に分割され、リードソロモン消去によって生成されます。 対応するリカバリ フラグメント エンコーディング スキーム。このソリューションは、データの回復を容易にし、送信中のデータの整合性を保証します。これは、ネットワークのセキュリティと信頼性を維持するために重要です。
この分解と伝播のプロセスにより、ブロック データが Solana 全体に迅速かつ効率的に分散され、高いスループットとネットワーク セキュリティが維持されます。
イレージコーディング
タービン ツリーを通じてフラグメントを伝播する前に、フラグメントはまずリードソロモン消去符号化 (多項式ベースのエラー検出および訂正スキーム) を使用してエンコードされます。イレイジャーコーディングは、送信中に一部のデータが失われたり破損したりした場合でも、元のデータを復元できるデータ保護方式です。リードソロモン消失符号化は、特定のタイプの前方誤り訂正 (FEC) アルゴリズムです。
Turbine は基本的にダウンストリーム バリデータからの一連のパケット再送信に依存しているため、これらのバリデータは悪意のあるものになる可能性があります (ビザンチン ノードに対して誤ったデータを再生するか、不完全なデータを受信する (ネットワーク パケット損失) ことを選択します。Turbine の再送信ツリー構造により、ネットワーク全体のあらゆるパケット損失はさらに複雑で、パケットが宛先に到達できない確率はホップごとに増加します。
高いレベルでは、リーダーがブロックのパケットの 33% を消去符号化して送信した場合、ネットワークはブロックを失うことなくパケットの 33% をドロップできます。リーダーは、最近観察されたネットワーク全体のパケット損失やツリーの深さなどの変数を考慮して、ネットワーク状況に基づいてこの数値 (FEC レート) を動的に調整できます。
簡単にするために、FEC 比が 4:4 の断片化グループを調べてみましょう。
断片化グループの例: 8 パケットのうち 4 パケットは、元のデータに影響を与えることなく改ざんまたは損失される可能性があります。
データ シャードはリーダーによって構築された元のブロックの部分的なチャンクであり、リカバリ シャードはリードソロモンによって生成された消去符号化されたチャンクです。
Solana のブロックは通常、32:32 の FEC を利用します (64 パケットのうち 32 パケットは再送信なしで失われる可能性があります)。 Solana のドキュメントに記載されているように、以下は保守的なネットワークの前提条件です。
・パケットロス率15%
· 50k TPS は 1 秒あたり 6400 シャードを生成します
FEC レートが 32:32 の場合、ブロック成功率は約 99% になります。さらに、リーダーは、ブロックが成功する確率を高めることを選択した場合、FEC レートを高める権限を持ちます。
Turbine は現在、ブロックの伝播に UDP を使用しており、レイテンシに大きなメリットをもたらします。バリデーターのオペレーターによると、6 MB 以上の消去符号化データを us-east-1 から eu-north-1 に転送するには、UDP を使用すると 100 ミリ秒かかるのに対し、TCP を使用すると 900 ミリ秒かかります。
タービンツリー
タービン ツリーは、バリデータ間でのシャード (コード化されたブロック データ) の効率的な伝達を容易にするために Solana によって使用される構造化されたネットワーク トポロジです。シャードがそれぞれのシャード グループに正しくエンコードされると、ターボ ツリーを通じてシャードを伝播し、ネットワーク内の他のバリデーターに最新の状態を通知できます。
各シャード グループは、ネットワーク パケットを介して特別なルート ノードに送信され、どのバリデータが最初の層 (1 ホップ離れたところ) の一部であるかを管理します。次に、次の手順を実行します。
1. リストの作成: ルート ノードは、すべてのアクティブなバリデーターをリストに集約し、ネットワーク内の各バリデーターのステークに応じて並べ替えます。より高いステークウェイトを持つバリデーターは、より高速なシャードに対して優先され、合意に達するために投票メッセージにより迅速に応答できるようになります。
2. リストのシャッフル: リストは決定的な方法でシャッフルされます。これにより、スロット リーダー ID、スロット、シャード インデックス、およびシャード タイプから派生したシードを使用して、各シャードのバリデータ ノードのセットから「タービン ツリー」が生成されます。静的ツリー構造に関連する潜在的なセキュリティ リスクを軽減するために、実行時にシャード グループごとに新しいツリーが生成されます。
3. レイヤーの形成: 次に、ノードはリストの先頭から順にレイヤーに分割されます。パーティション分割は、タービン ツリーの幅と深さを決定する DATA_PLANE_FANOUT 値に基づいて行われます。この値は、フラグメントがネットワークを介して伝播する速度に影響します。現在、DATA_PLANE_FANOUT は 6 です。
有名な Turbine ツリーにより、各バリデーターはそのシャードを中継する責任がある場所を正確に把握できます。現在の DATA_PLANE_FANOUT 値が 6 であると仮定すると、Turbine ツリーは通常 4 または 5 ホップ ツリーになります (アクティブなバリデータの数に応じて)。
さらに、ノードが十分な断片化を取得していない場合、または損失率が FEC レートを超えている場合、ノードはゴシップと修復にフォールバックすることができます。現在の実装では、ブロックを再構築するのに十分なフラグメントが不足しているノードは、リーダーに再送要求を送信します。決定論的タービンでは、完全なブロックを受信したノードは、要求元のノードが必要とする修復フラグメントを送信できるため、データ転送がツリーのさらに下流にある、データが要求された領域にプッシュされます。
Solana と Ethereum 間のブロック伝播の比較
Solana でのブロックの伝播はイーサリアムとは異なります。高レベルの違いをいくつか示します。
1. Solana の理想的な帯域幅要件 (>1 Gbps) はイーサリアムよりも大幅に高くなります (geth は >25 Mbps を推奨)。このより高い帯域幅要件は、Solana のブロック サイズが大きくなり、ブロック時間が高速になるためです。 Solana は、帯域幅全体を効率的に利用してデータ転送を高速化し、待ち時間を短縮するように設計されています。帯域幅のピークは 1 Gbps に達しますが、1 Gbps が常に使用されるわけではありません。 Solana のアーキテクチャは、帯域幅需要のピークに対処できるように設計されています。
2. Solana はブロック データの伝播に Turbine を使用しますが、Ethereum は標準のゴシップ プロトコルを使用します。イーサリアムでは、ブロック データの伝播は単純な方法で行われます。つまり、すべてのノードがネットワーク内の他のすべての完全なノードと通信します。新しいブロックが作成されると、クライアントはそれをピアに送信し、ブロック内のトランザクションを承認することでそれを検証します。このメカニズムは、Solana と比較してブロック サイズが小さく、ブロック時間が長いため、イーサリアムに適しています。イーサリアム L2 集約データ (validium を除く) に関しては、伝播もゴシップ プロトコルに従い、ブロック データはイーサリアム L1 ブロックの「calldata」フィールドに保存されます。
3. Ethereum はブロック伝播に TCP (DevP2P プロトコル経由) を使用しますが、Solana は UDP (一部のコミュニティ サポートにより QUIC に移行) を使用します。 UDP と QUIC の間には考慮すべきトレードオフがいくつかあります。
· UDP の一方向性により、QUIC に比べて遅延が少なくなるため、QUIC ストリームが必要になります。 QUIC への一方向フローの実装についての議論が進行中です。
· QUIC の支持者は、カスタム制御フローは UDP 上で実行できるものの、それには多大なエンジニアリングの労力が必要ですが、QUIC はそのような機能をネイティブにサポートすることでその労力を軽減すると主張しています。最終目標は同じですが、QUIC パフォーマンス (レイテンシ、スループットなど) の上限は純粋な UDP の現状です。
これらの違いは、Solana と Ethereum がそれぞれのパフォーマンス、スケーラビリティ、ネットワークの堅牢性を向上させるのに役立つ独自のアーキテクチャ上の決定を強調しています。 TCP、UDP、QUIC のより詳細な分析については、Solana と QUIC に関する記事をご覧ください。
将来の研究課題
ブロックの伝播とデータの可用性は依然として未解決の研究分野であり、多くのチームが独自のアプローチを開発しています。指標は進化し続ける可能性がありますが、さまざまなアプローチとそれに関連するトレードオフの概要を示したいと思います。
1. 「データ可用性」(DA) メカニズムとしての Turbine について、いくつかの議論が浮上しています。 Turbine はデータ可用性メカニズムとして機能し、ブロック データ全体が Solana 上の他のすべてのバリデーターによって公開およびダウンロードされます。それでも、Turbine は、ハードウェア要件を軽減してライト ノードが状態を検証するのに役立つ機能であるデータ アベイラビリティ サンプリング (DAS) をサポートしていません。これは Celestia のようなチームにとって積極的な開発の焦点です。 Turbine と同様に、DAS は消去コーディングを使用しますが、これはデータ隠蔽攻撃の検出と防止という明確な目的があります。
2. Tubrine は、Solana Virtual Machine (SVM) L2 (Eclipse など) との関連性を失いました。これは、それらの間でデータを渡すためのバリデーターが設定されていなかったためです。 Eclipse の場合、ブロック データはデータの可用性を確保するために Celestia に公開されます。これにより、外部の監視者が不正行為の証明を実行して、正しい実行と状態遷移を保証できるようになります。 Eclipse は、Solana ネットワーク自体の外での SVM の最初の実装の 1 つになります。 Pyth はまた、独自のオラクル ネットワーク「Pythnet」用に SVM をフォークし、事実上独自のサイドチェーンとして実行しました。
3. Solana では、フルノードがブロックの伝播を管理すると同時に、トランザクションの順序付けやコンセンサスなど、ブロックチェーン スタックの他の部分の統合にも参加します。 Turbine が専用ハードウェア上のモジュラー コンポーネントとして実行される場合、その定量的な指標は何ですか?
4. タービンは、ブロック データを最初に受信するために、より高い重みを持つノードを優先します。これにより、時間の経過とともに MEV の一元化がさらに進むのでしょうか?
5. 生のスループットと信頼の最小化の点で、EigenDA (水平方向にスケーラブルな単一ユニキャスト リレー) や Celestia (データ可用性サンプリング) などのさまざまなデータ可用性アプローチは、本番環境の Turbine とどのように比較されますか?
6. Firedancer は、データ拡散をさらに拡大するように設計されており、強力な 10 Gbps 帯域幅接続用に最適化されています。 Turbine を中心としたシステム レベルの最適化は、消費者向けおよびプロフェッショナル グレードのハードウェアの実稼働環境でどのように機能しますか?
7. 現在、Solana 上のすべてのノードはフル ノードです (ライト クライアントの実装はまだ開発中です)。 Sreeram Kannan (EigenLayer) は最近、Turbine の上に DAS-S を実装することについて説明しました。 Turbine 用の DAS のバージョンはサポートされますか? DAS を使用してライト クライアントを実装して、データ スループットを高く維持しながら、ライト クライアント (リソース要件が大幅に低い) で信頼の最小化を実現することは可能ですか?
結論は
おめでとう！この記事では、Turbine と、Solana の広範なトランザクション インクルージョン スペース内で Turbine がどのように機能するかについて説明します。 Turbine を他のデータ可用性ソリューションと比較し、この分野に開かれたさまざまな研究手段について説明します。 Solana の Turbine プロトコルは、構造化されたネットワーク トポロジを活用してバリデータ間でブロック データを効率的に伝播することで、高スループットと低遅延を実現するというネットワークの取り組みを示しています。
データの可用性を強化し、ブロック伝播の効率を高める方法を見つけることで、より広範なブロックチェーン コミュニティ内でイノベーションを推進できます。 Solana と Ethereum のブロック伝播メカニズムの比較分析により、それぞれの利点とトレードオフが明らかになり、EigenDA、Celestia、Firedancer などの新興ブロックチェーン ソリューションが将来このエコシステムをどのように形成するかについてのさらなる研究が促進されます。
効率的なデータの配布とデータの可用性のためのソリューションは完全には程遠いです。しかし、セキュリティを犠牲にしたり信頼を最小限に抑えたりすることなくネットワーク パフォーマンスを最適化するという Solana のアプローチと強力な取り組みは温かく歓迎されました。
元のリンク