Solana Turbine: ブロック伝搬の解説

Solana Turbineのブロック伝搬とは、ブロックデータがシャード（shreds）に分割され、バリデーター全体に配布される仕組みを指します。この記事の図は、特に日付が指定されていない限り、過去のまたはターゲットの値であり、実際のスロットタイミング、トポロジー、パケットロス、および実装の動作は変動します。

はじめに：なぜブロック伝搬がブロックチェーンの速度を決定するのか

数千のバリデーターに一度に完全なブロックを送信することは、各バリデーターが単一のソースからブロック全体をダウンロードする必要があることを意味し、ネットワークがスケーリングするにつれて悪化する帯域幅のボトルネックを生み出します。Solana (SOL) は、高性能なレイヤー1ブロックチェーン（中央集権的な権威なしにトランザクションを記録・検証する分散型台帳ネットワーク）であり、専用のブロック伝搬プロトコルであるTurbineでこの問題を解決しています。

初期のSolanaの資料では、理論上のスループットが65,000 TPS近く、ターゲットのスロット時間が400ミリ秒近くであることが引用されています。これらは保証されたライブ測定値ではなく設計上の参照であり、スロットが常にブロックを生成するわけではありません。Turbineは、Solanaの過去のアーキテクチャフレームワーク内で説明されているブロックデータ伝搬メカニズムです。

ブロック伝搬はコンセンサスメカニズムの下に位置します。バリデーター（台帳のコピーを保持し、トランザクションを検証し、ブロックの有効性に投票するサーバー）は、シャードからブロックを受信して再構築するまで、その有効性に投票できません。この依存関係は、Turbineの速度がSolanaのコンセンサスパフォーマンスの直接的な実現要因であることを意味します。Solana上のすべてのスマートコントラクトインタラクション、分散型金融 (DeFi) のスワップからNFT のミントまで、次のスロット内で確認されるのに十分な速さでブロックがバリデーターに到達することに依存しています。

以下では、Turbineの定義、5段階のメカニズム、技術的パラメータ、パフォーマンスへの貢献、セキュリティのトレードオフ、そしてEthereumおよびAvalancheとの比較を網羅します。

この記事について

• Solana Turbineブロック伝搬とは？
• 主要用語：Turbine用語集
• Turbineがブロックを伝搬する方法：ステップバイステップ解説
• Turbineの技術的パラメータ
• TurbineとSolanaのパフォーマンス：ブロック伝搬とTPSの関連性
• Turbineは安全か？セキュリティモデルと既知の攻撃ベクトル
• Solana Turbine vs. Ethereumおよびその他のレイヤー1ブロックチェーン
• SolanaアーキテクチャにおけるTurbine：8つのイノベーションすべて
• Turbineの進化：2017年のホワイトペーパーから現在まで
• Solana Turbineに関するよくある質問
• 結論：Solanaの将来にとってTurbineが重要な理由
• さらに読むべき資料と一次情報源

Solana Turbineブロック伝搬とは？

定義

Solana Turbineは、Solanaのブロック伝搬プロトコルであり、新しく生成されたブロックがシャード（shreds）と呼ばれる数千個の固定サイズのデータパケットに断片化され、ネイバーフッドツリー（neighborhood tree）と呼ばれる階層的なツリー構造を通じてバリデーターネットワーク全体に配布されるメカニズムです。Reed-Solomon誤り訂正符号は、転送中に失われたパケットを復旧し、悪条件のネットワーク下でもバリデーターが完全なブロックを再構築できるようにします。

Turbineが存在するのは、単純なブロードキャストではスケーリングしないためです。ブロックリーダー（特定のスロットのブロックを生成するように指定されたバリデーター）が、すべてのバリデーターに一度に完全なブロックを直接送信すると、各バリデーターは個別に完全なブロックをダウンロードする必要があります。Solanaのネットワークには2,000を超えるアクティブなバリデーターがいるため、このアプローチでは単一ソースからO(n)の帯域幅が必要となり、ネットワークに追加されるバリデーターごとに帯域幅コストが線形に増加します。

Turbineは、BitTorrentプロトコルからコア原則を借用することで、O(log n)の帯域幅スケーリングを実現しています。BitTorrentのピアツーピアファイル共有プロトコルは、大きなファイルを小さな断片に分割し、それらを1つのサーバーから提供するのではなく、多数のノードに同時に分散させることで効率的に転送します。Turbineは、ブロックリーダーが完全なブロックをすべてのバリデーターに送信するのではなく、ブロックをシャードに断片化し、バリデーターの階層的なツリーを介してルーティングし、各レイヤーがシャードを下流に転送するという同じ考え方をブロックチェーンのブロック伝搬に適用します。

