--- id: 2 title: Bitroot マルチエンジン並列実行：スケジューリング、シャーディング、コンフリクト面 slug: bitroot-evm date: 2026/08/07 summary: マルチエンジン並列実行を深掘りします。エンジン間でトランザクションをどう共有するか、アクセスのために状態をどうシャーディングするか、楽観的並行性と三段階のコンフリクト検出が再実行をどう抑えるか、そしてテストネット条件下で高速化率とコンフリクト率をどう読むかを解説します。 keywords: マルチエンジン並列,EVM,状態シャーディング,コンフリクト検出,Bitroot heroImage: /cms-media/file/4In%20depth%20analysis%20of%20Bitroot.jpg --- 単一スレッド EVM のボトルネックは「Solidity が遅い」ことではありません。直列実行のセマンティクスと、共有状態におけるロックコンフリクトを置く場所がないことです。マルチエンジン並列はエンジニアリングの問いです。ブロックのトランザクションを実行コンテキストへどう分割し、コンフリクト時にブロック全体を破棄しないようにするか。業界の路線については[並列実行の三つの路線](/ja/blog/parallel-execution-approaches)を参照してください。本稿は Bitroot 側のマルチエンジン設計に焦点を当てます。理論の骨格は [OCC 入門](/ja/blog/optimistic-concurrency-control-intro)です。本稿はデータベースの四段階の話を繰り返しません。 ## 設計目標：並列だがリプレイ可能 マルチエンジン設計は通常、次を堅持します。 - エンジンごとに比較的独立した実行コンテキストを設け、グローバルロックを減らす。 - 状態をアカウントやストレージスロットで分割し、エンジンがローカルシャードを優先してエンジン間同期を削減する。 - スケジューラが事前解析とバッチ化を行い、関連するトランザクションを同じエンジンやバッチに保ち、往復を減らす。 - 最終コミットがコンセンサス順序の下での直列実行と等価であること（決定的リプレイ）。 コンセンサスがどう高速に順序を出すかについては [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft)、楽観的前提とロールバックについては[楽観的並列化](/ja/blog/bitrootevm-)、アーキテクチャの地図については[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)を参照してください。 ## スケジューリング：単純なラウンドロビンでは済まない 素朴なラウンドロビンは、ホットなコントラクトが現れるまでトランザクションを均等にばらまき、そこでエンジン同士が争います。より良いスケジューラは次を見積もります。 - 複雑さとガスの大きさ（粗く）。 - 触れる可能性が高い状態パーティション。 - 優先度とバッチ親和性（関連する tx をまとめてエンジン間同期を削減）。 スケジューリング自体にもコストがかかります。粗すぎる事前解析は誤ってグループ化し、細かすぎる解析は直列のボトルネックになります。よくある妥協は「静的なヒューリスティック＋実行時モニタリング」です。楽観的にグループ化し、コンフリクト検出で補正します。DeFi のホットスポットがなぜ並列性を貫くのかについては[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 ## 状態シャーディング：並列実行の次に来る壁 実行が並列化されると、単一の状態ツリーと単一マシンのメモリが依然としてスループットを制限します。シャーディングは状態空間を分割します。シャード内は並列、シャード間は明示的なメッセージか非同期コミットです。大きなオブジェクトはオフチェーンストレージに置きオンチェーンのハッシュと組み合わせ、フルノードの負荷を和らげます。シャーディングは無料ではありません。シャード間のアトミック性と開発者のメンタルロードが増えるため、そのルールはプロトコルに書き、アプリの運任せにしないこと。 シャード間でコンポーザブルな DeFi はしばしばストレステストになります。多くのプールに触れるルートは、書き込みコンフリクトにシャード間プロトコルのレイテンシを積み重ねます。プロダクトがその境界をどう認めるかについては [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 ## コンフリクト検出：影響範囲を縮小する 楽観的並列の代償はコンフリクトです。Bitroot の資料は三段階の検出を強調しています。 1. **実行前**：依存関係／読み書きのヒューリスティックにより、明らかなコンフリクトを同じ並列ウィンドウから排除します。 2. **実行中**：バージョンや読み書き集合の監視により、無効なパスを早期に中断します。 3. **実行後**：状態ルートの整合性チェックにより、見落としや実装バグを捕まえます。 目標はコンフリクトゼロではなく、コンフリクトが起きたときに選択的に再実行することです。Aptos の Block-STM 風の協調スケジューリングは同じ楽観的ファミリーに属し、実装の詳細が異なります。プロジェクト間で生のテスト TPS を単純比較しないでください。 ## 「エンジン数 ↔ TPS」曲線の読み方 テストでは、エンジンを増やすとまずほぼ線形に加速し、コンフリクト率の上昇とともに曲がることがよくあります。公開テストネットの数値は、より少ないエンジンで数千 TPS、より多くでピーク数万 TPS、さらに示された構成下でサブ秒の確認を挙げてきました。すべてハードウェア、コントラクトの構成、コンフリクトの仮定に依存します。これらはエンジニアリング上の観察であり、メインネットの SLA でも利回りの約束でもありません。実効並列度、コンフリクト率、再実行の割合、レイテンシのパーセンタイルを併せて読むことを好むべきです。用語集は[性能指標の用語集](/ja/blog/performance-metrics-glossary)です。 マルチエンジンが既存コントラクトに対して透過的であり続けるかは EVM 互換性（バイトコード、プリコンパイル、ツールチェーン）に依存します。[EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。バリデータのハードウェアと地理が並列の利得をどう取り戻すかについては[分散化と性能](/ja/blog/decentralization-performance-tradeoff)を参照してください。 ## コンセンサスに追随する マルチエンジンがどれほど速くても、コンセンサスの順序を消費します。実行がブロック生成に慢性的に遅れると、未確認の状態ビューが積み上がり、アプリは「ブロックは速いのに依存する tx／クエリは依然として遅い」と感じます。開示ではエンジンのピークだけでなく、実行の遅れと確認のパーセンタイルを示すべきです。Pipeline 側については [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft)、ポジショニングについては [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 アプリ開発者にとって、マルチエンジンは透過的であるべきです。「並列を宣言する」ための Solidity 構文は不要です。変えるべきは状態のレイアウトと相互作用のパターンです。グローバルなシングルトンカウンタを減らし、多くのユーザーが一つの共有スロットに書き込むことを減らします。そうでなければ、余分なエンジンは再実行でビジーループするだけです。互換性については [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)、読者像については[誰が並列 EVM を読むべきか](/ja/blog/who-should-read-parallel-evm)を参照してください。 ## キャッシュ、プリフェッチ、エンジン間通信の税 エンジン数のほかに、階層化キャッシュと状態プリフェッチがエンジンが実際に働くかを決めます。ローカルシャードのヒット率が高ければ並列性は CPU 幅に近づき、リモートスロットの頻繁な取得は通信の税の下で高速化を平坦にします。ガスだけを見てパーティション親和性を見ないスケジューラは、体系的にエンジン間トラフィックを生みます。 エンジン間の読み書きシェア、バージョンコンフリクトの件数、シャード間キューの深さを監視してください。これらの指標はエンジン数だけよりも実際の容量をよく追跡します。コンセンサス分離後、実行の追随が遅いことは確認から状態ルートまでの間隔の拡大として現れ、ユーザーは依然として「チェーンが遅くなった」と感じます。概要については[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)を参照してください。 ## コントラクト作者に見える影響 マルチエンジンは通常、Solidity の作者に対して透過的であるべきです。書き直さずにデプロイできます。間接的な影響は残ります。ブロック内の正確なタイミングや「同じブロックの後の tx は常に前の書き込みを見る」といった仮定は、投機的ウィンドウの下ではより脆くなります。文書化されていないスケジューラの偶然に頼らず、明示的なトランザクション境界とイベントに依存してください。 ツールチェーンは、トレース、ガスプロファイル、デバッガで再実行のパスを説明できなければなりません。そうでなければインシデントを再構成できません。読者別の経路は[誰が並列 EVM を読むべきか](/ja/blog/who-should-read-parallel-evm)、互換性は [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。 マルチエンジン設計は、コンフリクト率の曲線が与えられたときに高速化が説明可能か、再実行が観測可能か、レガシーコントラクトのセマンティクスが互換のままか、で評価すべきです。この三つがエンジニアリングとしての並列 EVM を作ります。デモ用のマルチスレッドインタプリタではありません。 ## 可観測性：指標がなければ並列性もない 本番のマルチエンジンには、エンジンごとの稼働率、シャード間メッセージ率、段階ごとのコンフリクトヒット、再実行の割合、コンセンサス順序から状態ルートまでの時間が必要です。これらの曲線がなければ、運用者は「TPS が落ちた」としか見えず、スケジューリング、ホットなコントラクト、状態 I/O を区別できません。可観測性は機能の一部として扱うべきであり、ローンチ後のダッシュボードの飾りではありません。 スケジューリング、シャーディング、コンフリクト検出はまとめて読む必要があります。可観測性のないエンジン追加は、同じ失敗をより速く繰り返すだけです。コンフリクト率の曲線を公開することは、ビルダーとバリデータに対する最低限の誠実さです。 テストネットの数値を公開するときは、エンジン数、負荷の構成、コンフリクト率を明記し、それらがメインネットの約束でも投資助言でもないことを述べてください。 ## まとめ マルチエンジン並列は「EVM を多数のコアで動かせるか」という問いを、スケジューリング、シャーディング、コンフリクト制御へと変えます。コンフリクトが少なく分割可能な負荷ではスループットを増幅し、AMM の共有プールのホットスポットではエンジンを増やしても直列へ崩れます。それはワークロードの問題であり、もう一つのマーケティング文句で消えるものではありません。 ## 関連記事 - [楽観的並列化](/ja/blog/bitrootevm-) - [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft) - [コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)