Over the past two years, parallel EVMs have become one of the most talked-about topics in the public-chain world. Monad, Sei, Aptos, and Bitroot are all telling the same story: transactions no longer execute one at a time in a queue — they run concurrently wherever possible, and conflicts get sorted out afterward. This sounds like something the blockchain industry invented from scratch, but a look at the database literature shows the skeleton of the idea was already worked out back in 1981.
That year, H. T. Kung and John T. Robinson of Cornell University published "On Optimistic Methods for Concurrency Control" in ACM Transactions on Database Systems, Volume 6, Issue 2, laying out a complete framework for optimistic concurrency control (OCC). Once you understand the logic of that paper, today's parallel EVM designs start to look like blockchain engineers re-deriving, under a new set of constraints, a problem the database world had already worked through more than four decades earlier. This piece tries to trace that lineage: what OCC originally solved, how it relates to pessimistic locking and MVCC, and exactly which extra constraints blockchains had to bolt on that the database world never had to worry about.
What that 1981 paper actually said
Kung and Robinson were staring at a very concrete problem: concurrency control traditionally relied on locking, but the overhead of maintaining lock tables, detecting deadlocks, and scheduling around them noticeably drags a system down as the number of transactions grows. Their counterintuitive proposal: if most transactions don't actually conflict with each other, you can simply let them run concurrently and push the work of checking for conflicts to the very end, instead of paying the cost of locking upfront for conflicts that might never happen. The original paper describes this approach as relying on transaction backup as its primary control mechanism — betting that conflicts won't occur, which is where the word "optimistic" comes from.
The concrete implementation unfolds across three phases. A transaction first enters the Read Phase, where it freely reads and writes data, but every write lands only in the transaction's private working copy, not yet reflected in the shared database. It then moves into the Validation Phase: on entering this phase the transaction is assigned a timestamp, against which the system checks whether its results still satisfy timestamp-ordered serializability — in other words, whether any data it read was modified by another, earlier-committing transaction sometime between when it read that data and when it entered validation. Only once validation passes does the Write Phase follow, merging the writes sitting in the private copy into the shared database. The paper further distinguishes serial validation from parallel validation: the former treats validation and writing as a single indivisible atomic operation, while the latter lets validation and writing happen concurrently for higher throughput, at the cost of needing extra machinery to preserve correctness.
The value of this framework isn't that it eliminates conflicts — it's that it moves conflict handling from "prevent before execution" to "check after execution." That shift in timing later became the common starting point for nearly every optimistic concurrency system that followed, including today's blockchain parallel execution engines.
Why pessimistic locking feels heavy
To understand why OCC is appealing, it helps to look at what it replaced. Two-phase locking (2PL) is the classic pessimistic concurrency-control mechanism in relational databases: a transaction must acquire a lock before touching data, and over its lifetime it only ever accumulates more locks (the growing phase) until it commits or rolls back and starts releasing them (the shrinking phase). Correctness is easy to prove under this scheme, but the cost is just as easy to see. The lock table itself has to be maintained, consuming memory and CPU time; if transactions request the same set of locks in different orders, deadlocks become possible, forcing the system to run deadlock detection or fall back on timeouts to force a transaction to give up; and the longer a long-running transaction holds its locks, the more other transactions pile up waiting behind it, dragging overall concurrency down.
OCC takes the opposite bet: don't lock anything upfront — gamble instead that most transactions' read/write sets don't actually overlap. When that bet pays off, the system skips the entire cost of acquiring, maintaining, and releasing locks, and throughput clearly beats the pessimistic approach. But the bet can also fail: if concurrent transactions frequently read and write the same data, a large number of them will fail validation and have to re-execute, and the wasted, duplicated work can end up costing more than the pessimistic approach ever would have. That's why OCC has carried the label "pays off more in low-contention settings" since it was first proposed — a judgment that still holds more than four decades later in the blockchain context, except "contention" now means "read/write-set conflicts between on-chain transactions."
MVCC: a related but distinct path
If you've ever paid attention to how PostgreSQL or Oracle handle concurrency, you've heard of multi-version concurrency control (MVCC). MVCC and OCC are often discussed together, but they attack the problem from different angles. MVCC's defining feature is that readers never block writers: the system keeps multiple versions of each piece of data, and a transaction gets a consistent snapshot at the moment it starts — no matter what other transactions do to the data afterward, it always sees the version that existed at that snapshot moment. PostgreSQL's concurrency model is built directly on this snapshot-isolation mechanism, so reads and writes almost never contend with each other.
Microsoft SQL Server's in-memory database engine, Hekaton, offers an example of combining MVCC and OCC. According to Microsoft Research's published technical material, Hekaton uses a timestamp-based variant of optimistic concurrency control layered on top of multi-version storage, and compiles specialized execution logic for each type of transaction through runtime code generation, cutting down the overhead of interpreted execution. Another frequently cited case is Silo, an in-memory database released by an MIT team in 2013, which validates using decentralized timestamps and deliberately avoids generating any shared-memory writes for read-only records, reducing cache-coherence traffic on multi-core hardware. The later TicToc system (proposed by Yu and Pavlo) pushed this further by making timestamp assignment something computed after the fact rather than assigned upfront, so concurrency is no longer bottlenecked by an ordering that was locked in too early. What these systems share is a recognition that plain pessimistic locking gets too expensive on multi-core, high-concurrency hardware, so they trade it for version management plus deferred validation to gain throughput — the specific way each one combines version control with validation logic is where they differ.
It's worth clearing up a point that's easy to conflate: OCC is about the validation logic — detecting conflicts and deciding whether to roll back — while MVCC is about how to store and expose multiple versions of data. The two aren't mutually exclusive; in practice, high-performance systems typically layer some form of version management together with some optimistic validation strategy, rather than choosing one over the other.
Blockchain borrowed the skeleton, but changed the rules of the game
Turning back to blockchain: in the paper "Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing" (arXiv:2203.06871), the Aptos team explicitly positions their parallel execution engine as a combination of software transactional memory (STM) and optimistic concurrency control: transactions are optimistically executed in parallel first, validated afterward, and any transaction whose validation surfaces a conflict is aborted and re-executed. This maps almost one-to-one onto Kung and Robinson's read phase, validation phase, and write phase.
But the Block-STM paper specifically calls out a key difference between the blockchain setting and general-purpose STM or database OCC: transactions on a blockchain already have a fixed global order handed to them by the consensus layer before execution even begins, and that order cannot change. Traditional database OCC typically doesn't assume any predetermined ordering between transactions — the validation phase has to dynamically work out who came first. Blockchain is the exact opposite: the order is fixed in advance, and the execution engine's job is to spread transactions across as many cores as possible without violating the causal relationships implied by that fixed order. The Aptos team calls this "turning the ordering curse into a performance blessing": because the order is already locked in, the system can use a collaborative scheduling mechanism where a transaction that fails validation only needs to re-execute around that specific read/write conflict, rather than handling arbitrarily-ordered transactions the way a general-purpose STM would. According to the benchmark data disclosed in the paper, Block-STM executes more than 160,000 non-trivial Move transactions per second under low contention, and still sustains over 80,000 per second under high contention, with overhead relative to fully serial execution never exceeding 30%. Whether these exact numbers hold up depends heavily on the hardware, contract types, and conflict rates used in testing, but they validate a directional conclusion: a predetermined transaction order really can be used to simplify validation logic that would otherwise be far more complex.
The constraint unique to blockchains: everyone has to replay the same answer
If you only look as far as "execute first, validate after, re-run on conflict," it's easy to mistake blockchain's parallel execution for a straight port of database OCC. There's actually one more requirement that has no counterpart in the database world: deterministic replay.
On a single-machine database, OCC only needs to guarantee serializability within that one database instance — different database instances never need to produce byte-for-byte identical execution traces for the same batch of transactions. Blockchain is nothing like that: a chain has hundreds or thousands of independent nodes, each of which receives the same consensus-determined transaction order and executes it independently, and every one of them must arrive at exactly the same final state. Any node that computes a different result causes a state fork — a far more serious problem than a performance hit. That means a parallel EVM's conflict-detection and re-execution logic can never introduce any non-deterministic behavior tied to thread-scheduling order, the system clock, or floating-point arithmetic — otherwise the same transaction could compute different results on different nodes or under different degrees of parallelism. Bitroot's own documentation describes a "three-phase conflict detection mechanism" and emphasizes state-root consistency checks, and both are, at bottom, in service of this determinism red line: dependency analysis before execution, real-time conflict monitoring during execution, and state-root verification after execution all stack together to guarantee that no matter how parallelism is scheduled or where re-execution happens, the state transition finally written to the block is identical to what you'd get by assuming transactions executed strictly in serial order.
This is also why engineering parallel execution for a blockchain is harder than database OCC: a database only has to guarantee one correctness standard — serializability. A blockchain has to guarantee serializability and bit-for-bit consistency across nodes and execution environments, and it has to do so under a Byzantine fault-tolerance assumption, preventing malicious validators from profiting by manipulating execution order or forging state roots. That's the root reason "determinism" gets emphasized so relentlessly in optimistic parallel EVM design.
From database intuition to on-chain engineering
Back to the original question: why use database OCC as a lens for understanding blockchain execution? Because that lineage saves engineers from repeating a lot of the same mistakes. How to define read/write sets, what exactly to check during validation, whether a conflict should trigger re-running the whole batch or just the affected transactions — the database field has spent decades working through these questions, and Silo, Hekaton, and TicToc each arrived at different trade-offs. The space of choices facing blockchain teams isn't fundamentally different; it just comes with one additional hard constraint — deterministic replay across the entire network — plus the extra premise that, in a Byzantine environment, no single execution result can be trusted on its own.
Once you understand where this three-phase model comes from, it becomes much easier to look at the conflict-detection details in Bitroot, Aptos, and Sei and tell which choices are engineering trade-offs versus which are just fundamentals the database literature already settled. The next piece turns the lens back to Bitroot itself, laying out concretely what problem it's trying to solve as a high-performance, optimistic-parallel-EVM Layer 1, and where its boundaries are.