Solanaのトランザクション・パイプライン：TPUの4ステージ・パイプライン

このテクニカルガイドでは、Solanaのトランザクション・パイプラインであるTPUの4ステージ・パイプラインと、それがどのように並列処理をサポートしているかについて解説します。

Solanaは約400ミリ秒ごとに新しいブロックを生成します。ほとんどのブロックチェーンは、1つずつトランザクションを処理し、それぞれが完了するのを待ってから次を開始します。Solanaはそうではありません。

Solanaのトランザクション・パイプラインは、SolanaのTransaction Processing Unitが、入ってくるトランザクションを「Fetch（取得）」「SigVerify（署名検証）」「Banking（バンキング）」「Writing（書き込み）」という4つの連続したステージを通じて移動させる手法です。複数のトランザクション・バッチがこれらのステージを同時に通過するため、あるバッチが分散型台帳に書き込まれている間に、次のバッチはすでに検証されており、3番目のバッチはすでに取得されているという状態になります。この並列処理こそが、Solanaブロックチェーン（すべてのトランザクションが記録される分散型台帳）のネイティブ資産であるSolana (SOL) が、ほとんどのレイヤー1ネットワークを遥かに凌駕するスループットを達成できる理由です。

Solanaは、元QualcommのエンジニアであるAnatoly Yakovenko氏によって構築されました。彼は2017年にProof of Historyのホワイトペーパーを公開し、パイプラインの高速化を可能にする暗号学的時計メカニズムを導入しました。プロトコルを開発したサンフランシスコ拠点の組織であるSolana Labsは、バリデータークライアントのコア機能としてパイプライニングを実装しました。その結果、このネットワークは、1秒未満のトランザクション・ファイナリティを必要とする分散型取引所、レンディングプロトコル、オンチェーンのデリバティブ市場など、分散型金融（DeFi）アプリケーションの主要なプラットフォームとなりました。

広く引用される「ブロックチェーンのトリレンマ」では、ブロックチェーンは「拡張性（スケーラビリティ）」「セキュリティ」「分散化」の3つの特性のうち2つしか優先できないとされています。Solanaのトランザクション・パイプラインは、拡張性の次元に対するアーキテクチャ上の回答です。この記事では、パイプライニングとは何か、4つのTPUステージがメカニズムとしてどのように機能するか、Proof of Historyがどのようにパイプラインを可能にするか、Gulf StreamとTurbineがどのようにパイプラインの入出力を処理するか、Sealevelがどのようにパイプライニングの原則をスマートコントラクト実行に拡張するか、Solanaがアーキテクチャ的にEthereumとどう比較されるか、そしてパイプラインの文書化されたトレードオフと限界がどこにあるのかを解説します。

目次

1. Solanaのトランザクション・パイプラインとは何か？（そしてなぜSOLにとって重要なのか）
2. SolanaのTPUパイプラインの仕組み：4つのステージの解説
3. Proof of History：パイプラインを可能にする暗号学的時計
4. Gulf Stream：準備が整う前にトランザクションがパイプラインに入る仕組み
5. CPUパイプラインのアナロジー：なぜSolanaのアーキテクチャはエンジニアにとって馴染み深く感じられるのか
6. Turbine：パイプラインの出力がネットワークに到達する仕組み
7. Sealevel：スマートコントラクト実行に拡張されたパイプライニング
8. Solana対Ethereum：パイプライン・アーキテクチャの比較
9. 制限、混雑、そしてSolanaのパイプライン・アーキテクチャにおける誠実なトレードオフ
10. Solanaのトランザクション・パイプラインに関するよくある質問
11. Solanaのトランザクション・パイプラインとSOLの投資仮説

Solanaのトランザクション・パイプラインとは何か？（そしてなぜSOLにとって重要なのか）

Solanaのトランザクション・パイプラインとは、トランザクション処理を異なるステージに分割し、それらのステージを複数のトランザクション・バッチにわたって並行して実行する技術です。これにより、バリデーターのハードウェアの一部が別のステージの終了を待ってアイドル状態になるのを防ぎます。車の組み立てラインを想像してください。異なる車両が同時に異なるステーションにあり、1台の車が完全に完成するまで次の車が入るのを待つためにラインが止まることはありません。

Solanaはこのアイデアをコンピュータのプロセッサから借用しました。現代のCPUは、命令レベルのパイプライニングを通じて高いスループットを実現しています。ある命令が実行されている間に次の命令がデコードされ、さらにその次の命令はすでにフェッチ（取得）されています。Solanaはこれと同じロジックをバリデーターレベルのトランザクションに適用しています。CPUのステージとSolanaのTPUステージの完全な対応関係については、後述のCPUアナロジーのセクションで説明しますが、核となる原理は同じです。「すべてのステージを常に稼働させておく」ということです。

ほとんどのブロックチェーンはトランザクションを逐次的に処理します。つまり、バリデーターは次のトランザクション（またはバッチ）を開始する前に、1つのトランザクションに対するすべての処理を完了させる必要があります。この逐次モデルでは、一連の操作がどれだけ速く実行できるかによってスループットの天井が決まってしまいます。パイプライニングは、専用のハードウェアコンポーネント間で複数の操作を並列実行することでその天井を打破し、各ステージを高速化することなく確認の遅延（トランザクションの送信からファイナライズまでの時間）を短縮します。

