---
id: 17
title: 並列 EVM について誰が読むべきか：コントラクト開発者・クライアントエンジニア・研究者のための三つの道
slug: who-should-read-parallel-evm
date: 2026/09/06
summary: コントラクト開発者、クライアントエンジニア、研究者が並列 EVM に関心を持つ理由はそれぞれ異なります。本記事は三つの読書経路を示し、このサイトにすでに公開されている記事だけを指すことで、各読者が何を読むべきか、何を飛ばしてよいかを判断できるようにします。
keywords: 並列 EVM,コントラクト開発,クライアントエンジニアリング,ブロックチェーン研究,読書ガイド
heroImage: /images/community-bg.png
---

「並列 EVM」は読者によって意味する問いが異なります。Solidity 開発者がまず気にするのは、コントラクトの挙動が黙って変わるかどうかです。クライアントとプロトコルのエンジニアは、スケジューラ、コンフリクト検出、状態ツリーがどうコアを使い切るかに関心を持ちます。研究者は、楽観的並列化に検証可能な正しさの限界があるのか、それともマーケティングがデータベース用語をまとっているだけなのかを問います。三つの関心はすべて妥当ですが、混ぜてしまうと、誰も満足できないほど曖昧な議論になりがちです。

そこで読者を分けるのが役立ちます。門を設けるためではなく、並列実行がアプリケーション、システム、理論にまたがることを認めるためです。三つすべてを喜ばせようとする一本の記事は、多くの場合どれも深めません。[EVM 互換とは実際に何を意味するのか](/ja/blog/evm-compatibility-explained)では互換性のエンジニアリング的な意味を扱いました。本記事は「次に何を読むか」を三つの実行可能な道に変えます。ここでは**すでに公開されている記事だけ**をリンクし、架空の続編や、開けない「シリーズ第 N 回」のような参照は使いません。

## 道1：コントラクト開発者 — 挙動は変わるのか、コードを変える必要があるのか

コントラクト作者にとって、並列化は Solidity の構文を変えません。変わるのは実行時のコンフリクトとリトライの体験です。単一スレッドの EVM では、ブロック内のトランザクションは順番に解釈され、最終状態はその順序に従います。楽観的並列化では、バッチが並行に投機実行され、検証で受け入れられるかロールバックされます。共有状態の少ない低頻度のコントラクトでは、通常は透過的な処理に見えます。同じストレージスロットを繰り返し触る AMM、レンディングプロトコル、NFT ミントではコンフリクト率が高くなります。確認は遅くなり、失敗したリトライが増え、同一ブロック内の暗黙の順序を前提とするロジックはより脆くなります。

推奨する順序：

1. [EVM 互換とは実際に何を意味するのか](/ja/blog/evm-compatibility-explained) — 移行にどのバイトコード、プリコンパイル、JSON-RPC、ツールチェーンの整合が重要かを確認する。
2. [楽観的並行制御（OCC）入門](/ja/blog/optimistic-concurrency-control-intro) — 「実行し、検証し、コンフリクト時にリトライする」直感と、なぜ最終状態がなお直列順序と一致すべきかを身につける。
3. [コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots) — AMM／レンディング／ミントのトラフィックがなぜスループットを損なうのか、ストレージ配置がどうコンフリクト率を左右するのかを見る。
4. 任意の深掘り：[Bitroot の楽観的並列化](/ja/blog/bitrootevm-)、[マルチエンジン並列実行の設計](/ja/blog/bitroot-evm) — 本番志向のエンジンがどう作業をまとめ、コンフリクトを検出するか。システムの細部を最初からすべて理解する必要はない。

実践的な結論：まずホットなスロットとグローバルカウンタを監査し、可能ならユーザーやプール単位で状態を分割し、「このブロックでは誰かが先に実行した」を暗黙の不変条件として符号化しないこと。ほとんどのコントラクトは並列化のためにビジネスロジックを書き換える必要はありませんが、コンフリクトの多いコントラクトはほぼ常に、コンフリクトに強いストレージと相互作用の設計を必要とします。既存の Solidity リポジトリを新しいチェーンに移すことが主な仕事なら、四層の互換性チェックリストのほうが、実行エンジンのソースを読むよりもローンチリスクを下げられることが多いです。

## 道2：クライアント／プロトコルエンジニア — スケジューリング、状態、コンセンサスはどう噛み合うか

この読者はノード内部をすでに知っています。問いはより難しくなります。依存グラフはどう構築されるのか、読み書き集合はアカウント単位かスロット単位か、エンジンプールはどうスケールするのか、コンフリクトの再実行はどうライブロックを避けるのか、コンセンサスの提案と実行のパイプラインはどう互いをブロックせず分離するのか。ボトルネックの歴史的な文脈は[単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck)、設計上の分岐は[並列実行の三つの路線](/ja/blog/parallel-execution-approaches)にあります。

推奨する順序：

