--- id: 5 title: Bitroot 並列 EVM アーキテクチャ概要：コンセンサス、実行、状態がどう協調するか slug: bitrootevm date: 2026/07/30 summary: Bitroot の並列 EVM をレイヤーごとに概観します。Pipeline BFT、楽観的並列実行、状態シャーディング、BLS 集約がどう組み合わさるのか、そして性能の数値をメインネットの約束ではなくテストネット／エンジニアリング上の目標としてどう読むかを解説します。 keywords: Bitroot,並列EVM,アーキテクチャ概要,Pipeline BFT,状態シャーディング heroImage: /cms-media/file/6Design%20and%20Implementation%20of%20High%20Performance%20Blockchain%20Architecture.jpg --- 高性能 L1 で最もよくある失敗するコミュニケーションは TPS ポスターです。役に立つのは三つの問いに答えることです。誰がトランザクション順序を決めるのか、状態遷移はどう並列化されるのか、状態のサイズはどう成長するのか。本稿は Bitroot の並列 EVM の地図であり、パラメータ競争ではありません。より細かい仕組みは Pipeline BFT、マルチエンジン、楽観的並列の各記事にあります。理論は OCC 入門とスケーリングマップを指し、本概要はそれらの記事を重複させません。 ## 問題はどこから始まるのか 古典的な EVM はブロック内でトランザクションを一つずつ実行します。正しさは推論しやすい一方で、スループットは単一コアの直列セマンティクスに制限されます。スケーリングマップでは、並列実行はロールアップやシャーディングなどの中の一つのセルにすぎません。[ブロックチェーン・スケーリングマップ](/ja/blog/blockchain-scaling-map)と[単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck)を参照してください。Bitroot の選択は、完全な EVM 互換性を保ち、楽観的並列の道を取り、コンセンサスを実行から分離し、開発者にアカウントリストの事前宣言を強制しない、というものです。 ## 三つのレイヤーの協調、三つのステッカーではない | レイヤー | 仕組みの焦点 | 何に対処するか | |-------|-----------------|-------------------| | コンセンサス | Pipeline BFT、VRF リーダーローテーション、BLS12-381 集約 | 直列フェーズとほぼ O(n²) のメッセージング／検証コスト | | 実行 | 楽観的並列、動的グループ化、三段階のコンフリクト検出 | 単一スレッドの上限と再実行の影響範囲 | | 状態 | アカウント／スロットのシャーディング、階層化キャッシュ、大きなオブジェクトはオフチェーン＋オンチェーンハッシュ | 単一ツリーの容量とフルノードのストレージ圧力 | コンセンサスは順序に素早く合意し、実行は順序づけられたバッチ上で状態遷移を並列に進め、状態は「実行は並列化したがディスクとメモリが単一点のまま」を避けます。どれか一つのレイヤーが欠けると、ポスターの数値が実際のワークロードに耐えることはほとんどありません。プロダクトの座標は [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 ## Pipeline BFT：高さを重ねる 古典的 BFT はしばしば、ある高さの propose→vote→commit を待ってから次を本格的に始めます。Pipeline BFT はステージをパイプライン化します。高さ N が pre-commit にある間に、N+1 が pre-vote に、N+2 が propose を始められます。リーダーは VRF でローテーションし、予測可能な操作を減らします。BLS 集約は多くのバリデータ署名をほぼ一定の検証コストへ圧縮し、集合の拡大がコンセンサス作業を線形に爆発させないようにします。詳細と分離がなぜ重要かについては [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft)を参照してください。 分離とは具体的には、コンセンサスが次の高さの順序づけ作業を進める前にブロックの完全な実行を待たなくてよい、ということです。実行は非同期に追随できます。エンジニアリング上の代償は厳格です。並列性がどうであれ、最終状態はコンセンサス順序の下での直列実行と一致しなければなりません。これはブロックチェーンの OCC がデータベースの OCC に対して追加で負う厳しい制約です。背景は [OCC 入門](/ja/blog/optimistic-concurrency-control-intro)を参照してください。 ## 楽観的並列：EVM を保ち、複雑さをランタイムに残す 決定論的な並列（明示的なアカウントリスト）とオブジェクトモデルは、しばしば理論上の並列性で勝りますが、移行コストが高くなります。楽観的な道は、ほとんどのトランザクションは衝突しないと仮定して並列に実行し、コンフリクト時に選択的に再実行します。Bitroot の資料は、実行前の依存関係分析、実行中のバージョン監視、実行後の状態ルートチェックという階層化された検出を強調し、より早く失敗してロールバックを縮小します。深掘りは[楽観的並列化](/ja/blog/bitrootevm-)、業界の対比は[並列実行の三つの路線](/ja/blog/parallel-execution-approaches)を参照してください。 マルチエンジンのスケジューリング、シャード内の並列、シャード間のメッセージングは、実行／状態のエンジニアリング上の展開です。[マルチエンジン並列実行](/ja/blog/bitroot-evm)を参照してください。ホットなワークロードが並列の配当を食いつぶすときについては[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 AI エージェントやジョブ決済コントラクトにとって、このレイヤーは計画可能な確認とスループットの期待を提供します。学習自体は通常、コンセンサスのホットパスには入りません。[分散型 AI スタック](/ja/blog/aibitrootweb3ai)を参照してください。 ## 性能の数値の読み方（注意点付き） 公開資料とテストネット資料は、おおむね数百ミリ秒の確認、シャードあたり数千〜数万 TPS、マルチシャードでのスケーリングを挙げてきました。数値はハードウェア、トランザクションの構成、コンフリクト率に依存します。生の数値を単純比較せず、メインネットの保証や財務リターンに外挿しないでください。レイテンシ分布、コンフリクト率、検証可能なリプレイコストを併せて読むことを優先してください。用語集は[性能指標の用語集](/ja/blog/performance-metrics-glossary)、分散化の緊張は[分散化と性能](/ja/blog/decentralization-performance-tradeoff)、互換性の境界は [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。 ## ポスターにストレージとネットワークを省略させない 実行が速くても、依然としてストレージに当たり、票をネットワーク越しに送ります。大きなオブジェクトはオンチェーンハッシュを伴ってオフチェーンに属し、パイプラインが深いほどテールレイテンシに敏感になります。実際の負荷では、ホットキャッシュのヒット率とシャード間キューが、純粋な実行カーネルよりも先にユーザーに見えることがよくあります。読者向けの案内は[誰が並列 EVM を読むべきか](/ja/blog/who-should-read-parallel-evm)を参照してください。 互換性のコストも同じ表に載せるべきです。バイトコードレベルの EVM を保つことは、読み書きの完全な事前宣言を要求できないことを意味し、並列性の上限はランタイムのコンフリクト挙動に従います。これはプログラミングパラダイムを並列性と引き換えにするオブジェクトモデルチェーンとは逆です。[並列実行の三つのアプローチ](/ja/blog/parallel-execution-approaches)と [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。移行するチームは、ポスターのピークの前にホットなトレースでコンフリクト率と p95 レイテンシを検証すべきです。 ## バリデータの視点：リプレイコストが分散化の予算 スループットのポスターはしばしばバリデータのリプレイコストを無視します。楽観的並列が多くの投機的パスと再実行を生むと、フルノードの CPU と帯域が増え、バリデータの要件がそれに追随します。これが実行側の分散化と性能の緊張です。設計は並列の高速化を求めつつ、正直なノードが許容できるコストで決定的にリプレイし状態ルートを検証できるようにすべきです。 したがって Bitroot 級のシステムを評価するには、リーダーのブロックレイテンシだけでなく、通常のフルノードの同期／検証の資源曲線、状態成長とシャーディング後のスナップショット／プルーニング戦略も問う必要があります。[分散化と性能](/ja/blog/decentralization-performance-tradeoff)を参照してください。読者別の経路は[誰が並列 EVM を読むべきか](/ja/blog/who-should-read-parallel-evm)を参照してください。 ## なぜ状態の成長と大きなオブジェクトの方針がアーキテクチャなのか 実行の並列化が CPU を広げた後は、履歴状態と大きなオブジェクト（長い calldata、メタデータ、証明ブロブ）がディスクと同期のボトルネックになります。オンチェーンハッシュを伴うオフチェーンのペイロードは一般的ですが、可用性の仮定、チャレンジ期間、ライトクライアント検証が必要です。そうでなければ「並列は速い」は空の状態のベンチマークにしか存在しません。 シャーディングはシャード間のレイテンシとアトミック性のセマンティクスを加え、開発者のメンタルモデルを変えます。展開については[マルチエンジン並列実行](/ja/blog/bitroot-evm)、地図のセルについては[ブロックチェーン・スケーリングマップ](/ja/blog/blockchain-scaling-map)を参照してください。 概要を一行で締めると、並列 EVM はコンセンサス、実行、状態の三層システムであり、一つだけを最適化して他を測らなければ実際のワークロードがそれを露呈します。パラメータは各専門記事を開いてください。ここですべてを探そうとしないでください。 ## この概要を読む際に持ち続ける三つの問い 輻輳下でもトランザクション順序は予測可能か。コンフリクトが増えたとき、スループットはゼロに崩壊せず、緩やかに劣化するか。フルノードのリプレイコストは、十分に分散したバリデータ集合を依然として許すか。アーキテクチャの物語は、テストネットの資料がこれらの条件付きで答えるときだけ成り立ちます。そうでなければ、モジュール名の一覧に留まります。 ## まとめ Bitroot の並列 EVM の骨格は、順序づけのためのパイプライン化されたコンセンサス、状態遷移のための楽観的並列、状態の規模のためのシャーディング、移行摩擦を下げるための EVM 互換性です。概要はここまでです。あるレイヤーの深さについては、一つの記事でコンセンサスの証明とスケジューラの擬似コードの両方を終わらせることを期待せず、対応する記事を開いてください。 ## 関連記事 - [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft) - [マルチエンジン並列実行](/ja/blog/bitroot-evm) - [楽観的並列化](/ja/blog/bitrootevm-)