Solanaのテクニカルドキュメントによると、Solanaの理論上のTPS（秒間トランザクション数）は約65,000件です。これは理想的な条件下でのパイプラインの最大値を示しています。実環境における非投票（non-vote）TPSは大幅に低く、ネットワーク負荷やトランザクションの構成にもよりますが、通常2,000〜4,000 TPSの範囲です。Solanaは、バリデーターの投票トランザクションとユーザーが生成した非投票トランザクションを別々にカウントしています。投票を含む合計TPSの数値は高くなりますが、ユーザー向けのスループット指標としてはあまり意味がありません。比較として、Ethereumのレイヤー1の処理能力は秒間約15〜30トランザクションであり、Bitcoinは秒間約7トランザクションです。

主要統計

SolanaのTPUパイプラインは約400ミリ秒ごとに新しいブロックを生成します。これはEthereumのブロック生成時間（約12秒）の約30倍の速さです。 理論上のTPS：約65,000。実環境の非投票TPS：約2,000〜4,000（ネットワーク負荷により変動）。

TPS算出方法に関する注意：65,000という数値はSolanaのテクニカルドキュメントによる理論上の最大値です。実環境の非投票スループットはネットワーク状況により変動します。2,000〜4,000の数値には投票トランザクションは含まれていません。Ethereumの数値はレイヤー1のスループットを示しており、レイヤー2ソリューションは含まれていません。

これを可能にするメカニズムが、すべてのリーダー・バリデーター内で稼働する4ステージ・パイプラインであるSolanaの**Transaction Processing Unit (TPU)**です。次のセクションでは、そのパイプラインがメカニズムとしてどのように動作するかを説明します。

SolanaのTPUパイプラインの仕組み：4つのステージの解説

Solanaの高速性の背後にあるメカニズムは、**Transaction Processing Unit (TPU)**に収容された4ステージのパイプラインです。これは各スロットのリーダー・バリデーター内で動作し、各ステージの専用ハードウェアを通じて複数のトランザクション・バッチを同時に処理します。

Transaction Processing Unit (TPU) とは何か？

Solanaにおいて、**Transaction Processing Unit (TPU)**は、トランザクション処理を物理的に実行する各バリデーターノード内のパイプラインエンジンです。これはSolana独自の用語であり、機械学習で使用されるGoogleのTensor Processing Unitとは無関係です。

TPUは、各約400ミリ秒のスロットでリーダーバリデーター専用に実行されます。非リーダーバリデーターはトランザクション検証ユニット（TVU）を実行し、リーダーが生成したブロックをリプレイおよび検証します。Solanaは、ステーキングされた重みに基づいて各バリデーターのリーダー・スロットを割り当てる、エポックごと（約2〜3日）に事前に公開される決定論的なリーダー・スケジュールを通じて、どのバリデーターがリーダーとして機能するかを決定します。このスケジュールが、後述のGulf Streamセクションで説明されているように、Gulf Streamのトランザクション事前ルーティングを可能にするものです。

TPUアーキテクチャの詳細については、Solana公式TPUドキュメンテーション)およびSolanaスロットタイムドキュメンテーション.)を参照してください。

Solana TPUパイプラインの4つのステージ

TPUパイプラインは、4つの連続したステージでトランザクションを処理します。各ステージは専用ハードウェアによって処理され、各ステージは前のステージから新しい入力を同時に受け取りながら、その出力を次のステージに渡します。

1. フェッチ (Fetch): ネットワーキングスタックは、QUIC（輻輳制御を改善するために元のUDP接続に取って代わった最新のトランスポートプロトコル）を介して生のトランザクションパケットを受信します。フェッチ・ステージはパイプラインの受付ドックです。スロット開始前にGulf Streamが既にロードした事前ロードバッファからトランザクションを取得し、検証済みのパケットをSigVerifyに渡します。

2. SigVerify: GPUは、受信したトランザクションの暗号署名を検証します。各Solanaトランザクションには、状態変更が発生する前に検証する必要がある1つ以上のデジタル署名が含まれています。GPUアクセラレーションにより、この単一ステージ内で数千もの署名検証を並列実行できます。SigVerifyは認証チェックポイントであり、通過したトランザクションはバンキングに送られ、失敗したトランザクションはドロップされます。

3. バンキング (Banking): CPUは、検証済みのトランザクションを台帳状態に適用し、アカウントのデビット・クレジットを実行し、スマートコントラクトの状態変更を処理します。バンキングはパイプラインの会計部門であり、最も計算集約的なステージです。また、高負荷時の主要なボトルネックでもあります。トランザクション量がバンキングの処理能力を超えると、パイプラインはキューイングするのではなく、トランザクションをドロップし始めます。

4. 書き込み (Writing): NVMe SSDは、確認された台帳エントリをディスクに書き込み、このステージはTurbineを介して生成されたブロックデータをネットワークの残りにブロードキャストします。書き込みはディスパッチおよび記録ステージであり、完了するとブロックはオンチェーンに存在し、伝播が開始されます。