このアナロジーには、注意すべき限界があります。BitTorrentは、すべての参加者が平等に扱われるフラットなピアツーピアのスウォームとして機能します。Turbineは、ステーク加重配置を使用した階層的なツリーを採用しており、より多くのSOLをステークしているバリデーターはツリーの上位に配置され、より早くシャードを受け取ります。この違いは、Turbineの効率とセキュリティのトレードオフの両方を理解する上で重要です。

Turbineは、Solana Labsの共同創設者であるAnatoly Yakovenkoによって設計され、Anatoly Yakovenko (2017) によるオリジナルのSolanaホワイトペーパー.) で紹介されました。このプロトコルは、2020年3月のSolanaのメインネットベータローンチ以来、継続的に稼働しています。

主要用語：Turbine用語集

Turbineの仕組みを説明する前に、この記事全体で遭遇する主要な用語を以下に示します。

| 用語 | |---|---| | Turbine | | シャード (Shred) | | データシャード | | コーディングシャード | | ブロックリーダー | | ネイバーフッドツリー (Fanout Tree) | | Reed-Solomon誤り訂正符号 | | Fanout Factor | | スロット (Slot) | | ステーク・ウェイト (Stake-Weighting) |

Turbineがブロックを伝搬する方法：ステップバイステップ解説

Turbineは、5つのステップを経てブロックを伝搬させます。まず、ブロックリーダーがブロックをシュレッド（断片化）し、リード・ソロモン符号によって冗長パケットが生成されます。その結果生じたシュレッドは、すべてのバリデーターが完全なブロックを再構成するのに十分なシュレッドを保持するまで、ステーキングの重みに基づくネイバーフッド・ツリー（近隣ツリー）を通じて流れていきます。以下の各ステップでは、そのプロセスの各段階を詳細に説明します。

ステップ1：ブロックリーダーによるブロックの生成

各ブロックは、ブロックリーダー（ブロックプロデューサーとも呼ばれます）から始まります。これは特定のスロットに対して指定されたバリデーターノードであり、Solanaの決定論的リーダー・スケジュールを通じて事前に選出されます。Solanaのリーダー・スケジュールに関するドキュメント,)によると、そのスケジュールはSolanaの暗号学的時刻記録メカニズムであるProof of History（PoH）クロックから派生したものです。リーダー・スケジュールは公開されており決定論的であるため、どのバリデーターもスロットが始まる前に次のブロックリーダーが誰になるかを確認できます。

ブロックリーダーは、Gulf Stream（現在のブロックが確定する前に、未確認のトランザクションを次に予定されているリーダーに転送するSolanaのトランザクション転送プロトコル）によって転送されたトランザクションを収集し、それらを完全なブロックとして組み立てます。組み立てが終わると、ブロックリーダーはTurbineのプロセスを開始します。

ステップ2：ブロックのシュレッド化（データパケットへの分割）

ブロックリーダーは、Solanaの技術ドキュメントに従い、完成したブロックをシュレッドと呼ばれる固定サイズのデータパケット（各約1.5 KB）に分割します。これらの元のブロックデータの断片はデータ・シュレッドと呼ばれます。フルサイズのSolanaブロックからは、ブロックサイズに応じて数千のデータ・シュレッドが生成されます。

シュレッド化を、大きなファイルを数千の小さなメール添付ファイルに分割し、それぞれを異なる経路で送信するようなものだと考えてみてください。たとえいくつかの添付ファイルが遅れて届いたとしても、送信先で完全なファイルが再構成されます。主な利点は並列伝送です。ツリー内の各バリデーターが異なるシュレッドを同時に受信して転送するため、ネットワークはデータの配信を開始する前に、一つの大きなシーケンシャルな転送を待つ必要がありません。

Turbineのシュレッド化はシャーディングとは異なります。シャーディングはブロックチェーンの状態やトランザクション処理を複数の並列サブネットワークに分割し、バリデーターの異なるサブセットが状態の異なる部分を検証するものです。Turbineがブロックをシュレッド化するのは純粋に伝送効率のためであり、Solanaのバリデーターネットワーク全体が同じ完全なブロック状態を検証します。この断片化は配信メカニズムであり、分割戦略ではありません。

ステップ3：リード・ソロモン符号による冗長シュレッドの生成

リード・ソロモン消失訂正符号は、コーディング・シュレッドと呼ばれる第2のカテゴリーのシュレッドを生成します。これは、元のデータ・シュレッドの一部が輸送中に失われた場合でも、バリデーターが完全なブロックを再構成できるようにする冗長パケットです。この区別は重要です。データ・シュレッドは実際のブロック内容を運び、コーディング・シュレッドは欠落を埋めることができる数学的に導出された冗長性を運びます。

分かりやすい例えとして、リード・ソロモン消失訂正符号はQRコードのように機能します。QRコードの一部が隠れたり損傷したりしても、残りの部分に十分な冗長情報がエンコードされていれば、完全なメッセージをデコードできます。ただし、QRコードの例えには注意すべき限界が一つあります。QRコードは静的なオブジェクトですが、Turbineの消失訂正符号は、特定の数値的な回復しきい値を持つシュレッドのストリーミングバッチに対して動作します。

