--- id: 4 title: Pipeline BFT と実行の分離：実行待ちで並ばないコンセンサス slug: bitroot-pipeline-bft date: 2026/08/02 summary: 古典的 BFT の逐次フェーズとメッセージングの複雑さがスループットをどう制限するか、Pipeline BFT が高さをパイプラインでどう重ねるか、そしてコンセンサスを実行から分離した後に正しさの境界がどこにあるかを整理します。 keywords: Pipeline BFT,実行分離,BLS,コンセンサス,Bitroot heroImage: /cms-media/file/5In%20depth%20analysis%20of%20Bitroot%20multi%20engine%20and%20execution%20design.jpg --- コンセンサスと実行が結びついていると、システムは投票を待つ間にサイクルを浪費し、CPU は遊びます。このブロックのトランザクションが終わるまで次の高さは安全に進めないからです。Pipeline BFT はまずフェーズのパイプライン化とバリデータ間通信コストを狙います。楽観的並列実行と組み合わせると、分離後に最終状態が順序づけられた直列セマンティクスと一致することを誰が保証するのか、という問いにも答える必要があります。 ## 古典的 BFT が詰まる場所 古典的 BFT（propose、pre-vote、pre-commit、commit）は安全性の面では成熟していますが、レイテンシに優しくありません。 1. **高さの直列化**：次の高さはしばしば前の高さの重要なフェーズを待ちます。 2. **ほぼ二乗のメッセージング**：n 人のバリデータがゴシップすると、帯域と署名検証が高くつきます。 3. **資源のミスマッチ**：CPU はネットワーク待ちで遊び、ネットワークは検証のスパイク中に遊びます。 バリデータ集合を増やすことは分散化の物語に資し、コンセンサスの予算を突破できます。これは分散化と性能の緊張のコンセンサス側の姿です。[分散化と性能](/ja/blog/decentralization-performance-tradeoff)を参照してください。 ## Pipeline BFT：ステージを重ねる 直感は CPU のパイプラインです。異なる命令が同時にフェッチ、デコード、実行に位置します。高さに対応づけると次のようになります。 - 高さ N がコミットしている間に、N+1 が pre-commit し、N+2 が pre-vote し、さらに新しい高さが propose を始めてもよい。 - リーダーは VRF 風の検証可能ランダム性でローテーションし、固定提案者による検閲と単一リーダーリスクを減らす。 - BLS12-381 クラスの集約は多くの票を素早く検証できる集約へ圧縮し、「バリデータを増やす」ことが各ノードの検証負荷を線形に増幅しないようにする。 パイプライン化が高めるのは**順序づけと確認パスの利用率**であり、自動的に実行レイヤーの TPS と等しくなるわけではありません。実行が単一スレッドのままだと、速くなったコンセンサスは保留キューを成長させるだけです。アーキテクチャの地図は[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)、単一スレッドの上限は[単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck)を参照してください。 ## 実行の分離：まず順序づけ、並列で収束 分離後、役割は通常こうなります。 - **コンセンサス**：グローバルなトランザクション順序（とブロック境界）を高速に出す。 - **実行**：その順序の下で状態を楽観的に並列で進め、コンフリクト時は固定ルールで再実行し、直列セマンティクスが成り立つまで続ける。 これは他のプロジェクトが「コンセンサスと実行の分離／遅延実行」として論じるのと同じエンジニアリング判断です。順序が安定すれば、実行は非同期に追随できます。Bitroot 側の実行の詳細は[マルチエンジン並列実行](/ja/blog/bitroot-evm)と[楽観的並列化](/ja/blog/bitrootevm-)、データベース OCC の背景は [OCC 入門](/ja/blog/optimistic-concurrency-control-intro)、路線の対比は[並列実行の三つの路線](/ja/blog/parallel-execution-approaches)を参照してください。 三つの正しさのレッドラインは、マーケティングよりも設計で重要です。 1. 同じ順序づけられたバッチをリプレイする正直なノードは、同じ状態ルートに到達しなければならない。 2. 並列スケジューリングは、スレッドのタイミングに依存する非決定性を持ち込んではならない。 3. ビザンチンバリデータは、ローカルの実行結果を偽造するだけでは正規状態を定義できない。正規状態は依然としてコンセンサス順序と決定的な実行関数から来る。 ## AI／エージェントシーンとの関係（控えめに） 低く予測可能な確認レイテンシは、エージェントがオンチェーンで決済しリスク管理するのに役立ちます。AI の学習自体は通常、コンセンサスのホットパスでは動きません。Pipeline BFT を「AI 学習のために設計された」と呼ぶのは過大な主張です。より正確には、高頻度の自動決済のためのコンセンサス基盤を提供するものであり、コンピュートネットワークと検証可能なコンピュートは別の場所にあります。[分散型 AI スタック](/ja/blog/aibitrootweb3ai)を参照してください。 確認レイテンシとスループットのテストネットまたはエンジニアリング上の目標は、条件を明記すべきです。追随速度はコンフリクト率で変わるため、パイプラインの深さを安定した TPS の約束に変換しないでください。指標の読み方は[性能指標の用語集](/ja/blog/performance-metrics-glossary)、プロダクトの境界は [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 ## 安全性とライブネスはパイプラインでも必須 バリデータ集合を増やしパイプラインを深くしても、障害閾値内で二重コミットを防ぎ（安全性）、同期ウィンドウの下でブロックを作り続ける（ライブネス）必要があります。リーダーローテーションとタイムアウトは通常ライブネスに効き、集約可能な署名は主に検証を速くし、それ自体で障害閾値を変えるものではありません。コンセンサスフェーズの時間と実行の追随遅延は分けて監視してください。基準については[単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck)を参照してください。 運用上、Pipeline BFT の問題はしばしばこう見えます。票が定足数に達しない、ビューチェンジが頻発する、あるいは実行の遅れが「コンセンサスが停止した」と誤読される。ログは提案の到着、集約署名の完了、実行の状態ルートコミットを分離すべきです。そうして初めて、ネットワークの増強、タイムアウトの調整、コンフリクト検出の修正を判断できます。スケーリングの地図は[ブロックチェーン・スケーリングマップ](/ja/blog/blockchain-scaling-map)、分散化の緊張は[分散化と性能のトレードオフ](/ja/blog/decentralization-performance-tradeoff)を参照してください。 バリデータ運用者にとって、パイプライン化はハードウェアと帯域のプロファイルも変えます。メッセージングはより継続的になり、検証は集約パスに依存し、ディスクは実行の追随とスナップショットに引っ張られます。容量計画では、コンセンサスのみとコンセンサス＋実行のプロファイルを分けて測定すべきです。空ブロックの TPS では不十分です。用語については[性能指標の用語集](/ja/blog/performance-metrics-glossary)を参照してください。 ## パイプラインの深さとテールレイテンシ パイプラインを深くすると平均の高さ進行は上がりますが、テールレイテンシの要因も増幅します。ある高さで票が詰まると、その後ろに重なるステージが積み上がります。エンジニアリングにはタイムアウト、ビューチェンジ、そしてコンセンサスフェーズの時間と実行の追随遅延を分離する明確な監視が必要です。そうでなければ実行のホットスポットがコンセンサスの障害と誤診されます。BLS 集約は検証コストを下げますが、障害閾値は変えません。リーダーローテーションは検閲の面を改善しますが、スループットの唯一の決定要因ではありません。 楽観的並列実行と組み合わせる場合は、コンフリクト率が急上昇したときに、順序づけ済みだが見つかっていないバッチが膨らまないかも見てください。キューが伸びると、Pipeline BFT が高さを進めていてもサブ秒の確認目標は消え去ります。指標については[性能指標の用語集](/ja/blog/performance-metrics-glossary)、ホットスポットがコンフリクトをどう増やすかについては[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 ## 最終性と確認レイテンシとの関係 ユーザーが言う「高速な確認」は、票が集まったこと、状態ルートが照会可能になったこと、あるいは下流のサービスがすでにレシートを見たことを意味するかもしれません。Pipeline BFT が直接最適化するのは最初のものです。分離後は、後者は実行の追随に依存します。プロダクトのドキュメントは、コンセンサスの最終性目標、実行の可視性目標、テストネットでの観測範囲を分けて開示すべきです。 そうでなければ、コンセンサスのダッシュボードは緑のまま、ウォレットは保留を表示します。確認レイテンシ、最終性、コンフリクト率はまとめて読んでください。[性能指標の用語集](/ja/blog/performance-metrics-glossary)を参照してください。楽観性が可視性にどう影響するかについては[楽観的並列化](/ja/blog/bitrootevm-)を参照してください。 パイプライン化されたコンセンサスは高性能 L1 にとって必要ですが十分ではありません。決定的な並列実行と制御された状態の成長がなければ、速い順序づけは速いキューイングにすぎません。閉ループのためには、マルチエンジンと OCC の記事と併せて読んでください。 ## 実装におけるよくある二つの見積もり違い 一つ目は、深いパイプラインに少ない実行エンジン。コンセンサスが高さを進める一方で実行キューが爆発します。二つ目は、多数のエンジンに依然としてほぼ二乗のコンセンサスメッセージング。検証と帯域が先に飽和します。容量計画では、バリデータ数、パイプラインの深さ、エンジン数、目標コンフリクト率をまとめて記述し、そのマトリクスをテストネットで回帰すべきです。一つのつまみを回すのではありません。 ## まとめ Pipeline BFT はステージの重なりと署名集約によって BFT の直列化と通信の税を和らげ、実行の分離は順序づけが実行に引きずられるのを止めます。実際のシステム能力は、パイプライン化されたコンセンサスと楽観的並列実行が決定的リプレイで整合するかどうかにかかっています。片側だけを最適化すると、もう片側がすぐに新しいボトルネックになります。 ## 関連記事 - [並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm) - [マルチエンジン並列実行](/ja/blog/bitroot-evm) - [Bitroot のポジショニング](/ja/blog/bitroot-positioning)