Bitroot - Optimistic Concurrency Control (OCC) Primer: From Databases to On-Chain Execution

Parallel-EVM discussions keep recycling the same verbs: execute in parallel, check for conflicts, roll back and retry if needed. That sounds chain-native; the skeleton is from databases. In 1981, H. T. Kung and John T. Robinson published “On Optimistic Methods for Concurrency Control” in ACM TODS, turning “optimistic” into an analyzable concurrency method. Once that logic is clear, Block-STM or a parallel EVM engine looks far less mysterious.

This piece explains OCC’s bet and three phases through a database lens, separates it from pessimistic locking and MVCC, then lists constraints blockchains add when they borrow the skeleton. It is prerequisite material for why optimistic parallelism fits EVM-compatible routes — not a parameter manual for any one product.

What optimism is betting on

Traditional concurrency control leans on locks: acquire before access so nobody mutates what you are reading. Locks can prove correctness, but lock tables, deadlock detection, and long transactions holding locks all become visible overhead under high concurrency. OCC’s counterintuitive proposal: if most transactions’ read/write sets do not overlap, let them run first and postpone conflict checks until just before commit, avoiding lock costs for conflicts that may never happen. The paper treats backup as the primary control — “optimistic” means hoping contention is sparse.

That does not deny conflicts; it moves when they are handled — from prevent-before-execute to validate-near-commit. Once timing shifts, the design bottleneck moves from “how to lock finely” to “how to detect cheaply and how to shrink redo.”

Read, validate, write: the three-phase skeleton

Classic OCC splits a transaction into three phases.

Read phase: the transaction freely reads the database; writes land only in a private workspace and do not immediately pollute shared state. To observers, unverified side effects are invisible or only isolation-visible.

Validation phase: the transaction receives a timestamp or sequence number; the system checks whether its read set is still valid — whether data was overwritten after the read by another transaction that should precede it in order. If the read set is stale, validation fails and the transaction aborts and retries. Validation is really about serializability: can the parallel interleaving equal some serial order?

Write phase: after validation passes, merge the private write set into the shared database. The paper also distinguishes serial validation from parallel validation: the former binds validate-and-write into a stronger atomic step and is simpler; the latter allows more concurrency but needs extra machinery so commits do not contradict each other.

Mapped onto blockchain parallel execution, the correspondence is nearly one-to-one: transactions execute speculatively and collect read/write sets; validate against the block’s fixed order; committers apply state, failures re-execute along dependencies. Whether the name is STM, Block-STM, or “optimistic parallel EVM,” the skeleton is still OCC.

Why pessimistic locking feels heavy

Two-phase locking (2PL) is the classic pessimistic scheme in relational databases: a transaction only acquires more locks until it ends. Correctness is easy to argue; so is cost — lock memory, deadlocks, head-of-line blocking. Under low contention, 2PL’s “prevention tax” can exceed OCC’s occasional redo; under high contention, OCC’s redo storms can cost more than locks. OCC has therefore long been labeled “pays off more when contention is low.” On-chain, that translates to: when read/write sets inside a block barely overlap, optimistic parallelism wins; when everyone hits the same AMM pool, engineering must bound re-execution or the numbers look bad.

That is also why performance disclosures must name workload type and test conditions. Lab floods of unrelated transfers and peak mainnet DEX routes have totally different conflict structure; the same OCC engine can feel an order of magnitude apart.

MVCC: related, but a different knob

Multi-version concurrency control (MVCC) often appears beside OCC but answers a different question. MVCC lets readers see a consistent snapshot so readers do not block writers; the core is version storage and visibility rules. OCC’s core is what happens when validation fails. They compose: use versions to reduce read/write trampling, then optimistic validation to decide who wins write/write conflicts. Systems such as Hekaton, Silo, and TicToc show variants with timestamps, decentralized validation, and delayed sequence assignment — united by admitting that pure pessimistic locking is too expensive on multi-core hardware, and trading versioning plus deferred validation for throughput.

For on-chain engineers, the clarification helps when reading papers and docs: “we use MVCC” may only describe state representation; what usually decides parallel-EVM behavior is the validation rule and re-execution schedule — OCC-family questions.

Extra rules blockchains add

Database OCC usually assumes local retry and a client that can observe aborts. Blockchains add two hard constraints.

First, deterministic replay network-wide. Every honest node must reach the same final state for the same block. Optimistic execution may parallelize inside a node, but commits must converge to a state equivalent to the canonical order; “this machine submitted a different write set because of scheduler luck” is forbidden. Implementations therefore bake a preset order or canonical sequence into the protocol rather than letting thread scheduling become part of semantics.

Second, Byzantine environments. A single executor cannot be assumed honest. Nodes may lie, omit, or manufacture conflicts to slow others. Parallel engines therefore sit inside larger consensus and verification flows: consensus fixes order and the finality path; execution efficiently and deterministically computes the state root; light clients and full nodes rely on verifiable final state, not an intermediate optimistic guess.

In Block-STM-related work, the Aptos team places the engine in the STM and OCC tradition and stresses turning “ordering” from a curse into a performance condition: once order is given, parallelism only accelerates convergence to that order. The same reading fits parallel EVMs — EVM transactions already live in a world where blocks are ordered; OCC races for multi-core under that order rather than canceling order.

Read/write sets: simple abstractly, hard in engineering

Textbook read and write sets map in the EVM to balances, nonces, storage slots, and occasional log or refund side effects. Too coarse a key invents false conflicts and wastes parallelism; too fine raises tracking and validation cost. Dynamic jumps, external calls, and proxies make static pre-analysis incomplete — exactly why EVM struggles with deterministic pre-declaration and why runtime collection of read/write sets is the default.

Whether a conflict re-runs one transaction, its dependency closure, or a whole batch decides tail latency. Strong OCC implementations treat validation failure as an expected hot path, not an exception branch. Those details belong to concrete engines; this primer only builds judgment: when a parallel EVM claims high throughput, ask conflict-rate assumptions and re-execution policy before asking for the testnet or benchmark conditions.

From intuition to the next positioning piece

Reading blockchain execution through database OCC pulls the discussion from slogans back to checkable mechanisms: what is assumed, what validation checks, who pays failure cost. Bitroot and other optimistic parallel EVM projects rarely differ on “whether OCC” — they differ on how read/write sets are captured, how conflicts are layered, and whether consensus pipelines separately from execution. The next article focuses on Bitroot: which cell it occupies on the scaling map and among the three parallel paths, where its boundaries are, and which claims should stay labeled as engineering goals under test conditions.