コアのパイプラインメカニズムは、4つのステージすべてで同時に動作します。バッチNがバンキングにある間に、バッチN-1は既に書き込みにあり、バッチN+1は既にSigVerifyにあります。いずれのステージも、次のバッチを開始する前に、現在のバッチを完了するために別のステージを待つことはありません。このように、パイプラインは並列スループットを実現します。ハードウェアのすべての部分がスロットのあらゆる瞬間で占有されています。

[図必要: DIAGRAM-01] 4つのステージ（A、B、C、D）が同時に異なるステージにあるバッチを示す4ステージパイプライン。バッチA: 書き込み (NVMe SSD)。バッチB: バンキング (CPU)。バッチC: SigVerify (GPU)。バッチD: フェッチ (ネットワーキング)。各バッチのステージ間進行および4ステージすべてでの同時動作を示す矢印。

Solanaバリデーターは、TPUパイプラインを物理的に実行するノードオペレーターです。各バリデーターはSolanaソフトウェアを実行する専用サーバーであり、ブロックを生成する（現在のリーダーである場合）か、リーダーによって生成されたブロックを検証およびリプレイする（TVUを使用）かのいずれかの責任を負います。

リーダー・スケジュールは、各約400ミリ秒のスロットでどのバリデーターがTPUを実行するかを割り当てます。このスケジュールは、各エポック開始時のステーキング加重バリデーターセットから決定論的に計算されるため、バリデーターは数日前に今後のリーダー・スロットを把握できます。この予測可能性により、Gulf Streamはスロット開始前にトランザクションを今後のリーダーに事前ルーティングでき、スロット開始時にフェッチ・ステージのバッファが満杯であることを保証します。

TPUパイプラインの実行には、エンタープライズグレードのハードウェアが必要です。SigVerifyステージ用の専用GPU、バンキングステージ用の高コア数CPU、書き込みステージ用のエンタープライズNVMe SSD、フェッチステージ用の高帯域幅ネットワーキングが必要です。これらの要件は、Ethereumのバリデーターハードウェアしきい値よりも大幅に高く、これは制限セクションでカバーされている中央集権化のトレードオフを生み出します。現在のバリデーターハードウェア仕様については、Solanaのバリデーター要件ドキュメンテーション.)を参照してください。

Proof of History: パイプラインを可能にする暗号時計

Proof of History (PoH) は、Solanaのパイプラインがハードウェアが許す限り高速で実行できるようにする暗号メカニズムです。バリデーターが次のステージに進む前に、各トランザクションバッチのタイミングに合意するために互いに通信する必要はありません。

メカニズムは次のように機能します。PoHはSHA-256ハッシュの連続シーケンスを生成し、各ハッシュは前のハッシュを入力として取ります。SHA-256計算には測定可能で検証可能な時間がかかるため、生成されたハッシュシーケンスは、チェーンに記録された任意の2つのイベント間に特定の時間が経過したことの暗号証明を構成します。各バリデーターは、他のバリデーターと連絡することなく、このシーケンスを独立して検証できます。

パイプラインとの関連は直接的です。PoHがない場合、パイプラインは各ステージで一時停止し、次のステージが開始する前にネットワークが現在のトランザクションバッチの順序についてコンセンサスに達するのを待つ必要がありました。このノード間通信の往復は、主要なレイテンシ要因となり、ネットワークスケールで400ミリ秒のスロット時間を不可能にしていました。PoHは、すべてのバリデーターがローカルで確認できる共有可能で検証可能な時計を提供することにより、この待機を排除します。パイプラインは、ネットワークメッセージの往復ではなく、PoH時計に基づいて進みます。

Anatoly Yakovenkoは、2017年に公開されたProof of Historyホワイトペーパー)でProof of Historyを導入しました。これは、Qualcomm在籍時の分散システムでの経験を基にしています。

PoHはProof of Stakeではありません。

Proof of HistoryはSolanaのコンセンサスメカニズムではありません。イベントをシーケンス化し、経過時間を証明する暗号時計です。Solanaは、どのバリデーターが経済的に参加資格があるか、そしてどのバリデーターが各スロットをリードするかを決定するために、コンセンサスにProof of Stake（具体的にはTower BFT、Practical Byzantine Fault Toleranceの実装）を使用しています。PoHは順序付けとタイミングを提供します。Proof of Stakeは経済的セキュリティとSybil耐性を提供します。これらは明確に区別される機能です。

Proof of Historyの動作方法、その暗号構造、およびSolanaのコンセンサスメカニズムとの関係についての完全な説明については、専用のProof of History解説を参照してください。

PoHは時計を提供します。Gulf Streamはパイプラインの受信トレイが常に満杯であることを保証します。

Gulf Stream: パイプラインが準備完了になる前にトランザクションがどのようにパイプラインに入るか