Solanaの実装によると、バリデーターは全シュレッド（データとコーディングの合計）の約3分の2を受け取る限り、完全なブロックを再構成できます。つまり、このプロトコルは約3分の1のパケット損失までなら、再構成が失敗することなく許容できるということです。リード・ソロモン符号は、CD、DVD、衛星通信などのアプリケーションで数十年の使用実績がある成熟した技術であり、Turbineのフォールトトレランス・メカニズムが実験的な設計ではなく、実績のあるエンジニアリングに基づいているという主張を裏付けています。技術的なパラメータは、Solanaのホワイトペーパー)およびSolana公式のTurbineドキュメント.)から引用されています。

ステップ4：ネイバーフッド・ツリーを通じたシュレッドの分配

ネイバーフッド・ツリー（ファンアウト・ツリーとも呼ばれます）は、Turbineがシュレッドを分配するための階層的なルーティング構造です。Solanaのバリデーターをレイヤー構造に整理し、各レイヤーは上のレイヤーからシュレッドを受け取り、それを下流に再送信します。以下の構造は、ツリーが2つのレイヤーでどのようにスケーリングするかを示しています。

レイヤー0（ブロックリーダー）
        |
        +-- レイヤー1：約200のバリデーター（各々がシュレッドのユニークなサブセットを受信）
                |
                +-- レイヤー2：最大約40,000のバリデーター（200 x 200、各レイヤー1バリデーターがさらに約200へ転送）

各レイヤーのファンアウト係数を約200とすると、ネイバーフッド・ツリーは2〜3レイヤー以内でSolanaの全アクティブバリデーターセット（Solana Foundationのネットワーク統計によると約2,000以上）をカバーします。2つのレイヤーがあれば、数学的にツリーは最大40,000のバリデーター（200 x 200）に到達でき、これは現在のアクティブセットをはるかに上回ります。

この構造を郵便の仕分けネットワークのように考えてみてください。中央拠点が地域仕分けセンターにバッチを送り、そこから各郵便局へ、そして個別の住所へと届けられます。各レイヤーは総負荷のごく一部のみを処理し、単一のノードが全帯域幅のコストを負担することはありません。ただし、中立的な郵便システムとは異なり、Turbineのネイバーフッド・ツリーはステーキングの重みに基づいています。Solanaのプルーフ・オブ・ステークに基づくコンセンスメカニズム（Tower BFT）において、より多くのSOLをステーキングしているバリデーターほどツリーの上位に配置され、シュレッドをより早く確実に受け取れるようになります。

また、ツリーのトポロジーはPoHクロックから派生した検証可能な乱数を使用してスロットごとにランダム化されます。これは、中央の当事者を信頼することなく、どのバリデーターも独自に検証できる乱数源であることを意味します。ツリーはスロットごとに変化するため、敵対的なバリデーターは次のラウンドで誰が隣人になるかを予測できません。このランダム化は、攻撃者がターゲットとなるバリデーターを囲い込んでシュレッドを阻止しようとする「エクリプス攻撃」に対するTurbineの主要な防御策です。

その結果、帯域幅のスケーリングはO(log n)となり、バリデーターの数に対して帯域幅の要件は緩やかにしか増加しません。この特性により、Solanaのバリデーター数が増えるにつれてTurbineの設計の価値はますます高まります。

ステップ5：バリデーターによるブロックの再構成と投票

バリデーターは、消失訂正符号のしきい値（そのブロックの全シュレッドの約3分の2）を満たす十分なシュレッドを受け取ると、完全なブロックを再構成し、Solanaのプルーフ・オブ・ステークに基づくコンセンスメカニズムであるTower BFT（Tower Byzantine Fault Tolerance）に投票を送信します。再構成が完了するまでバリデーターは投票できないため、Turbineの伝搬速度がコンセンサスのスループットを直接左右することになります。

伝搬プロセスはSolanaの目標スロット間隔に合わせて設計されていますが、実際のタイミングとバリデーターのカバー率はネットワークや実装の状況によって異なります。その時間内に伝搬が完了すればコンセンサスが進み、次のスロットが始まります。完了しない場合はスロットがスキップされる可能性があり、一時的にスループットが低下します。

シュレッドが失われた場合はどうなるか？

重要な事実

輸送中にシュレッドが失われた場合でも、そのブロックに対して送信された全シュレッドの約3分の1未満のパケット損失であれば、Solanaのリード・ソロモン消失訂正符号により、バリデーターは受信したコーディング・シュレッドから完全なブロックを再構成できます。

