並列実行は「より多くのコアをオンにすればスループットが上がる」と聞こえます。コンフリクトの少ないワークロードでは、その直感はおおむね正しいです。同じ状態スロットに決して触れないトランザクションは異なる実行エンジンが同時に消化でき、マルチコアの利用率が上がります。しかし実際にパブリックチェーンを輻輳させるトラフィックは、きれいなピアツーピア送金であることはまれです。同じホットなアカウントやストレージスロットを繰り返し読み書きするコントラクト呼び出しです。そのとき並列性はもはや CPU 数ではなく、コンフリクト率によって制限されます。
それが見えれば、どんな「並列 EVM」の性能数値も正しく読めます。同じエンジンでもワークロードによって桁違いになり得ます。
低コンフリクトと高コンフリクト：二つの異なるゲーム
低コンフリクトの負荷は、無関係な単純送金が多数、独立した NFT 保有者間の移動、異なるコントラクトインスタンスへの読み取り専用クエリのようなものです。読み書き集合がほとんど重ならないため、楽観的並列は「理想的な高速化」に近づけます。N 個のエンジンが、固定のスケジューリングとバージョン確認のコストを差し引いて、ほぼ N 倍のコンフリクトのない作業を消化します。
高コンフリクトの負荷は逆です。同じ AMM ペア、同じレンディングの金利インデックス、同じ NFT ミントのカウンタが、多くのトランザクションを小さな状態集合に詰め込みます。楽観的実行は依然として並列で先へ進みますが、検証がバージョンのコンフリクトを発見し、多くのトランザクションが直列順序でやり直されます。エンジンは忙しく見えるのに、実効スループットは単一スレッド水準へ崩れ、さらにロールバックと再実行のオーバーヘッドが加わります。
したがって「並列 EVM は速いか」は yes/no の問いではありません。「どのコンフリクト分布の下で、どれだけ速いか」です。
なぜ AMM、レンディング、NFT ミントがスループットを傷つけるのか
自動マーケットメーカーは流動性と価格を少数のプールコントラクトのストレージスロットに集中させます。同じブロック内の複数のスワップが同じ reserve や価格関連のスロットを読み書きすることが多く、コンフリクトは構造的です。ユーザーのアドレスが異なっても、コントラクト側のホットスポットだけで並列性を平坦にするのに十分です。
レンディングも同様です。金利インデックス、グローバルな借入総額、共有の清算パラメータがユーザーをまたぐ接点になります。「ユーザー A が預金する」トランザクションは、ユーザー B の借入やユーザー C の清算とグローバル変数を共有することがあります。
NFT ミントはより極端です。連番の ID、供給カウンタ、アローリストのビットマップは、短命なコンフリクトの下で一つの書き込み点になることがよくあります。イーサリアムの歴史的なミントラッシュがガスオークションを途方もない範囲へ押し上げたのは、「多くの人が来た」からだけでなく、実行レイヤーがそれらの密結合した書き込みを分割できなかったからです。
読み書き集合の粒度：コンフリクト率の隠れたつまみ
楽観的並列は読み書き集合を使い、二つのトランザクションがコンフリクトフリーかを判断します。集合はアカウントレベルほど粗くも、個々のストレージスロットほど細かくもできます。
- 粗い集合はコンフリクトを過剰報告します。同じコントラクトの異なるスロットに触れる二つのトランザクションが、それでも直列化されます。
- 細かい集合は解析とバージョン管理のコストを上げます。依存グラフが断片化しメタデータが増えますが、真の並列性も増えます。
エンジニアリングは通常、アカウントレベルのヒューリスティックとスロットレベルの精度をバランスさせ、実行前の静的依存分析、実行中のバージョン監視、実行後の状態ルートチェックを組み合わせます（楽観的並行制御（OCC）入門を参照）。アプリケーション開発者への含意は具体的です。無関係な状態をスロットごとに分割し、グローバルカウンタを減らし、単一のホットな totalSupply パスを避けることは、チェーンを乗り換えるよりも確認体験を改善することがよくあります。
ホットスポットでピーク TPS がどう劣化するか
ベンチマークは合成のコンフリクトフリー負荷を好みます。曲線が良く見えるからです。実際のブロックは混在しています。並列化する送金もあれば、ホットスポットで詰まる DeFi 呼び出しもあります。実効スループットはおおむね次に制約されます（例示であり、正確な式ではありません）。
実効スループット ≈ コンフリクトフリーの割合における並列利得＋コンフリクトする割合におけるほぼ直列のスループット − ロールバック／再実行コスト。
コンフリクトする割合が上がるにつれ、後ろの二項が支配的になります。これがよくあるマーケティングとエンジニアリングの食い違いを生みます。資料は「理想的な負荷でのピーク TPS」を引用し、ミント当日や市場の乱高下時にユーザーはより遅い確認とより多くのリトライを感じます。正直な開示は低コンフリクトと高コンフリクトの両方の数値を示し、ハードウェア、クライアントのバージョン、トランザクションの構成を明記します（性能指標の用語集を参照）。
コンポーザブル DeFi に正面から向き合うことを選ぶ楽観的並列 EVM チェーン——送金ベンチマークの最適化だけではない——は、コンフリクト検出と動的グループ化の品質が、ポスターのスループットとユーザーに見えるスループットの差になります。
コントラクトとプロトコル設計への実践的な含意
- ホットなスロットを見つける：監査中に高頻度の書き込みをマッピングします。グローバルカウンタ、単一の流動性プール、共有の設定ビットが第一容疑者です。
- 状態を分割する：可能な限りユーザー、プール、シャードごとに書き込みを分離し、一つのスロットに漏斗で集めないようにします。
- 暗黙の順序の仮定を捨てる：「暗黙の同一ブロック順序」に依存するロジックは楽観的並列の下でより脆くなります。順序を明示的にエンコードするか、設計をコンフリクト耐性にします。
- ベンチマークはコンフリクト率を通して解釈する：TPS の数値を見たら、まずトランザクションの構成を尋ねてください。コンフリクト分布のないピークは参照価値が限られます。
結び：並列性は無料の昼食ではない
並列 EVM が複数のコアを使うのは、ワークロードに十分なコンフリクトフリーのトランザクションが含まれるときだけです。ホットなコントラクトは実行エンジンが変わったからといって消えるわけではなく、ボトルネックを「単一スレッドのインタプリタ」から「コンフリクト検出と再実行」へ移します。それを説明することは、もう一つのエレベーターピッチより役に立ちます。開発者にはストレージのレイアウトを変えるべきかを伝え、読者には次の性能ポスターをどう疑うべきかを伝えます。