Gulf StreamはSolanaのトランザクション転送プロトコルであり、パイプラインのフェッチ・ステージがトランザクションの到着を待ってアイドル状態にならないようにします。ほとんどのブロックチェーンでは、未確認のトランザクションをグローバルなメンプールに保持し、そこでバリデーターが取得するのを待ちます。Solanaにはグローバルなメンプールはありません。Gulf Streamは、決定論的な事前ルーティングでこのモデルを置き換えます。

メカニズムは4つのステップで機能します。

1. Solanaのリーダー・スケジュールは、事前にどのバリデーターが次の約400ミリ秒のスロットをリードするかを公開します。
2. ユーザーまたはアプリケーションがトランザクションを送信すると、Gulf Streamはそれを共有プールではなく、次の関連スロットをリードするバリデーターに直接ルーティングします。
3. そのバリデーターのリーダー・スロットが開始する頃には、そのフェッチ・ステージのバッファは既にトランザクションで事前ロードされています。
4. フェッチ・ステージは、スロット中にトランザクションが到着するのを待つのではなく、この事前ロードされたバッファから取得します。

このメンプールレス設計は、3つの測定可能な利点をもたらします。トランザクションが待機する時間が短縮されるため確認レイテンシが短縮され、グローバルなメンプールがすべてのバリデーターに課すメモリオーバーヘッドが排除され、バリデーターあたりのメモリ要件が大幅に削減されます。

トレードオフは重大です。永続的なトランザクションバッファがないため、迅速に処理されないトランザクションはキューに入れられるのではなくドロップされます。ユーザーは「トランザクションが期限切れました」というエラーを受け取り、再送信する必要があります。高負荷のネットワークでは、この動作は、制限セクションで説明されているように、輻輳イベントの一因となるメカニズムの1つです。

Gulf StreamはFetchステージに直接接続されます。

Gulf Streamは、決定論的なLeader Scheduleを使用して、次のリーダーにトランザクションを事前ルーティングします。バリデーターのTPU Fetchステージがアクティブになると、グローバルなメンプールからではなく、事前にロードされたバッファからプルします。これが、Solanaのパイプラインが通常の条件ではFetchステージでの入力入力をほとんど待たない理由です。

Gulf Streamがパイプラインの入力メカニズムである場合、Turbineは出力メカニズムです。

CPUパイプラインの類推：Solanaのアーキテクチャがエンジニアにとって馴染み深く感じる理由

Solanaのトランザクションパイプラインは、最新のCPUを高速にするのと同じアーキテクチャ原則、つまり命令レベルのパイプライン処理を採用しています。これは比喩ではありません。この設計は、PattersonとHennessyの基礎的なテキスト『Computer Organization and Design』で説明されているのと同じスループット技術からアーキテクチャ的にインスピレーションを得ています。

CPUの命令パイプラインは次のように機能します。1つの命令がすべての処理ステージを完了するのを待ってから次の命令をフェッチするのではなく、CPUは実行を連続したステージ（Fetch、Decode、Execute、Write-back）に分割し、それらのステージを異なる命令で同時に実行します。命令Nが実行されている間、命令N+1がデコードされ、命令N+2はすでにフェッチされています。その結果、個々のステージをより速く実行することなく、スループットはパイプラインステージの数に比例して増加します。

SolanaのTPUパイプラインは、この同じ原則をトランザクションに適用します。ステージごとのマッピングは直接的です。

[図が必要：DIAGRAM-02] 並列比較図。左側：Fetch、Decode、Execute、Write-backのステージと、同時命令処理を示す波線矢印を備えたCPU命令パイプライン。右側：Fetch、SigVerify、Banking、Writingのステージと、同時バッチ処理を示す波線矢印を備えたSolana TPUパイプライン。類似ステージ間のマッピング線。

類推が成り立つ点： どちらのアーキテクチャも、すべてのステージを同時に占有状態に保つことでスループットの向上を達成しています。どちらも、次のアイテムを開始する前に1つのアイテムが完了するのを待ちません。どちらもアイテムを波で処理し、いつでも異なるステージにある複数のアイテムがあります。基本的な洞察は同じです。逐次処理はハードウェア容量を無駄にし、パイプライン並列処理はその無駄を排除します。

類推が破綻する点： SolanaのパイプラインとCPUパイプラインを区別する3つの重要な違いがあります。

第一に、Solanaのパイプラインはネットワークで接続された分散ハードウェアコンポーネント全体で動作し、単一のチップ内ではありません。ネットワーク条件は、CPUの類推がない方法でパイプラインのパフォーマンスに影響を与えます。

第二に、障害モードが異なります。CPUパイプラインのハザードには、データ依存性（1つの命令がまだ完了していない前の命令の出力を必要とする）や分岐予測ミス（プロセッサが間違ったパスで命令をフェッチした）が含まれます。Solanaのパイプラインハザードは種類が異なります。トランザクションスパムは、Bankingステージを処理能力を超えて過負荷にすることで構造的なハザードとして機能し、ネットワーク輻輳はFetchおよびWritingステージを遅くする停止条件として機能します。これらは、内部のデータ依存性ハザードではなく、外部の需要駆動型ハザードです。