ここでもQRコードの例えが当てはまります。パターンの十分な量が残っていれば、メッセージ全体をデコードできます。パケット損失が回復しきい値を下回っている限り、バリデーターは届いたデータ・シュレッドとコーディング・シュレッドのどのような組み合わせからでもブロックを再構成します。

パケットロスがそのしきい値を超えると、バリデーターは失われたシュレッドを保持している近隣のバリデーターに修復リクエストを発行します。その修復メカニズムは遅延を追加しますが、修復がスロットウィンドウ内で完了できない限り、スロットスキップを直接引き起こすことはありません。

ネットワーク全体にパケットロスが広範囲に及ぶ（単一のパスに限定されない）深刻なネットワーク輻輳下では、複数のバリデーターがスロットウィンドウ内でブロックを再構築できない可能性があります。その連鎖反応はスロットスキップの一因となり、極端な場合には2021年と2022年の主要な輻輳イベント中にSolanaが経験したようなネットワーク劣化につながります。Solana Labsはその後、これらのイベントに対応してTurbineの輻輳処理を改良しました。輻輳とスロットスキップの関係については、以下のセキュリティセクションで説明します。

Turbineの技術的パラメータ

以下の表は、Solanaの公式ドキュメントおよびSolana ホワイトペーパーから引用した Turbine の主要な運用パラメータをまとめたものです。プロトコルが進化するにつれて、Solana Labs によってパラメータが更新される場合があります。現在の値は、Solanaの公式Turbineドキュメント.)で確認してください。

TurbineとSolanaのパフォーマンス: ブロック伝播とTPSの関連性

Solana ホワイトペーパーおよびその後の解説では、理論上のスループットが65,000 TPS近くに達するとされています。観測されるスループットは日付、ワークロード、投票の包含、フィルタリング、ソフトウェアバージョンによって異なります。そのため、測定方法論なしでライブの非投票TPS範囲を示すべきではありません。Turbine はその結果の1つのコンポーネントであり、独立したTPS保証ではありません。

因果関係は以下のようになります。Turbineはシュレッドを十分に速く伝播するため、ネットワーク全体のバリデーターが約400msのスロットウィンドウ内でブロックを再構築し、投票します。コンセンサスが進行します。次のスロットが開始されます。Solanaはそのスロットのテンポを維持します。各スロットには数千のトランザクションを含めることができるため、そのテンポを維持することが高TPSを生み出します。伝播遅延によってテンポが中断されるとTPSは低下しますが、それを維持するとTPSは高止まりします。

理論上のTPSと観測上のTPSの違いには、明確な注意が必要です。Solanaの生のTPS値（より高い数値に達する可能性がある）には、バリデーターの投票トランザクションが含まれます。これらはユーザー提出トランザクションを表さない内部コンセンサスメッセージです。非投票TPSは、他のブロックチェーンのスループットにより比較可能な値であり、Solana Labsのパフォーマンスドキュメントによると、2024-2025年時点の実際の負荷下では通常2,000～4,000 TPSで稼働しています。65,000という数値は、理想的な条件を想定した理論上の天井であり、平均的なネットワーク動作の説明ではありません。

TurbineのO(log n)帯域幅設計は、バリデーター数が増加しても伝播レイヤーがボトルネックになるのを防ぎます。ナイーブなブロードキャストアプローチでは、バリデーター数を倍増させると、各送信ノードに必要な帯域幅も倍増します。Turbineのツリー構造では、バリデーター数を倍増させても追加されるのは1つのレイヤー（各ノードあたり約200の追加バリデーター）だけなので、帯域幅要件は線形ではなくゆっくりと増加します。

重要なポイント

Turbineはトランザクションを実行せず、ブロックデータを伝播します。伝播パフォーマンスは、投票とスループットに影響を与える可能性がありますが、Turbineは固定のTPS値、スロットテンポ、またはファイナリティ時間を保証するものではありません。

Turbineは安全か？セキュリティモデルと既知の攻撃ベクトル

Turbineは3つのコアセキュリティメカニズムを組み込んでいます: 各スロットごとにシャッフルされるランダムルーティング、ステーキング量で重み付けされたツリー配置、およびリード・ソロモン符号による冗長性です。各メカニズムは特定の攻撃面に対処しますが、それぞれ評価に値する正直なトレードオフも導入します。

ランダムルーティングが敵対的バリデーターから保護する方法

ネイバーフッドツリーは、Proof of Historyクロックから派生した検証可能なランダム性を使用して、各スロットごとにシャッフルされます。つまり、敵対的なバリデーターは、次のスロットでどのバリデーターが自分のネイバーになるかを予測できません。これは、レイヤード分布ツリーに対する主な攻撃ベクトルがEclipse攻撃であるため重要です。悪意のあるアクターがターゲットバリデーターの周囲にバリデーターを配置し、シュレッドを隠蔽することで、そのバリデーターがブロックを再構築できなくなり、投票できなくなるという攻撃です。

