--- id: 1 title: Bitroot の楽観的並列化：検出、再実行、決定性 slug: bitrootevm- date: 2026/08/09 summary: EVM 上で楽観的並列化がどう機能するか。開発者が宣言する読み書き集合がなぜ使えないのか、三段階のコンフリクト検出がどうロールバックを縮小するのか、そして決定的リプレイがブロックチェーンの OCC がデータベースに対して追加で負う制約である理由を解説します。 keywords: 楽観的並列化,OCC,コンフリクト検出,並列EVM,Bitroot heroImage: /cms-media/file/2Deep%20analysis%20of%202Bitroot%20parallelized%20EVM%20technology.jpg --- 楽観的並列化を一行で言えば、ほとんどのトランザクションは衝突しないと仮定して並列に走らせ、読み書きのコンフリクトが起きたら固定順序でやり直し、結果が直列実行と一致するまで続ける、というものです。「高速化の魔法」ではなく、コンフリクト処理を予防から検出と回復へ移すものです。EVM がアカウントのアクセスリストを強制できないとき、これはバイトコード互換性を保つほぼ主要な道です。理論は [OCC 入門](/ja/blog/optimistic-concurrency-control-intro)、路線は[並列実行の三つの路線](/ja/blog/parallel-execution-approaches)、アーキテクチャ内の位置づけは[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)と [Bitroot のポジショニング](/ja/blog/bitroot-positioning)を参照してください。 ## なぜ EVM は決定論的な事前宣言に抵抗するのか Solana の Sealevel は、スケジューラが実行前にグラフを構築できるよう、宣言されたアカウントリストを要求します。EVM のトランザクションが触れるストレージスロットは、条件分岐の後に初めて現れることがよくあります。アクセスリストを強制すると、多くの既存コントラクトとツールチェーンの前提が壊れます。そのため Bitroot のようなプロジェクトは互換性を優先し、コンフリクトをランタイムに委ねます。互換性の境界は [EVM 互換とは何を意味するのか](/ja/blog/evm-compatibility-explained)を参照してください。 代償は、高いコンフリクト率が再実行によって並列の配当を食いつぶすことです。それは「バグのある実装」ではなく、楽観的手法に固有の曲線であり、特にホットなコントラクトで顕著です。[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 ## 三段階のコンフリクト検出が行うこと Bitroot の資料は責務によって三つの段階を説明しています（具体的なアルゴリズムはノード実装に従います）。 1. **実行前 — 静的／ヒューリスティックな依存関係分析** 履歴パターン、静的解析、粗い読み書きの見積もりを使い、明らかなコンフリクトを同じ並列ウィンドウから排除します。 2. **実行中 — バージョンまたは読み書き集合の監視** トランザクションはプライベートなビュー上で実行されます。ある読み取りバージョンがより早い順序のトランザクションによってすでに書き込まれていれば、無駄な作業を完了させる前に早期中断します。 3. **実行後 — 状態ルート／直列化可能性のチェック** コミット候補の整合性を確認し、並列結果の統合が正規の直列セマンティクスと一致するようにして、見落としと実装バグを捕まえます。 一括処理を最後に一度検証する素朴な OCC に対して、階層化された検出は**より早く、より小さな再実行集合で失敗する**ことを狙います。これは Block-STM の協調スケジューリングと同じ問題群を共有しますが、スケジューラも中断の粒度も同一ではありません。コンフリクト率の曲線をマーケティング上の倍率で置き換えないでください。 ## ロールバックと再実行：ブロック全体ではなく選択的 効率的な実装は通常、影響を受けるトランザクションとその依存関係の閉包だけを再実行し、ブロック内のすべてのトランザクションを再実行しません。コンセンサス順序は依然として拘束します。スループットのために黙って並べ替えることはできません。順序を先に、収束を後に、については [Pipeline BFT と実行の分離](/ja/blog/bitroot-pipeline-bft)を参照してください。マルチエンジンがどう並列ウィンドウを担うかについては[マルチエンジン並列実行](/ja/blog/bitroot-evm)を参照してください。 エージェントや高頻度決済にとって、これは次を意味します。コンフリクトが少なければ確認は予測可能になり得ますが、ホットなプールでは再実行の増加を覚悟すべきです。「並列＝常に高速」と仮定しないでください。スタック内の文脈は[分散型 AI スタック](/ja/blog/aibitrootweb3ai)を参照してください。 ## 決定性：ブロックチェーンの OCC が追加で必要とする層 単一ノードのデータベース OCC は、そのインスタンス上での直列化可能性だけを必要とします。オンチェーンでは、すべての正直なノードが独立に同じ状態を計算しなければなりません。したがって、スレッドのスケジューリング順序、ローカルクロック、不安定な浮動小数点など、非決定性への依存を禁じます。並列性が変わっても、正規の結果は一意でなければなりません。これは安全性の性質であり、性能の隠しボーナスではありません。 ## 仲間のアプローチとの比較（控えめに） | 路線 | 核となる考え方 | レガシー EVM | |-------|----------------|------------| | 決定論的宣言 | 実行前に依存関係が判明 | 高い移行コスト | | オブジェクトモデル | オブジェクト所有権で分離 | 新しい言語／パラダイム | | 楽観的 OCC | 実行時に検出＋再実行 | バイトコード互換性に最も近い | 「古典的 EVM に対して数倍のスループット」という公開主張は、特定の負荷とテストネット条件下でのエンジニアリング上の観察として読むべきであり、高コンフリクト下では倍率は縮みます。読み方の手引きは[性能指標の用語集](/ja/blog/performance-metrics-glossary)、バリデータの閾値が利用可能な並列性をどう制限するかについては[分散化と性能](/ja/blog/decentralization-performance-tradeoff)を参照してください。これは投資助言ではありません。 ## ピーク倍率よりコンフリクト曲線 ラボでの「直列 EVM に対して N 倍」は通常、コンフリクトの少ない合成負荷に対応します。同じエンジンでも共有プールのホットスポットでは倍率が急速に縮みます。単一の倍率よりも、コンフリクト–スループット曲線、再実行の割合、p95 レイテンシを優先してください。ホットスポットの解剖は[並列 EVM のワークロードとホットスポット](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 クライアントの詳細は異なりますが、評価チェックリストは共有できます。読み書き集合の粒度（アカウントかスロットか）、中断が即座に再実行されるかキューに入るか、検証が並列か、並列統合後に状態ルートをどう確定するか。チェックリストが具体的であるほど、「三段階」を手を振って説明することは難しくなります。データベースとしての系譜は [OCC 入門](/ja/blog/optimistic-concurrency-control-intro)、アーキテクチャは[並列 EVM アーキテクチャ概要](/ja/blog/bitrootevm)を参照してください。 ## コンフリクト率の曲線とエンジニアリングのつまみ 重要なつまみは「エンジンは常に多い方がよい」ではなく、並列ウィンドウの幅、中断ポリシー、再実行の優先度、ヒューリスティック分析の保守性です。ウィンドウが広すぎるとコンフリクトの連鎖が長くなり、狭すぎると直列実行に近づきます。ヒューリスティックが保守的すぎるとスループットが頭打ちになり、攻撃的すぎると再実行の嵐を招きます。 公開テストは、コンフリクトなしのベースライン、中程度の合成コンフリクト負荷、AMM に近いホットスポットのストレス負荷を報告すべきです。最初の数値だけを公開すると、楽観的な仮定が成り立つときの上限を示すことになります。用語集は[性能指標の用語集](/ja/blog/performance-metrics-glossary)、ワークロードの分類は[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)を参照してください。 ## ブロックチェーンの OCC とデータベースの OCC——再び データベースはプライマリでコミットしてからレプリケートできますが、チェーンではすべての正直なレプリカが独立に同じルートへ収束する必要があります。「ほぼ直列化可能」では不十分で、決定性が必須です。浮動小数点のモデル出力、ローカルのエントロピー、順序のない並列リダクションは、正規の状態遷移に入ってはなりません。それらはオフチェーンに留め、証明や集約署名でアンカーできます。 だからこそ AI の推論を直接コンセンサスへ流すべきではありません。確率的な出力は決定的リプレイと衝突します。パターンはオフチェーン計算、オンチェーン決済、任意の証明です。[分散型 AI スタック](/ja/blog/aibitrootweb3ai)、[トラステッドコンピューティング・フレームワーク](/ja/blog/trusted-computing-framework)を参照してください。 楽観的並列化の教育的価値は、「速い」を測定可能なコンフリクト率と再実行の割合に翻訳することにあります。その翻訳を保てば、次のより大きな TPS ポスターを無批判に信じることは難しくなります。実装の詳細は依然としてクライアントのコードと監査に従います。 ## 正しさのテスト（概念的） スループットのベンチマークを超えて、次のことが重要です。同じバッチが並列度の異なるレベルで一つの状態ルートを生むこと。注入された読み書きコンフリクトが依然として直列と等価な結果へ収束すること。クラッシュリカバリのリプレイがフォークを生まないこと。ファズされたランダムフローが並列モードと直列モードで一致すること。これらに合格することは、もう一つのピーク TPS の主張よりも、エンジニアリングされた楽観的並列化について多くを語ります。 検出、再実行、決定性は楽観的並列の三角形を成します。検出がなければロールバックが遅れ、選択的な再実行がなければスループットが崩れ、決定性がなければ安全性モデルが破綻します。三つが揃って初めて、TPS の数値は自らを説明します。 高速化はコンフリクト率と再実行の割合と併せて公開し、孤立したピークを避けてください。投資助言ではありません。 具体的なアルゴリズムはノード実装と監査に従います。本稿は仕組みの直感を築くだけです。 ## まとめ 楽観的並列化により、Bitroot は開発者にアクセスパターンの書き直しを強いることなくマルチコアの利得を引き出せます。その上限はホワイトペーパーの形容詞ではなく、コンフリクト率と再実行の効率によって決まります。検出の層と決定性の制約を理解することは、どんな TPS の数値を暗記するよりも役に立ちます。 ## 関連記事 - [OCC 入門](/ja/blog/optimistic-concurrency-control-intro) - [マルチエンジン並列実行](/ja/blog/bitroot-evm) - [並列実行の三つの路線](/ja/blog/parallel-execution-approaches)