第三に、Solanaのパイプラインには、順序実行（out-of-order execution）に相当するものはありません。Proof of Historyクロックは、各バッチ内のトランザクションの厳密な順序付けを強制するため、パイプラインはCPUがデータハザードを回避するために命令を並べ替えることができるように、競合を回避するためにトランザクションを並べ替えることができません。

この類推とその限界を理解することが、Solanaの速度に関する表面的な知識と、真のアーキテクチャ的洞察を分けるものです。

Turbine：パイプラインの出力がネットワークに到達する方法

TurbineはSolanaのブロック伝搬プロトコルであり、パイプラインのWritingステージが完了した後に何が起こるかを処理します。Gulf Streamがパイプラインに常にデータが供給されることを保証するなら、Turbineはパイプラインの出力が可能な限り効率的にネットワークの残りに到達することを保証します。

Writingステージが確認されたトランザクションのバッチを台帳にコミットした後、Turbineはその結果のブロックをshredsと呼ばれる小さなデータパケットに分割し、バリデーターのツリー構造ネットワークを通じて伝搬します。フルブロックをすべてのバリデーターに同時にブロードキャストする（リーダーからの巨大なアップリンク帯域幅を必要とする）のではなく、Turbineは伝搬負荷をネットワーク全体に分散します。ツリー内の各バリデーターはshredのサブセットを受信し、それをツリーの下位の他のバリデーターに転送します。これは、BitTorrentが複数のノードにファイル配布負荷を共有させることでファイルを配布する方法と原理的に似ています。（Turbineはピアツーピアスワームではなく構造化ツリーを使用しており、これはネットワーク信頼性にとって重要な違いです。）

パイプライン互換の設計がここで重要になります。リーダーバリデーターがすでにパイプラインを通じて次のトランザクションバッチの処理を行っている間に、shredはネットワークの残りに伝搬され始めます。ブロック伝搬とブロック生成は同時に実行されます。ブロックNのネットワークレベルの伝播は、ブロックN+1の生成に一時停止を引き起こしません。

エンジニアリング上の利点は、Solanaがすべてのバリデーターノードでエンタープライズレベルのアップリンクを必要とせずに、高いブロック帯域幅を達成することです。リーダーバリデーターのみが完全な生成負荷を負担し、伝搬はネットワーク全体に分散されます。

TPUパイプラインの入出力ラッパー：

Gulf Stream：パイプライン入力（スロット開始前に次のリーダーにトランザクションを事前ルーティング）。 Turbine：パイプライン出力（検証済みブロックデータをバリデーターツリーネットワークを通じてshredとして配布）。 これらにより、TPUパイプラインが両端でアイドル状態にならないことが保証されます。

Turbineはブロックレベルでパイプラインの出力を処理します。Sealevelは、パイプライン処理の原則をスマートコントラクト実行レイヤーまでさらに拡張します。

Sealevel：パイプライン処理のスマートコントラクト実行への拡張

トランザクションのパイプライン処理はTPUで止まりません。Sealevelは、同じ並列処理原則をスマートコントラクト実行に拡張しており、これはSolanaの最も過小評価されているアーキテクチャ上の利点の1つです。

SealevelはSolanaの並列スマートコントラクトランタイムです。これにより、数千ものスマートコントラクト（Solanaのアーキテクチャではプログラムと呼ばれ、開発者にとってEthereumの用語とは異なる重要な区別です）が逐次ではなく同時に実行できるようになります。EthereumのEVM（Ethereum Virtual Machine）は単一スレッドでスマートコントラクトを処理するため、ブロックごとに一度に1つのコントラクトしか実行できません。Sealevelは、利用可能なすべてのCPUコアを使用して、複数のプログラムを並列実行します。

このメカニズムは、Solanaのアカウントモデルに依存しています。Solanaの各トランザクションは、どのアカウントから読み取り、どのアカウントに書き込むかを事前に宣言する必要があります。Sealevelはこれらの宣言を使用して、トランザクションを重複しないグループに分類します。異なるアカウントにアクセスするトランザクションは、状態の競合のリスクなしに同時に実行できますが、アカウントを共有するトランザクションは、正確性を維持するために順次処理する必要があります。

この事前宣言の要件は、プログラムを設計する際にSolanaの開発者が考慮しなければならない設計上の制約です。プログラムはアクセスするすべてのアカウントを事前に宣言する必要があり、これはコントラストストレージへのアクセスが事前に宣言されない、イーサリアムのより寛容な状態アクセスモデルとは異なります。

TPUパイプラインとの類似性は直接的です。TPUパイプラインが、異なる段階で異なるトランザクションバッチを同時に処理することで4つのハードウェアステージすべてを稼働させ続けるのと同様に、Sealevelは競合しないプログラムを同時に実行することで、利用可能なすべてのCPUコアを稼働させ続けます。常にすべてのハードウェアをビジー状態に保つという原則が、ここでは実行レイヤーに適用されています。

アカウント宣言とSolanaのアカウントモデルが実際にどのように機能するかについて詳しく知るには、[Solanaアカウントモデルの解説]の記事をご覧ください。

Solana vs. Ethereum：パイプラインアーキテクチャの比較