ツリーのトポロジーはスロットごとに変化するため、攻撃者はその包囲を確実に維持できません。ブロックリーダーは（決定論的なリーダー選出スケジュールを通じて）事前に知られていますが、伝播パスはそうではありません。この非対称性は意図的なセキュリティ設計です。誰がブロックを生成するかの透明性と、それらのブロックがどのように移動するかの不透明性の組み合わせです。

保護には限界があります。十分なステーキング量を持つ攻撃者は、連続するシャッフルで複数の位置に現れ、ターゲットバリデーターの近くにいくらかの統計的な存在感を維持できる可能性があります。ランダムルーティングは、十分なリソースを持つ敵対者に対して不可能にするわけではありませんが、Eclipse攻撃のコストと複雑さを増大させます。

ステーキング量による重み付けと中央集権化の懸念

ステーキング量による重み付けは、高ステーキング量のバリデーターをネイバーフッドツリーの上位に配置します。これは、低ステーキング量のバリデーターよりも早くシュレッドを受信することを意味し、大規模なステーキング運用に構造的な利点をもたらします。最初にシュレッドを受信するバリデーターは、低ステーキング量のピアよりも前に再構築と投票を開始でき、これはコンセンサスプロセスにおいてわずかなタイムミング上の優位性につながります。

結果として、多くのバリデーターで同時に誤り訂正符号（erasure coding）の回復しきい値を超える広範囲なパケットロスが発生し、個別の障害ではなくスロットスキップの連鎖に寄与しました。Solana Labsはその後、ネットワークがトランザクションの取り込みをどのように管理するか、および高負荷下でのTurbineが伝播をどのように処理するかについての変更を含む、輻輳処理に対するエンジニアリング改善を行いました。現在のエンジニアリング状況については、Solana Labsエンジニアリングブログ. を参照してください。アウトエージの履歴は、Turbineのプロダクション記録における事実であり、理論的なリスクではなく、Solanaの技術的耐性を評価する上で誰にとっても関連性のあるコンテキストです。

SolanaのTurbine vs. Ethereumおよびその他のレイヤー1ブロックチェーン

SolanaがEthereumよりもブロックを高速に伝播できる主な理由は、Turbineが階層的な近隣ツリーを使用してシャードを並列に配布するのに対し、Ethereumはバリデーターがランダムなピアのサブセットにブロックをブロードキャストし、そのピアがさらに他のピアに再ブロードキャストするゴシッププロトコルを使用しており、これはスケーリング時には根本的に遅いトポロジーであるためです。以下の表は、ブロック伝播において最も重要な次元でSolana、Ethereum、Avalancheを比較しています。

明確にしておくべき区別があります。Solana自体はクラスター情報共有やプロトコルメタデータのためにゴシッププロトコルを使用していますが、Turbineはブロック伝播という特定のタスクにおいてゴシップを置き換えています。ブロック配布を大規模に行う上で、ゴシップのフラットなトポロジーよりも優れた性能を発揮するのはTurbineの階層的ツリーです。

Ethereumのゴシッププロトコル（バリデーターがランダムなピアのサブセットにブロックをブロードキャストし、そのピアがさらに他のピアに再ブロードキャストして、複数ラウンドでネットワーク全体にブロックを伝播させる）は実装が簡単で、ステーキに基づくいかなるバリデーターも優遇しない、より均一なピア選択を実現します。その設計は、Ethereumが広範な分散化とパーミッションレスな参加を優先していることを反映しています。トレードオフは伝播速度であり、大規模なバリデーターセット全体での複数のゴシップラウンドは、ミリ秒ではなく秒単位で測定されるブロックタイムを生み出します。

Turbineは、上記の表に完全には捕捉されていない2つの点でBitTorrentプロトコルから逸脱しています。BitTorrentはすべての参加者が平等なフラットなピアツーピアのスウォームを使用しますが、Turbineはステーキ加重ハブポジションを持つ階層的なツリーを使用します。BitTorrentにはファイルアセンブリに時間的制約はありませんが、Turbineはコンセンサスを逃さないために400msのスロットウィンドウ内で配信する必要があります。これらの逸脱は、BitTorrentモデルが直面しないブロックチェーン固有の要件に対する設計上の応答です。

AvalancheのSnowflake/Snowball DAG伝播は異なるアプローチを取ります。つまり、単一のブロックリーダーモデルなしで確率的コンセンサスに到達するために、小規模なバリデーターサブセットの繰り返しランダムポーリングを行います。この設計は、ツリーによるものではなくサンプリングを通じてサブ線形帯域幅スケーリングを提供し、Ethereumよりも高速なファイナリティを生み出しますが、Turbineのシャードベースのアプローチとは根本的に異なります。各設計は、速度と分散化、そして耐障害性と複雑さの間で異なるトレードオフを行います。表はこれらのトレードオフを示していますが、1つのアーキテクチャが優れていると宣言することは、設計空間を誤って表現することになります。

