---
id: 14
title: 楽観的並行制御（OCC）入門：データベースからオンチェーン実行へ
slug: optimistic-concurrency-control-intro
date: 2026/08/29
summary: 楽観的並行制御は 1981 年のデータベース研究に始まり、今日では多くの並列 EVM を支えています。本稿は読み取り–検証–書き込みのフェーズを説明し、OCC を悲観的ロックや MVCC と対比し、ブロックチェーンが追加する決定性とビザンチンの制約に名前をつけます。
keywords: 楽観的並行制御,OCC,読み書き集合,直列化可能性,並列EVM
heroImage: /images/community-bg.png
---

並列 EVM の議論は同じ動詞を繰り返します。並列に実行し、コンフリクトを確認し、必要ならロールバックして再試行する。チェーン固有に聞こえますが、骨格はデータベースから来ています。1981 年に H. T. Kung と John T. Robinson が ACM TODS に「On Optimistic Methods for Concurrency Control」を発表し、「楽観的」を分析可能な並行性の手法に変えました。その論理が明確になれば、Block-STM や並列 EVM エンジンはずっと謎めいて見えなくなります。

本稿は OCC の賭けと三つのフェーズをデータベースのレンズで説明し、悲観的ロックや MVCC から区別し、ブロックチェーンが骨格を借りるときに追加する制約を列挙します。楽観的並列がなぜ EVM 互換の路線に合うのかの前提資料であり、特定プロダクトのパラメータ解説ではありません。

## 楽観性が賭けているもの

伝統的な並行制御はロックに頼ります。アクセスの前に取得し、読んでいるものを誰も変更しないようにします。ロックは正しさを証明できますが、ロックテーブル、デッドロック検出、長いトランザクションがロックを保持し続けることは、高並行下で目に見えるオーバーヘッドになります。OCC の直感に反する提案はこうです。ほとんどのトランザクションの読み書き集合が重ならないなら、まず走らせ、コンフリクトの確認をコミット直前に先送りし、決して起きないかもしれないコンフリクトのロックコストを避ける。論文はバックアップを主要な制御として扱います。「楽観的」とは、コンフリクトが疎であることを願うという意味です。

これはコンフリクトを否定するものではなく、いつ扱うかを移すものです。実行前の予防から、コミット近くの検証へ。タイミングが移れば、設計上のボトルネックは「どう細かくロックするか」から「どう安く検出し、どうやり直しを縮小するか」へ移ります。

## 読み取り、検証、書き込み：三段階の骨格

古典的な OCC はトランザクションを三つのフェーズに分けます。

読み取りフェーズ：トランザクションはデータベースを自由に読み、書き込みはプライベートなワークスペースにのみ置かれ、共有状態をすぐには汚しません。観測者から見れば、未検証の副作用は不可視か、分離レベルの範囲でのみ可視です。

検証フェーズ：トランザクションはタイムスタンプかシーケンス番号を受け取り、システムはその読み取り集合が依然として有効か——読み取りの後に、順序上先行すべき別のトランザクションがデータを上書きしていないか——を確認します。読み取り集合が古ければ検証は失敗し、トランザクションは中断して再試行します。検証は実に直列化可能性の問題です。並列のインターリービングが何らかの直列順序と等価になり得るか。

書き込みフェーズ：検証を通過した後、プライベートな書き込み集合を共有データベースへマージします。論文は直列検証と並列検証も区別します。前者は検証と書き込みをより強い原子的なステップに束ね、単純です。後者はより多くの並行性を許しますが、コミットが互いに矛盾しないための追加の仕組みを必要とします。

ブロックチェーンの並列実行に対応づけると、対応はほぼ一対一です。トランザクションは投機的に実行され読み書き集合を集め、ブロックの固定順序に対して検証し、コミッタが状態を適用し、失敗は依存関係に沿って再実行されます。名前が STM でも Block-STM でも「楽観的並列 EVM」でも、骨格は依然として OCC です。

## なぜ悲観的ロックは重く感じるのか

二相ロック（2PL）はリレーショナルデータベースの古典的な悲観的方式です。トランザクションは終了するまでロックを増やすだけです。正しさは論じやすく、コストも同様です。ロックのメモリ、デッドロック、先頭詰まりです。低コンフリクトでは、2PL の「予防の税」が OCC の時々のやり直しを上回ることがあり、高コンフリクトでは OCC の再実行の嵐がロックより高くつくことがあります。したがって OCC は長く「コンフリクトが低いときにより報われる」とラベル付けされてきました。オンチェーンではこう訳されます。ブロック内の読み書き集合がほとんど重ならなければ楽観的並列が勝ち、全員が同じ AMM プールに当たれば、エンジニアリングは再実行を制限しなければ数値が悪く見えます。

だからこそ性能の開示はワークロードの種類とテスト条件を明記しなければなりません。無関係な送金のラボでの洪水と、メインネットの DEX ルートのピークでは、コンフリクトの構造がまったく異なります。同じ OCC エンジンでも桁違いに感じられます。

## MVCC：関連するが、別のつまみ