Solanaとイーサリアムの性能差は、並列パイプライン処理か順次トランザクション実行かという、根本的なアーキテクチャの選択にまで遡ります。

イーサリアムのEVMは、シングルスレッドのキューでトランザクションを処理します。1つのトランザクションが完了してから、次のトランザクションが開始される必要があります。この設計は意図的なものです。順次実行は状態管理を簡素化し、スマートコントラクトの動作を推測しやすくし、バリデーターが消費者向けハードウェアで参加できるようにすることで、広範で比較的分散型のバリデーターセットを生み出します。イーサリアムには現在、約900,000以上の有効なバリデーターが存在します。

対照的に、Solanaの並列TPUパイプラインは、4つの専用ハードウェアステージにわたって複数のトランザクションバッチを同時に処理します。GPUは署名検証を加速させます。CPUはSealevelを介して、競合しないプログラム全体で状態変更を並行して適用します。NVMe SSDは書き込みを処理し、Turbineは伝播を並行して実行します。この設計により、レイヤー1のスループットが大幅に向上しますが、同時により多くのハードウェアを要求し、約2,000の有効なバリデーターという、より集中したバリデーターセットを生み出します。

パフォーマンスの数値は具体的です。イーサリアムのブロック時間は約12秒ですが、Solanaのスロット時間は約400ミリ秒です。イーサリアムのレイヤー1 TPSは約15〜30ですが、Solanaの実環境での非投票TPSはネットワーク状況に応じて約2,000〜4,000です。（規模の参考として、ビットコインは約7件のトランザクションを1秒間に処理します。）ArbitrumやOptimismを含むイーサリアムのレイヤー2ソリューションは、イーサリアムの実質的なスループットをレイヤー1のベースラインを超えて劇的に向上させており、これは生のレイヤー1の数値を比較する際に重要な文脈となります。

これらのアーキテクチャが投資と開発の側面でどのように比較されるかの詳細な内訳については、当社のSolana vs. Ethereum アーキテクチャの完全比較.)をご覧ください。

どちらのアーキテクチャが決定的に優れているということはありません。両者は、広く引用されているブロックチェーンのトリレンマにおける意図的なトレードオフを象徴しています。イーサリアムは、分散化と豊かなレイヤー2エコシステムのためにスループットを犠牲にしました。Solanaは、レイヤー1のスループットのために分散化を犠牲にしました。どちらのトレードオフが特定のアプリケーションや投資理論により適しているかは、具体的な要件によります。

Solanaのパイプラインアーキテクチャの限界、混雑、そして誠実なトレードオフ

Solanaのパイプラインアーキテクチャは、実証済みのパフォーマンス上の利点をもたらすと同時に、実証済みのトレードオフも伴います。開発や投資の目的でネットワークを真剣に評価するには、その両方を理解することが不可欠です。

パイプラインが圧倒される時：混雑の仕組み

パイプラインの混雑は、トランザクションのボリュームがBankingステージの処理能力を超えたときに発生します。一連の事象は明確です。Bankingステージが、流入するトランザクションボリュームに追いつかなくなります。SolanaのメンプールのないGulf Stream設計は、永続的なトランザクションバッファを保持しないため、迅速に処理できないトランザクションは、キューに入れられるのではなく破棄されます。ユーザーは「transaction expired（トランザクション期限切れ）」エラーを受け取り、再送信する必要があります。極度の混雑時には、パイプラインが総トランザクションボリュームに対して投票トランザクションを十分に速く処理できなくなるため、バリデーターがコンセンサスから外れ、ネットワークが停止することがあります。

Solanaは、2021年9月、2022年1月、2022年5月などに大規模なネットワーク停止を経験しました。原因は一様ではありませんでした。過剰なトランザクションボリュームがBankingステージの能力を圧倒したケースもあれば、組織的なトランザクションスパムキャンペーン、ソフトウェアのバグ、またはパイプラインのスループット制限とは無関係なコンセンサスの失敗が原因であったケースもあります。すべてのSolanaの停止をパイプライン処理のせいにするのは不正確です。特定の条件下でパイプラインの容量制限を超えたことが一部の停止事案に寄与しましたが、他の停止には別の根本原因がありました。

Solanaのネットワーク事象とその原因に関する記録された履歴については、[Solanaネットワーク停止：歴史と投資家にとっての意味]の記事をご覧ください。

混雑に対するSolanaのアーキテクチャ上の対応

Solanaは、パイプラインの混雑に対処するため、2022年以降、いくつかのアーキテクチャ上の変更を行ってきました。

