Ethereum executes one transaction after another, and that fact by itself isn't a flaw — it's a choice: trade the simplest possible execution order for the easiest possible determinism to verify. But once the industry started taking seriously the question of whether a public chain can actually hold up under real economic activity, almost every team trying to break past the single-threaded ceiling arrived at the same fork in the road: who decides whether two transactions can run at the same time — does the developer declare it up front, or does the system discover it at runtime?
This isn't a technical footnote. It's a routing decision that shapes an entire platform's developer experience, its compatibility boundary, and the ceiling on its real-world throughput. Over the past few years the industry has worn in three reasonably mature paths: deterministic parallelism, exemplified by Solana's Sealevel; optimistic concurrency control (OCC), exemplified by Aptos's Block-STM, Monad, and Sei; and an object-based model, exemplified by Sui. All three appear to be solving the same problem — how to run many transactions at once — but they differ substantially in what they demand of developers, how well they fit existing ecosystems, and how they actually perform under real load. Understanding this map is a prerequisite for understanding every engineering detail that follows in parallel EVM design.
Deterministic parallelism: pushing the burden onto developers
Solana's Sealevel runtime is the clearest example of this path. Per Solana's own documentation and multiple technical write-ups, every transaction submitted on-chain must explicitly declare the list of accounts it will read and write, and mark each one as read-only or writable. Once the runtime has that declaration, it can build a complete dependency graph before execution even starts: two transactions that share no writable account can be safely dispatched to different cores and run in parallel; two that only read the same account can be processed together within the same PoH entry; only when two transactions both want to write the same account do they need to queue up and run serially. Paired with Solana's Cloudbreak storage layer, this in principle allows lock-free parallel state access — the scheduler never has to guess at runtime who conflicts with whom, because the answer is already written into the transaction itself.
The appeal of this design is determinism: once a transaction is accepted, its execution path is predictable, and there's no wasted work from discovering a conflict halfway through and having to start over. But the cost lands just as directly, on developers. Every transaction has to enumerate its full account-access list before submission. That's no burden for a simple transfer, but for a contract with complex branching logic whose state-access path depends on runtime conditions, it forces a choice: over-declare conservatively, listing accounts that might not even end up being touched, or risk a transaction failing because something was left off the list. Worse, the EVM was never designed around this kind of pre-declaration — which storage slots a transaction touches typically depends on conditional logic inside the contract, and there's no way to know until the relevant line of code actually runs. This is a point multiple analysts keep returning to: forcing an access-list declaration onto EVM transactions breaks bytecode-level compatibility outright, forcing developers to rewrite contract logic just to fit a new chain.
Pre-declaration also hasn't delivered on the promise of eliminating conflicts in practice. A 2025 empirical study published on arXiv analyzed historical block data from Ethereum and Solana, comparing the two chains' transaction conflict patterns and theoretical parallelism ceilings. The results: the share of independent transactions in an Ethereum block exceeds 50% in over half of all blocks, while Solana's average conflict-chain length runs to roughly 58% of block size — far higher than Ethereum's roughly 18%. In other words, even though Solana requires developers to declare account access up front, real-world application traffic — especially DEXes, lending markets, and other high-frequency read/write patterns over shared state — still produces long chains of mutually dependent transactions. Pre-declaration solves the scheduling-time question of "do we know who conflicts with whom," not the application-level question of "does the state itself have hotspots." That points to a conclusion this series will keep coming back to: the real bottleneck on parallelism is often not the execution engine, but whether the contract's own design has spread state out enough to avoid contention.
Optimistic concurrency control: treating conflict as the exception
If the deterministic path front-loads complexity onto developers, optimistic concurrency control takes the opposite bet: assume most transactions don't conflict, run them in parallel immediately, and push validation and correction to after — or during — execution. The heaviest engineering example of this path is Aptos's Block-STM. According to the paper published by Aptos Labs and accepted at PPoPP 2023 (the 28th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming), Block-STM builds on software transactional memory (STM) combined with classic OCC: transactions are optimistically executed in parallel according to a pre-assigned order, and once execution finishes the system checks whether the data each transaction read was overwritten by a transaction earlier in that order — if so, it aborts and re-executes, converging toward a result equivalent to running everything serially. Unlike traditional OCC, Block-STM adds a low-overhead collaborative scheduler that discovers dependencies dynamically during execution and schedules re-execution as it goes, rather than waiting for an entire batch to finish before validating — which means it only has to roll back transactions that actually conflicted, without dragging down the whole batch. Benchmark numbers disclosed by Aptos and its technical blog posts show the engine processing over 160,000 non-trivial Move transactions per second in its environment.
This approach was later adopted across multiple EVM-compatible chains, and for a consistent reason: EVM bytecode carries no access list by nature, so achieving full bytecode compatibility rules out anything like Sealevel's requirement that developers pre-declare their read/write sets. Sei's V2 technical documentation states this explicitly: when a node receives an EVM transaction, nobody knows which storage slots it will ultimately touch — only actual execution reveals that — so forcing an access list onto EVM transactions is neither realistic nor compatible. Sei's answer is to flip the assumption: default to assuming transactions depend on each other, run them speculatively in parallel first, record the actual state each transaction touched, and if a conflict shows up, pull out only the conflicting subset and re-execute it in order, leaving the rest untouched. Sei's own blog calls V2 "the first parallelized EVM blockchain," and pairs this optimistic parallelism with fast Cosmos SDK-layer consensus to target throughput in the tens of thousands of TPS.
Monad takes a different engineering path to the same idea. According to Monad's own materials and multiple third-party technical breakdowns, its execution engine runs each transaction speculatively against a state snapshot, and a scheduler then commits results in canonical order; if two transactions touch the same state, whichever commits later re-executes based on the former's output. Because the actual conflict rate in most blocks is low, the large majority of transactions pass through on the first try. Monad also decouples execution from consensus: its MonadBFT consensus layer uses a pipelined design that can finalize a block in a single round under good network conditions, compressing block time to roughly 300 milliseconds, while execution catches up asynchronously in the background rather than gating the next round of consensus on execution results being ready. This "order first, execute later, converge asynchronously" architecture is philosophically close to Aptos's approach of validating against a pre-assigned order: once ordering is settled, it stays stable, and the execution layer's optimistic assumptions plus retry mechanism are left to guarantee correctness.
Nearly every team building on this path acknowledges the core risk: if real-world conflict rates run higher than expected, the waste from repeated execution eats into the gains parallelism was supposed to deliver. That's why, in any deeper discussion of Block-STM-style systems, "selective rollback" and "in-flight conflict detection" keep coming up — they're the key engineering levers for keeping the cost of a failed optimistic bet as low as possible, and this series will return to that mechanism in more depth later on.
The object model: rebuilding the ledger's data structure
Sui offers a third answer, and it works at the data-model layer rather than layering scheduling tricks onto an existing account model. Per Sui's own documentation, every asset on Sui is modeled as an object with a globally unique ID, and objects are split cleanly into two categories: owned objects and shared objects. An owned object can only be used in a transaction signed by its owner; because there's exactly one possible writer, such transactions can skip consensus ordering entirely and take a lower-latency "fast path" straight to finality. A shared object has no single owner — anyone can read or write it — so any transaction touching a shared object must go through consensus-layer ordering to arbitrate among its multiple potential writers.
This design reframes the parallelism problem as an object-ownership problem: the bulk of transfers and NFT holdings — assets that naturally have exactly one owner — can be processed in parallel without going through global ordering at all, and only scenarios that genuinely require multiple parties to read and write together, like a DEX liquidity pool or an auction contract, have to pay the cost of consensus ordering. There's academic tracking of this in practice too: a paper analyzing how shared objects are actually used in Sui smart contracts finds that although shared objects make up only a small fraction of all objects, they're the variable that determines whether an on-chain application actually captures the benefits of parallelism — hot shared objects still become contention points, which is, at its core, the same phenomenon as the long conflict chains that high-frequency trading produces on Solana, just wearing a different face.
Sui's cost is just as direct: it requires an entirely new smart contract language, Move, and a programming paradigm completely unlike the account model. That means the Solidity contracts already written across Ethereum's ecosystem, and the Foundry and Hardhat tooling developers already know well, can't simply be carried over — developers have to relearn both a mental model and a way of expressing asset ownership just to get the parallelism benefit. For an ecosystem as large and as path-dependent as the EVM's, that's a non-trivial migration cost.
Putting the three paths side by side: compatibility is the real dividing line
Laid out next to each other, the tradeoffs come into focus:
| Path | Representative project | When conflicts are handled | What it demands of developers | Effect on EVM compatibility |
|---|---|---|---|---|
| Deterministic parallelism | Solana Sealevel | Before execution, dependencies known in advance | Must explicitly declare account read/write sets | Incompatible with EVM bytecode semantics |
| Optimistic concurrency control | Aptos Block-STM, Monad, Sei | Validated during or after execution | No pre-declaration needed, close to "write and go" | Can preserve bytecode-level compatibility |
| Object model | Sui | Split into a fast path and a consensus path by object ownership | Requires a new language and object-based programming paradigm | Abandons the account model, incompatible with EVM |
There's a clear pattern behind this table: any project that treats full compatibility with Ethereum's existing contracts and tooling as a hard constraint will almost never pick deterministic declaration or the object model, because both require developers to change how they write contracts in the first place — one demands pre-declared dependencies, the other demands an entirely new language. What's left as a realistic option for such a project converges almost entirely on optimistic concurrency control: without changing EVM semantics or asking developers to declare anything extra, hand the entire job of discovering dependencies and resolving conflicts to the runtime. This isn't because OCC is inherently superior in theory — Solana's and Sui's respective ecosystems both prove the other two paths can hit very high throughput too — it's that once "bytecode compatibility" gets written into a product's positioning, the space of viable engineering choices narrows sharply.
Once this is clear, it becomes straightforward to see why Bitroot chose optimistic parallelism as the underlying paradigm for its execution engine, and why it layers transaction dependency analysis and three-phase conflict detection on top of that optimistic framework: this is what it looks like to push the optimistic path itself as far as it can go, under the constraint of "must be EVM-compatible." Exactly how optimistic concurrency control defines read/write sets, detects conflicts, and decides who gets rolled back are questions that need to start from classic database theory — and that's what the next piece in this series will cover.