Solanaアーキテクチャ内のTurbine：8つのイノベーションすべて

Turbineは、2017年のSolanaホワイトペーパーでAnatoly Yakovenkoが導入した8つのアーキテクチャイノベーションのうちの1つであり、それぞれがブロックチェーンインフラストラクチャにおける異なるパフォーマンスボトルネックに対処するために設計されています。以下は全リストです。

• Proof of History (PoH): Solanaの暗号学的時間測定メカニズム。バリデーターに時間を合意するために通信させる必要なく、イベント順序の履歴記録を作成する検証可能な遅延関数です。PoHはコンセンサスメカニズムではなく、時計です。Turbineが動作するスロット構造を定義します。
• Tower BFT: SolanaのProof of Stakeベースのコンセンサスメカニズム。Practical Byzantine Fault Tolerance (PBFT) のバリアントで、PoHクロックを使用してファイナリティに到達する際のメッセージオーバーヘッドを削減します。
• Turbine: 本記事の主題であるブロック伝播。Turbineは、シャードおよび近隣ツリーを介して新しく生成されたブロックをすべてのバリデーターに配布します。
• Gulf Stream: Solanaのトランザクション転送プロトコル。Gulf Streamは、現在のブロックがファイナライズされる前に、予想される次のブロックリーダーに未確認トランザクションを転送し、リーダーがブロックをアセンブルするのに必要な時間を短縮します。
• Sealevel: Solanaの並列スマートコントラクト実行エンジン。数千の重複しないスマートコントラクトを逐次ではなく並列に処理します。
• Pipelining: トランザクション処理パイプライン。トランザクション検証の異なるステージを専用ハードウェアに割り当て、異なる処理ステージで複数のブロックを同時に検証できるようにします。
• Cloudbreak: Solanaの水平スケーリングされたアカウントデータベース。バリデーターのストレージハードウェア全体での同時読み書きに最適化されています。
• Archivers: 分散型台帳ストレージノード。履歴ブロックチェーンデータをバリデーターから別のストレージレイヤーにオフロードし、バリデーターのハードウェア要件を削減します。

Gulf StreamとTurbineは、トランザクションライフサイクル全体で順番に動作します。Gulf Streamはブロック生成が開始される前に、予想されるブロックリーダーに未確認トランザクションをルーティングします。その後、Turbineは生成されたブロックを、生成完了後にすべてのバリデーターに外部に配布します。この2つのプロトコルは協力して、送信からネットワーク全体への配布までの完全なトランザクションライフサイクルを処理します。

これら8つのイノベーションは、Solana Labsの共同創設者であるAnatoly Yakovenkoが2017年に発行したオリジナルのSolanaホワイトペーパーで導入されました。

バリデーターの視点

Turbineの近隣ツリーにおけるポジションは、バリデーターのハードウェア要件に影響します。レイヤー1（ブロックリーダーに近い）に配置されたバリデーターは最初にシャードを受信し、約200のレイヤー2バリデーターに転送する必要があります。これは、割り当てられたサブ近隣にのみ転送するレイヤー2バリデーターよりも高いアップロード帯域幅を必要とします。ステーキレベルがツリーのポジションを決定します。高ステーキバリデーターはレイヤー1ポジションを占め、それに応じてプロビジョニングする必要があります。オペレーターは、メインネットローンチ以降、最小仕様が進化しているため、Solana Labsからの現在のハードウェア推奨事項を参照する必要があります。

Turbineの進化：2017年ホワイトペーパーから現在まで

Turbineは、2017年にSolana LabsのAnatoly Yakovenkoが執筆したオリジナルのSolanaホワイトペーパーで初めて仕様化され、後から追加された機能ではなく、プロトコルの創設的なアーキテクチャ上の決定の1つとなっています。2017年の仕様は、シャードベースのブロックフラグメンテーション、配布のためのファンアウトツリー、および耐障害性のためのReed-Solomon誤り訂正符号というコア設計を確立しました。

Solana のメインネット ベータ版は 2020 年 3 月にローンチされ、Turbine が初めて本番稼働しました。初期デプロイにより、設計のコアプロパティが確認されましたが、理論上の仕様では完全には予期されていなかった実際の条件、特にトランザクションの輻輳と伝搬負荷との相互作用も明らかになりました。

2021 年と 2022 年のネットワークストレステストイベントの後、Solana Labs は Turbine の輻輳処理にエンジニアリング上の改善を加えました。これには、高負荷なネットワーク下でのシュレッド バッチのキューイングと送信方法の調整が含まれます。これらの改善はプロトコルの基本的なアーキテクチャを変更するものではありませんでしたが、運用範囲の極限での動作を改善しました。