• QUICプロトコルの採用: Solanaは、Fetchステージにおける元のUDP接続をQUIC（UDPに欠けている混雑制御と接続管理を提供する最新のトランスポートプロトコル）に置き換えました。QUICにより、Fetchステージは高負荷下でトランザクションの取り込みをよりインテリジェントに管理できるようになり、低コストのトランザクションスパムの効果を低減させます。
• ステーク加重型QoS (SWQoS): Solanaは、より高いステーク重量を持つバリデーターから転送されたトランザクションを優先する、ステーク加重型クオリティ・オブ・サービス（SWQoS）を導入しました。これにより、ステークの低いアクターがスパムトランザクションでパイプラインを溢れさせ、正当なユーザーのトランザクションを犠牲にしてBankingステージの容量を消費する能力が低下します。
• 優先手数料: ユーザーはトランザクションに優先手数料を付加することで、需要が高い時期にパイプラインを通じてより速く処理されるための支払意思を示すことができます。
• Firedancer: Jump Cryptoによって開発された独立したバリデータークライアントの実装であるFiredancerは現在開発中であり、単一の実装リスクを軽減する代替クライアントを提供することで、パイプラインのスループットを大幅に向上させ、ネットワークのレジリエンスを改善することを目指しています。

中央集権化のトレードオフ：高いハードウェア要件

Solanaのバリデータに対する高いハードウェア要件は、測定可能な中央集権化のトレードオフをもたらします。TPUパイプラインを実行するには、SigVerifyステージ用のエンタープライズGPU、Bankingステージ用の多コアCPU、Writingステージ用のエンタープライズNVMe SSD、およびFetchとTurbine用の高帯域幅ネットワークが必要です。これらの仕様は、一般のバリデータにとって大きなコストの障壁となります。

その結果、Ethereumよりも集中したバリデータセットとなっています。Solanaのアクティブバリデータ数は約2,000ですが、Ethereumは約90万以上です（どちらの数値も変動するため、最新のネットワークデータで確認する必要があります）。Solana LabsとSolana Foundationはこのトレードオフを明確に認めています。ハードウェア要件はスループット優先の設計選択による意図的な結果であり、ブロックチェーンのトリレンマにおけるスケーラビリティと分散化の軸上でのSolanaのポジションを表しています。このトレードオフが許容できるかどうかは、評価者が何を優先するかによります。

よくある質問：Solanaのトランザクション・パイプライン

SolanaのTransaction Processing Unit（TPU）とは何ですか？

SolanaのTransaction Processing Unit（TPU）は、トランザクションを物理的に処理するバリデータノード内のパイプラインエンジンです。これはSolana独自の用語であり、機械学習で使用されるGoogleのTensor Processing Unitとは一切関係ありません。TPUは約400ミリ秒のスロットごとにリーダーバリデータ上でのみ実行され、Fetch、SigVerify、Banking、Writingの4つのステージを通じて動作します。リーダーではないバリデータは、代わりにブロックを検証および再生するためにTVU（Transaction Validation Unit）を実行します。

Proof of Historyとは何ですか？またパイプラインとどのように関係していますか？

Proof of History（PoH）は、検証可能で時間順に並んだSHA-256ハッシュのシーケンスを生成する暗号化クロックです。PoHは、各パイプラインステージを進める前にバリデータ間でトランザクションの順序について通信し合意する必要性をなくすことで、パイプライン処理を可能にします。PoHがなければノード間の通信遅延が主要なボトルネックとなりますが、PoHがあれば、ネットワークのラウンドトリップを必要としない、共有されローカルで検証可能なクロックに基づいてパイプラインが進みます。

SolanaのGulf Streamとは何ですか？

Gulf Streamは、Solanaのメンプールのないトランザクション転送プロトコルです。Gulf Streamは、未確認のトランザクションをグローバルなプールに保持するのではなく、決定論的なリーダー・スケジュールを使用して、スロットが始まる前に次のリーダーバリデータにトランザクションを直接ルーティングします。リーダーのFetchステージがアクティブになると、プリロードされたバッファからトランザクションを取り出します。この事前ルーティングにより、SolanaはFetchステージでトランザクションの到着を待つことなく、約400ミリ秒のスロットタイムを維持できます。

Sealevelとは何ですか？

Sealevelは、Solanaの並列スマートコントラクト実行環境です。各トランザクションが読み書きするアカウントを事前宣言することを要求することで、数千のスマートコントラクト（Solanaのアーキテクチャではプログラムと呼ばれます）を同時に実行することを可能にします。Sealevelは重複しないトランザクションを識別し、利用可能なすべてのCPUコアで並列に実行します。これにより、TPUパイプラインからの同じ並列処理の原則がスマートコントラクトの実行レイヤーまで拡張されます。

Solanaのトランザクション・パイプラインがネットワーク停止の原因になりますか？

パイプラインの混雑はSolanaのいくつかの停止の一因となりましたが、すべてではありません。トランザクション量がBankingステージの処理能力を超えると、メンプールのない設計によりトランザクションがキューに入れられずドロップされ、極端な混雑時にはバリデータがコンセンサスから外れることがあります。また、Solanaは、パイプラインのスループット制限とは無関係なソフトウェアのバグ、コンセンサスの失敗、調整されたトランザクションスパムによる停止も経験しています。QUICの採用とSWQoSの導入により、2022年以降、混雑による障害は減少しています。

Solanaの実際のTPSはどれくらいですか？