1. [単一スレッド EVM のボトルネック](/ja/blog/evm-single-thread-bottleneck) — 「遅さ」をコンセンサス間隔だけでなく直列解釈の中に位置づける。
2. [ブロックチェーン・スケーリングマップ](/ja/blog/blockchain-scaling-map) — 並列実行をロールアップ、シャーディング、モジュラースタックの中に置き、実行レイヤーの勝利をスケーリング全体の答えと誤解しない。
3. [並列実行の三つの路線](/ja/blog/parallel-execution-approaches)と[OCC 入門](/ja/blog/optimistic-concurrency-control-intro) — 決定論的な宣言、オブジェクトモデル、楽観的経路がそれぞれどこに複雑性を置くかを見る。
4. [Pipeline BFT とマルチエンジンの相乗効果](/ja/blog/bitroot-pipeline-bft)、[マルチエンジン並列実行の設計](/ja/blog/bitroot-evm) — 具体的なコンセンサス–実行分離とマルチエンジン設計を比較し、トレードオフがコードの形をした選択にどう落ちるかを見る。
5. 数値を信じる前に：[性能指標の用語集](/ja/blog/performance-metrics-glossary)。ハードウェアと集合サイズを秤にかけるとき：[分散化と性能のトレードオフ](/ja/blog/decentralization-performance-tradeoff)。
6. 実負荷で期待値を調整する：[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)。

実践的な結論：「スループット」をスケジューリング効率、コンフリクト再実行コスト、状態の読み書き増幅、コンセンサスメッセージングコストに分解し、それぞれを測定すること。コンフリクト分布とハードウェアの開示なしに理想負荷のピークだけを引用するベンチマークは、クライアント最適化にとって価値が限られます。実装では、コンフリクトの定義、再実行ポリシー、可観測性の指標を設定可能かつエクスポート可能にしてください。そうでなければ本番で見えるのは「遅くなった」という事実だけで、理由は見えません。

## 道3：研究者 — 正しさの限界、モデル比較、反証可能な主張

研究者がもう一つの製品ブリーフを必要とすることはほとんどありません。必要なのは反証可能な問いです。コミットされた結果はブロック順序に対して直列化可能か。近似的な読み書き集合（アカウント単位かスロット単位か）は安全性と性能にどう影響するか。どのコンフリクトグラフの下で高速化は 1 に崩壊するか。Block-STM 系の方式、決定論的並列化、オブジェクトモデルに対して、それぞれの前提は何か。

推奨する順序：

1. [並列実行の三つの路線](/ja/blog/parallel-execution-approaches) — あるプロジェクトの実装に踏み込む前に比較の枠組みを固める。
2. [OCC 入門](/ja/blog/optimistic-concurrency-control-intro) — ブロックチェーンの実行を古典的なデータベース並行性の語彙（読み書き集合、検証、再実行）に写像する。
3. [コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots) — 送金だけのベンチマークではなく、実際のコントラクトの形からコンフリクトグラフの直感を養う。
4. [性能指標の用語集](/ja/blog/performance-metrics-glossary) — TPS／レイテンシ／最終性／コンフリクト率の定義を統一し、論文風の数値とマーケティング風の数値を混ぜない。
5. [分散化と性能のトレードオフ](/ja/blog/decentralization-performance-tradeoff) — 「より速い」をバリデータ要件、地理、クライアント多様性といった観測可能な次元に戻す。
6. 任意のシステム的文脈：[ブロックチェーン・スケーリングマップ](/ja/blog/blockchain-scaling-map)、[Bitroot のポジショニング](/ja/blog/bitroot-positioning)、[Pipeline BFT とマルチエンジンの相乗効果](/ja/blog/bitroot-pipeline-bft)。

実践的な結論：性能や正しさの主張には、ワークロードの記述、コンフリクトの定義、失敗／再実行ポリシーを添付するよう求めること。それらを欠いた「並列 EVM は速い」には、研究としての価値はほぼありません。主張を再現可能な実験設計（ハードウェア、クライアント、トランザクション生成器、コンフリクト注入）として書くことは、形容詞を論じ合うよりも、研究とエンジニアリングの共通言語に近づきます。

## 比較表：役割別にたどる

| 読者 | 中心の問い | 優先して読むもの（公開済み記事のみ） |
|------|----------|-----------------------------------------------|
| コントラクト開発者 | 挙動は変わるか、ホットなストレージをどう避けるか | 互換性 → OCC 入門 → コンフリクトのホットスポット。任意で Bitroot の実行系記事 |
| クライアント／プロトコルエンジニア | スケジューリング、状態、コンセンサスをどう実装し測定するか | 単一スレッドのボトルネック → スケーリングマップ → 三つの路線／OCC → Pipeline BFT／マルチエンジン → 性能用語集と分散化の緊張 → コンフリクトのホットスポット |
| 研究者 | 正しさの限界、モデル比較、反証可能な指標 | 三つの路線 → OCC → コンフリクトのホットスポット → 性能用語集 → 分散化の緊張。任意でポジショニングと Pipeline BFT |

共通の土台としては、サイトの読書チェーンをたどってください。ポジショニング → 互換性 → 本ガイド → 性能指標の用語集 → 分散化の緊張 → コンフリクトのホットスポット。三つの役割別の道はこの背骨からの分岐であり、開けない第二の目次ではありません。共通の土台の後は、上の表に従って深掘りするほうが、最初からすべての長い技術記事を読もうとするより通常は時間を節約できます。

## 関連記事

- 前：[EVM 互換とは実際に何を意味するのか：バイトコード、プリコンパイル、JSON-RPC、ツールチェーン](/ja/blog/evm-compatibility-explained)
- 次：[性能指標の用語集：TPS、BPS、確認レイテンシ、最終性、コンフリクト率](/ja/blog/performance-metrics-glossary)