Turbine は現在、毎日数百万件のトランザクションを処理するネットワーク全体で、4 年以上にわたり継続的に本番稼働しています。その稼働記録は、Turbine が実証済みの方法論なのか実験的なものなのかという問いに対して、明確な答えを支持しています。それは、2017 年の仕様にまで遡れる文書化されたエンジニアリングの系譜を持ち、大規模で実践で試された本番プロトコルであるということです。現在のプロトコルパラメータと最近のエンジニアリング変更については、Solana Labs エンジニアリングブログ.) を参照してください。

Solana Turbine ブロック伝搬に関するよくある質問

以下の質問は、Solana Turbine の設計とパフォーマンスに関する最も一般的な問い合わせに対応しています。

Solana Turbine とは何ですか？

Turbine は、Solana が新たに生成されたブロックを 400ms のスロットウィンドウ内にネットワーク上のすべてのバリデーターに配信するために使用するプロトコルです。ブロックをシュレッドに断片化し、階層的なネイバーフッドツリーを通じてルーティングします。Reed-Solomon 誤り訂正符号が、転送中に失われたパケットを処理します。これにより、バリデーターセットが増加してもスケーリングする、高速で帯域幅効率の高いブロック配信が実現します。

Solana におけるシュレッドとは何ですか？

シュレッドは、Turbine がブロック伝送に使用する基本的なデータパケットであり、サイズは約 1.5 KB です。データシュレッド（元のブロックコンテンツを運ぶ）とコーディングシュレッド（Reed-Solomon 誤り訂正符号によって生成された冗長パケットで、一部のデータシュレッドが転送中に失われた場合でもブロックを再構築できます）の 2 種類があります。

Turbine はブロックデータをどのように配信しますか？

ブロックリーダーはブロックをデータシュレッドに分割し、Reed-Solomon コーディングを通じてコーディングシュレッドを生成します。これらのシュレッドはネイバーフッドツリーを流れます。ブロックリーダーは、約 200 の レイヤー1 バリデーターに送信し、各バリデーターはさらに約 200 の レイヤー2 バリデーターに転送します。これにより、2〜3 層で完全なアクティブバリデーターセットをカバーし、約 400ms のスロットウィンドウ内に完了します。

なぜ Solana はブロック伝搬において Ethereum よりも高速なのですか？

Solana は Turbine の階層的なネイバーフッドツリーを使用しており、多数のバリデーターにシュレッドを並列に配信することで O(log n) の帯域幅スケーリングを実現しています。Ethereum はゴシッププロトコルを使用しており、完全なネットワークカバレッジを達成するためにランダムなピアへの複数回の逐次的な再ブロードキャストが必要であり、ブロック時間は約 12 秒になるのに対し、Solana のスロット時間は約 400ms です。どちらのデザインも、意図的なアーキテクチャ上の優先順位を反映しています。

Turbine は安全ですか？

Turbine には、ランダム化ルーティング（ネイバーフッドツリーは各スロットで検証可能なランダム性を使用してシャッフルされます）、Reed-Solomon 冗長性（約 3 分の 1 のパケット損失に耐えます）、および ステーキング する重み付けされた配置が含まれています。ランダム化ルーティングは、Eclipse 攻撃の実行を著しく困難にします。ステーキング重み付けは、軽微な中央集権化のトレードオフをもたらします。高ステーキングのバリデーターは、より早くシュレッドを受け取るため、構造的な利点が生じますが、Tower BFT のコンセンサスルールがこれを部分的に相殺します。

シュレッドが失われた場合はどうなりますか？

パケット損失が全シュレッドの約 3 分の 1 未満に収まる場合、Reed-Solomon 誤り訂正符号により、バリデーターは生存したデータシュレッドとコーディングシュレッドから完全なブロックを再構築できます。このしきい値を超えた場合、バリデーターは、欠落したシュレッドを保持している近隣のバリデーターに修復リクエストを送信します。スロットウィンドウ内に修復が完了しない場合、そのスロットはスキップされる可能性があります。

Turbine は中央集権化のリスクを生み出しますか？

Turbine のステーキング重み付けは、高ステーキングのバリデーターに構造的な利点をもたらし、シュレッドを早く受け取り、ネイバーフッドツリーでより高い位置を占めます。これは実際のトレードオフです。軽減要因としては、Solana が 2,000 以上のアクティブバリデーターに分散されていること、Tower BFT のコンセンサスルールが早期シュレッドアクセスの価値を制限していること、Solana Foundation の ステーキング 委任プログラムが ステーキング 分散を拡大することを目的としていることが挙げられます。

Solana Turbine は誰が作成しましたか？

Turbine は Solana Labs の共同創設者である Anatoly Yakovenko によって設計され、2017 年に公開された Solana ホワイトペーパーで最初に仕様化されました。Solana Labs（エコシステムガバナンスを扱う Solana Foundation とは別のエンジニアリング組織）がプロトコルの維持と継続的な開発を行っています。

Turbine は Gulf Stream とどのように関係していますか？