Solanaの理論上のTPSは約65,000であり、これはSolanaのテクニカルドキュメントによる理想的な条件下でのパイプラインの最大値を示しています。実際の非投票TPSは、ネットワーク負荷、トランザクションタイプの構成、バリデータのパフォーマンスによって異なりますが、通常2,000〜4,000の範囲です。Solanaはバリデータの投票トランザクションをユーザー生成のトランザクションとは別にカウントしています。投票を含む合計は高くなりますが、ユーザー向けのパフォーマンス指標としてはあまり意味がありません。

SolanaはどのようにしてEthereumより速いのですか？

Solanaの4段階の並列TPUパイプラインは、複数のトランザクションバッチを同時に処理しますが、EthereumのEVMはシングルスレッドでトランザクションを逐次処理します。その結果、Solanaのスロットタイムは約400ミリ秒であるのに対し、Ethereumのブロックタイムは約12秒であり、Solanaのレイヤー1のTPSは約2,000〜4,000であるのに対し、Ethereumは約15〜30です。両方のアーキテクチャは、ブロックチェーンのトリレンマにおける異なるトレードオフを伴う、意図的な設計上の選択を反映しています。

Solanaのパイプラインが混雑するとどうなるか？

トランザクション量がBankingステージの処理能力を超えると、Solanaはトランザクションをキューに入れるのではなくドロップします。これは、メンプールのないGulf Streamの設計が永続的なバッファを維持しないためです。影響を受けたトランザクションは「transaction expired（トランザクション期限切れ）」エラーを返し、再送信する必要があります。深刻な混雑時には、投票トランザクションの処理が遅れ、バリデータがコンセンサスから外れる可能性があります。QUICとSWQoSは、スパムによる混雑の影響を軽減しますが、根本的な容量制限は既知のアーキテクチャ上のトレードオフとして残っています。

BybitでSOLを探索する

Solana価格ページ を使用して現在のSOL市場データを確認するか、現物取引がお客様の目的に合致する場合は SOL/USDT 現物取引市場 にアクセスしてください。Bybit プラットフォームでの取引活動は、Solanaのオンチェーン・トランザクションの送信とは異なります。Solanaネットワーク上でSOLを入金または出金する際には、ネットワーク手数料が発生する場合があります。

経験豊富なデリバティブトレーダーの方は、SOLUSDT 無期限市場. もご確認いただけます。デリバティブには追加のリスクが伴い、現物 SOLの所有権を提供するものではありません。

Solanaのトランザクション・パイプラインとSOLの投資仮説

Solanaのトランザクション・パイプラインは、マーケティング上の主張ではなく、真のアーキテクチャの革新です。4段階のTPUパイプラインは、レイヤー1のスループットに対する一貫したエンジニアリングアプローチを象徴しています。Proof of Historyは、ネットワークのコンセンサス遅延なしにパイプラインを前進させる暗号化クロックを提供します。Gulf Streamはパイプラインの入力をプリロードします。Turbineはパイプラインの出力を配信します。Sealevelは、同じ並列処理の原則をスマートコントラクトの実行まで拡張します。

Solana（SOL）を保有または評価している投資家にとって、パイプラインを理解することは、Solanaのパフォーマンスの差別化要因となっている技術的基盤を理解することを意味します。このアーキテクチャの速度面での優位性は構造的なものであり、偶発的なものではありません。それは、トランザクションのライフサイクルのあらゆる層で並列処理の原則をどのように適用するかという、特定のエンジニアリング上の選択から生じています。

それらのエンジニアリング上の選択には、真のトレードオフが伴います。2021年と2022年の混雑事象は、メンプールのない設計とBankingステージのスループット上限が、敵対的または極端な負荷条件下では現実的な制約になることを証明しました。バリデータの高いハードウェア要件は、Ethereumよりも集中したバリデータセットを生み出しており、これはブロックチェーンのトリレンマの「スケーラビリティと分散化」の軸における意図的なポジションを示しています。QUICの採用、SWQoSの導入、Jump Cryptoによって開発中のFiredancerクライアントなど、Solanaの継続的なアーキテクチャの進化は、これらの限界を押し上げようと積極的に取り組んでいるプロトコルであることを反映しています。これらは開発の軌道を示すものであり、解決済みの問題ではありません。

Solanaのパイプラインスループットは、1秒未満のトランザクション確定（ファイナリティ）を必要とする DeFi アプリケーションにとって、意味のあるプラットフォームとなっています。一方、Ethereumは、より広範な分散化、成熟したレイヤー2エコシステム、および大規模な開発者ベースという異なる優先事項を持つ、有効なアーキテクチャの選択肢であり続けています。両方のネットワークは、実稼働中のブロックチェーンの中でそれぞれ独自の地位を占めています。

免責事項： 本記事は教育目的のみで提供されており、投資助言、財務助言、取引助言、またはその他のいかなる形式の助言も構成するものではありません。Solana（SOL）は暗号資産です。暗号資産は非常にボラティリティの高い資産であり、大きな損失のリスクを伴います。投資判断を下す前に、必ずご自身で調査を行い、資格を持つ財務アドバイザーにご相談ください。

このトピッククラスターの関連記事：

• Solana vs. Ethereum：アーキテクチャの完全比較: SolanaとEthereumのアーキテクチャ完全比較