単一スレッドの EVM は決定性を比較的安く買います。固定順序と単純なリプレイです。目標が「検証可能な正しさを壊さずに実行の幅を上げる」になると、設計者は同じ分岐に直面します。二つのトランザクションが一緒に走ってよいかを誰が決めるのか——開発者が事前に決めるか、ランタイムが後で決めるか。
その選択がプログラミングモデル、移行コスト、ホットなコンフリクト下での実スループットを形作ります。業界は比較的明確な三つの路線を歩んできました。Solana の Sealevel に代表される決定論的並列、Aptos の Block-STM と複数の並列 EVM に代表される楽観的並行制御（OCC）、そして Sui に代表されるオブジェクトモデルです。三つとも「並列化」しますが、前提とコストは大きく異なります。
決定論的並列：依存関係をトランザクションに書く
決定論的な路線は、各トランザクションが読み書きするアカウント（またはリソース）の完全なリストを、読み取り専用か書き込み可能かの印付きで運ぶことを要求します。実行前にランタイムはグラフを構築できます。書き込みのコンフリクトがなければ並列安全、共有された読み取りは同時スケジュール可能、共有された書き込みは直列化です。スケジューラは実行中に依存関係を推測する必要がなく、コンフリクトの構造はエンキュー時にほぼ判明しています。Solana の Sealevel は最も引用されるエンジニアリングの実例であり、そのアカウントモデルとランタイムストレージに密結合しています。
利点は予測可能性です。一度受け入れられれば、実行パスは「途中でコンフリクトを発見して試行全体を中断する」無駄な作業を減らします。コストは開発者とツールチェーンに載ります。単純な送金は宣言が安く済みますが、アクセスパスが実行時の条件に依存する複雑な分岐を持つプログラムは、過剰に宣言するか（並列性を縮める）、過少に宣言するか（トランザクションが失敗する）のどちらかです。古典的な EVM のストレージスロットアクセスは、しばしばコントラクト内の条件で決まります。バイトコードは Sealevel 風のアカウントリストを運びません。事前宣言を強制すれば、バイトコードレベルの互換性は即座に壊れ、コントラクトと監査の前提を書き直す必要があります。
事前宣言はアプリケーションのホットスポットも消しません。DEX プール、清算、ホットなミントは依然として書き込みを少数のアカウントに集中させ、コンフリクトの連鎖が長くなります。並列性はスケジューラではなく状態の設計によって制限されます。決定性が解決するのは「スケジュール時に依存関係が分かるか」であり、「状態が分散されているか」ではありません。ワークロードがどうホットスポットを作るかは別の記事に属しますが、ここで注意すべきは、全員が同じスロットを争うコントラクト構造を救うエンジンはないということです。
楽観的並行制御：並列と仮定し、誤りで収束する
OCC は賭けを反転させます。ほとんどのトランザクションは衝突しないので、まず並列に走らせ、読み取り集合が依然として有効かを検証します。コンフリクト時は正規の順序で中断・再実行し、結果がある直列順序と一致するまで続けます。ソフトウェアトランザクショナルメモリ（STM）とデータベースの OCC が理論の骨格を供給します。Aptos の Block-STM は広く引用されるブロックチェーンの実例です。あらかじめ定めた順序の下での楽観的実行で、実行中に依存関係を発見して作業を再実行する協調スケジューリングにより、真に影響を受けたトランザクションだけをロールバックすることを狙います。
公開資料の高い TPS の数値は通常、特定のベンチマーク、ハードウェア、トランザクションの構成（例えばラボやテスト環境での非自明な Move トランザクション）から来ます。メインネットの混合負荷の UX と互換ではありません。重要なのは仕組みの形です。正しさは「最終的に与えられた順序と等価になる」ことに依存し、性能は「コンフリクト率が十分低いか、再実行が十分安いか」に依存します。
複数の EVM 互換チェーンが OCC を選ぶ理由は一貫しています。受信時点ではすべてのストレージアクセスを静的に知ることはできず、実行だけがそれを明らかにします。ランタイムが実際の読み書き集合を記録し、コンフリクトする部分集合は直列に収束し、残りは並列の利得を保ちます。Monad、Sei などはスナップショット、コミット順序、コンセンサスが実行から分離するかどうかで異なりますが、「開発者の事前宣言なし」を互換性の前提として共有します。
OCC の核心的なリスクも同じくらい公的です。コンフリクト率が急上昇すると、再実行が並列の余剰を食いつぶし、極端には素朴な直列＋ロック戦略に近づくか下回ることがあります。選択的なロールバック、実行中の検出、バッチ化、読み書き集合の粒度が、楽観的な賭けが外れたときのテールコストを決めます。次の記事はデータベースの視点から OCC の読み取り–検証–書き込みのフェーズを説明します。
オブジェクトモデル：台帳の形を変えて並列の境界を変える
第三の路線はアカウントモデルにパッチを当てるのではなく、台帳の構造を変えます。Sui は資産を一意の ID を持つオブジェクトとしてモデル化し、所有オブジェクトと共有オブジェクトに分けます。所有オブジェクトは単一の書き手を持ち、関連するトランザクションはグローバルな順序づけの必要性が弱い、より低レイテンシなパスを取れます。共有オブジェクトは多くの接触者を許し、コンセンサスを通じて順序づけられなければなりません。並列性は所有権の問題になります。自然に単一所有者のフローはスケールアウトし、真に複数当事者の共有状態はグローバルな順序づけの代価を払います。
このモデルは NFT やピアツーピアの資産移動に優しいです。AMM プール、グローバルなオークション、その他の共有オブジェクト重視のアプリは依然としてホットなコンフリクトに当たります——アカウントスロットの粒度ではなくオブジェクトの粒度で。コストはパラダイムと言語の移行です。Move とオブジェクト所有権は Solidity のアカウントモデルとは異なります。既存のイーサリアムのコントラクトと Foundry／Hardhat のワークフローは「そのまま持ち上げて移す」ことはできず、エコシステムは並列性のために学習と監査のコストを払います。
オブジェクトモデルは、実行の並列性が「宣言」か「楽観的」なスケジューリングだけではないことを証明します。状態のトポロジーももう一つのレバーです。また EVM 互換の路線にこう思い出させます。アカウントとグローバル状態を保つことは、オブジェクトモデルが買う構造的な並列性の一部を諦めることを意味し、ランタイムのスケジューリングがより多くの負荷を担う必要があります。
三つの路線の比較
| 次元 | 決定論的（Sealevel 風） | 楽観的 OCC（Block-STM 風） | オブジェクトモデル（Sui 風） |
|---|---|---|---|
| 依存関係が分かる時期 | 送信前に宣言 | 実行中／実行後に発見 | オブジェクト所有権から導出 |
| 開発者の負担 | 高い（アクセスリスト） | 低い（慣れたコントラクトスタイルを保つ） | 高い（新しいモデル／言語） |
| 古典的 EVM との相性 | 難しい（セマンティクスの衝突） | 比較的実現可能 | 移行が必要 |
| 主な失敗モード | 過剰／過少宣言、ホットスポットは依然直列化 | 高コンフリクトの再実行の嵐 | 共有オブジェクトのホットスポット、エコシステムの移行 |
パターンは明確です。厳しいプロダクトの制約が既存のイーサリアムのコントラクトとツールとのバイトコードレベルの互換性であるなら、決定論的な事前宣言とオブジェクトモデルはどちらも書き直しかスタックの変更を強制するため、実際の選択肢はしばしば OCC に収束します。それは OCC がすべての負荷で理論的に最良だという主張ではありません——決定論的とオブジェクトの路線はそれぞれのエコシステムで強いスループットを示しています——互換性が設計空間を圧縮するという認識です。
楽観的並列 EVM として位置づけられる L1 にとって、OCC の選択は制約下での収束であり、スローガンではありません。本当のエンジニアリングの問いは、読み書き集合をどう定義するか、コンフリクトをどれだけ早く検出するか、ホットな負荷下で再実行をどう制限するかになります。それらは OCC のデータベースとしての直感と、ワークロードのホットスポットの正直な評価に依拠します。