多版並行制御（MVCC）はしばしば OCC の隣に現れますが、別の問いに答えます。MVCC は読み手が一貫したスナップショットを見られるようにし、読み手が書き手をブロックしないようにします。核心はバージョンの保存と可視性の規則です。OCC の核心は検証が失敗したときに何が起きるかです。両者は組み合わせられます。バージョンで読み書きの踏みつけを減らし、楽観的検証で書き込み／書き込みのコンフリクトに誰が勝つかを決めます。Hekaton、Silo、TicToc などのシステムは、タイムスタンプ、分散検証、遅延したシーケンス割り当てを備えた変種を示します。共通するのは、純粋な悲観的ロックはマルチコアのハードウェアでは高すぎると認め、バージョン管理と遅延検証をスループットと引き換えにすることです。

オンチェーンのエンジニアにとって、この整理は論文やドキュメントを読むときに役立ちます。「MVCC を使っている」は状態の表現を説明しているだけかもしれません。並列 EVM の挙動を通常決めるのは検証のルールと再実行のスケジュールであり、OCC ファミリーの問いです。

## ブロックチェーンが追加する追加ルール

データベースの OCC は通常、ローカルな再試行と中断を観測できるクライアントを前提とします。ブロックチェーンは二つの厳しい制約を追加します。

第一に、ネットワーク全体での決定的リプレイ。すべての正直なノードが同じブロックに対して同じ最終状態に到達しなければなりません。楽観的実行はノード内で並列化しても、コミットは正規の順序と等価な状態へ収束しなければならず、「このマシンはスケジューラの運で別の書き込み集合を提出した」は禁じられます。そのため実装は、スレッドのスケジューリングがセマンティクスの一部になるのではなく、あらかじめ定めた順序や正規のシーケンスをプロトコルに焼き込みます。

第二に、ビザンチン環境。単一の実行者が正直であると仮定できません。ノードは嘘をつき、省略し、他人を遅くするためにコンフリクトを捏造することがあります。そのため並列エンジンはより大きなコンセンサスと検証の流れの内側に位置します。コンセンサスが順序と最終性のパスを定め、実行が効率的かつ決定的に状態ルートを計算し、ライトクライアントとフルノードは中間の楽観的な推測ではなく、検証可能な最終状態に依拠します。

Block-STM 関連の研究で、Aptos チームはエンジンを STM と OCC の伝統に位置づけ、「順序づけ」を呪いから性能条件へ変えることを強調します。順序が与えられれば、並列性はその順序への収束を加速するだけです。同じ読み方が並列 EVM にも当てはまります。EVM のトランザクションはすでにブロックが順序づけられる世界に生きています。OCC はその順序の下でマルチコアを競い、順序を打ち消すのではありません。

## 読み書き集合：抽象では単純、エンジニアリングでは困難

教科書的な読み取り集合と書き込み集合は、EVM では残高、nonce、ストレージスロット、ときにはログや返金の副作用に対応します。キーが粗すぎると偽のコンフリクトを生み並列性を浪費し、細かすぎると追跡と検証のコストが上がります。動的なジャンプ、外部呼び出し、プロキシは静的な事前解析を不完全にします。まさに EVM が決定論的な事前宣言に苦しみ、読み書き集合の実行時収集が既定となる理由です。

コンフリクトが一つのトランザクション、その依存関係の閉包、バッチ全体のどれを再実行するかが、テールレイテンシを決めます。強い OCC 実装は、検証の失敗を例外分岐ではなく、予期されるホットパスとして扱います。それらの詳細は具体的なエンジンに属します。本入門は判断力を作るだけです。並列 EVM が高いスループットを主張するときは、テストネットやベンチマークの条件を尋ねる前に、コンフリクト率の仮定と再実行の方針を尋ねてください。

## 直感から次のポジショニング記事へ

ブロックチェーンの実行をデータベースの OCC を通して読むと、議論はスローガンから検証可能な仕組みへ引き戻されます。何が仮定され、検証が何を確認し、失敗のコストを誰が払うのか。Bitroot と他の楽観的並列 EVM プロジェクトが異なるのは、「OCC かどうか」ではなく、読み書き集合をどう捕捉するか、コンフリクトをどう階層化するか、コンセンサスが実行と別にパイプライン化されるかどうかです。次の記事は Bitroot に焦点を当てます。スケーリングマップと三つの並列路線の中でどのセルを占め、境界がどこにあり、どの主張がテスト条件下のエンジニアリング目標としてラベル付けされ続けるべきか。

## 関連記事

- 前：[並列実行の三つの路線：決定論的スケジューリング、楽観的 OCC、オブジェクトモデル](/ja/blog/parallel-execution-approaches)
- 次：[Bitroot のポジショニング：楽観的並列 EVM Layer 1 の境界](/ja/blog/bitroot-positioning)
- 関連：[Bitroot の並列化 EVM 技術解説：楽観的並列化](/ja/blog/bitrootevm-)、[性能指標の用語集：TPS、BPS、確認レイテンシ、最終性、コンフリクト率](/ja/blog/performance-metrics-glossary)