Gulf Stream と Turbine は、Solana のトランザクションライフサイクルにおける順次的なプロトコルです。Gulf Stream は、ブロック生成が開始される前に未確認トランザクションを想定されるブロックリーダーに転送するため、リーダーはトランザクションの到着を待たずにブロックの組み立てを開始できます。その後、Turbine は生成されたブロックをすべてのバリデーターに外部配信します。

Solana は何 TPS を処理できますか？

Solana の理論上の最大値は、Solana ホワイトペーパーによると、理想的な条件下では約 65,000 TPS です。実世界の条件下では、Solana Labs のパフォーマンスドキュメントによると、2024-2025 年現在、観測される非投票 TPS は通常 2,000〜4,000 トランザクション/秒の範囲です。より高い数字で引用される生 TPS は、ユーザートランザクションではなく内部コンセンサスメッセージであるバリデーター投票トランザクションを含んでいる場合があります。

関連 Solana ガイド

• Solana RPC ノード
• Solana スロットとブロック時間

SOL を OTK_1 で探す

読者は、現在の SOL 市場情報) または SOL/USDT 現物.) を確認できます。これらのリンクは市場情報とアクセスを提供しますが、技術的な主張を検証したり、SOL がすべての読者に適していることを示唆したりするものではありません。

結論: Solana の将来にとって Turbine が重要な理由

Turbine は Solana の約 400ms のスロット時間を実現するエンジニアリングメカニズムです。高速で帯域幅効率の高いブロック伝搬なしには、Solana のバリデーターは、高スループットに必要なスロットケイデンスを維持するために、十分な速さでブロックを受信して投票することはできません。この設計は、シュレッドベースの断片化、階層的なツリー配信、および Reed-Solomon 耐障害性を組み合わせることで、ナイーブなブロードキャストの O(n) 帯域幅問題という真のスケーラビリティ制約を解決します。

この設計には、理解する価値のあるトレードオフが伴います。 ステーキング 重み付けされたツリー配置は、大規模バリデーターに構造的な利点をもたらします。ランダム化ルーティングは、Eclipse 攻撃を軽減しますが、十分にリソースを持つ敵対者に対する攻撃を排除するわけではありません。伝搬レイヤーは、Solana の 2021〜2022 年の停止記録で実証されているように、極端なネットワーク輻輳下ではストレスを受ける可能性があります。これらのいずれも決定的な欠点ではなく、すべてがプロトコルが提供する速度と帯域幅効率と引き換えになされたアーキテクチャ上のトレードオフです。

Turbineは2020年から本番環境で運用されており、現実世界の状況に合わせて洗練されてきました。Solanaのバリデーター数が増加するにつれて、O(log n)のスケーリング特性はますます重要になります。バリデーターセットが倍増するたびに、帯域幅コストが倍増するのではなく、ツリーのレイヤーが1つ追加されるだけだからです。この特性こそが、大規模環境において設計を堅牢なものにしています。また、Turbineのブロック伝搬の速度と信頼性は、伝搬の遅延がトランザクションの確定結果に直接影響を与える高頻度な分散型金融（DeFi）アプリケーションにとって、Solanaを実行可能なインフラレイヤーにしている要因でもあります。

重要なポイント

Turbineは、Solanaの速度に関する主張を信頼に足るものにするエンジニアリングの基盤です。ブロックをシュレッドに断片化し、ステーキングの重み付けがされた近傍ツリーを介してルーティングし、リード・ソロモン消去符号化によって失われたパケットを回復する仕組みを理解することは、それらのパフォーマンスの主張が健全なアーキテクチャに基づいているかどうかを評価する最も明確な方法です。この設計には真の強みと真のトレードオフがあり、その両方がSolanaのインフラストラクチャに対する誠実な技術評価において重視されるべきです。

参考文献および一次資料

以下の一次資料は、本記事で行われた主張の技術的根拠となるものです。

• Turbine Block Propagation (Solana Docs): Solana Labsのエンジニアによって維持されている、Turbineに関する公式テクニカルドキュメント。
• Anatoly YakovenkoによるオリジナルのSolanaホワイトペーパー (2017年): TurbineおよびSolanaの8つのアーキテクチャ革新すべての基礎となる仕様書。
• Solana Labsエンジニアリングブログ: Solana Labsによる最新のエンジニアリングアップデート、プロトコル改善、およびポストモーテム（事後分析）。
• Solana GitHub: turbine ソースコード:): Turbineの実装を直接確認したい開発者向けのソースコード。
• Solana Foundation ネットワーク統計: 現在のバリデーター数、ステーキング分布データ、およびネットワークヘルス指標。

本記事は教育目的のみを目的としており、金融または投資に関するアドバイスを構成するものではありません。暗号資産への投資には大きなリスクが伴います。投資の決定を下す前に、常に自身で調査を行ってください。