A single-threaded EVM buys determinism relatively cheaply: fixed order, simple replay. Once the goal becomes “raise execution width without breaking verifiable correctness,” designers hit the same fork: who decides whether two transactions may run together — the developer up front, or the runtime later?
That choice shapes the programming model, migration cost, and real throughput under hot contention. The industry has worn three relatively clear paths: deterministic parallelism exemplified by Solana’s Sealevel; optimistic concurrency control (OCC) exemplified by Aptos’s Block-STM and multiple parallel EVMs; and an object model exemplified by Sui. All three “parallelize,” with very different assumptions and costs.
Deterministic parallelism: dependencies written on the transaction
The deterministic path requires each transaction to carry a full list of accounts (or resources) it will read and write, marked read-only or writable. Before execution, the runtime can build a graph: no write conflict implies parallel safe; shared reads can co-schedule; shared writes serialize. The scheduler need not guess dependencies mid-flight; conflict structure is approximately known at enqueue time. Solana’s Sealevel is the most cited engineering sample, tightly coupled to its account model and runtime storage.
The upside is predictability: once accepted, execution paths waste less work on “discover conflict halfway and abort the whole attempt.” The cost lands on developers and tooling. Simple transfers are cheap to declare; programs with complex branches whose access paths depend on runtime conditions must either over-declare (shrinking parallelism) or under-declare (failing the transaction). Classic EVM storage-slot access is often decided by in-contract conditions; bytecode does not carry a Sealevel-style account list. Forcing pre-declaration immediately breaks bytecode-level compatibility — contracts and audit assumptions must be rewritten.
Pre-declaration also does not erase application hotspots. DEX pools, liquidations, and hot mints still concentrate writes on a few accounts; conflict chains lengthen; parallelism is gated by state design, not the scheduler. Determinism solves “do we know dependencies at schedule time,” not “has state been spread out.” How workloads create hotspots belongs elsewhere; note here that no engine rescues a contract structure where everyone contends for the same slot.
Optimistic concurrency control: assume parallel, converge on errors
OCC flips the bet: most transactions do not conflict, so run them in parallel first, then validate whether read sets are still valid; on conflict, abort and re-execute in canonical order until the result equals some serial order. Software transactional memory (STM) and database OCC supply the theoretical skeleton; Aptos’s Block-STM is a widely cited blockchain instance — optimistic execution under a preset order, with collaborative scheduling that discovers dependencies during execution and re-runs work, aiming to roll back only truly affected transactions.
High TPS figures in public materials usually come from specific benchmarks, hardware, and transaction mixes (for example non-trivial Move transactions in lab or test environments). They are not interchangeable with mainnet mixed-load UX. What matters is the mechanism shape: correctness depends on “eventually equivalent to a given order”; performance depends on “conflict rates low enough or re-execution cheap enough.”
Multiple EVM-compatible chains choose OCC for a consistent reason: at receipt time you cannot statically know every storage access — only execution reveals it. The runtime records actual read/write sets; conflicting subsets converge serially; the rest keep parallel gains. Monad, Sei, and others differ in snapshots, commit order, and whether consensus decouples from execution, but share “no developer pre-declaration” as the compatibility premise.
OCC’s core risk is equally public: when conflict rates spike, re-execution eats the parallel surplus, and in extremes throughput can approach or fall below a naive serial-plus-locks strategy. Selective rollback, in-flight detection, batching, and read/write-set granularity decide the tail cost when the optimistic bet fails. The next article explains OCC’s read–validate–write phases from a database view.
Object models: change the ledger shape to change parallel boundaries
The third path does not patch the account model; it changes ledger structure. Sui models assets as objects with unique IDs, split into owned and shared objects. Owned objects have a single writer, so related transactions can take a lower-latency path with weaker global-ordering needs. Shared objects admit many touchers and must be ordered through consensus. Parallelism becomes an ownership problem: naturally single-owner flows scale out; truly multi-party shared state pays for global ordering.
The model is friendly to NFTs and peer-to-peer asset moves; AMM pools, global auctions, and other shared-object-heavy apps still hit hot contention — at object granularity rather than account-slot granularity. The cost is paradigm and language migration: Move and object ownership differ from Solidity’s account model. Existing Ethereum contracts and Foundry/Hardhat workflows do not “lift and shift”; ecosystems pay learning and audit costs for parallelism.
Object models prove execution parallelism need not be only “declare” or “optimistic” scheduling — state topology is another lever. They also remind EVM-compatible routes: keeping accounts and global state means giving up some structural parallelism the object model buys, so runtime scheduling must carry more of the load.
How the three paths compare
| Dimension | Deterministic (Sealevel-like) | Optimistic OCC (Block-STM-like) | Object model (Sui-like) |
|---|---|---|---|
| When dependencies are known | Declared before submit | Discovered during/after execution | Derived from object ownership |
| Developer burden | High (access lists) | Low (keep familiar contract style) | High (new model/language) |
| Fit with classic EVM | Hard (semantic clash) | Relatively feasible | Requires migration |
| Main failure mode | Over-/under-declaration; hotspots still serialize | High-conflict re-execution storms | Shared-object hotspots; ecosystem migration |
The pattern is clear: if the hard product constraint is bytecode-level compatibility with existing Ethereum contracts and tools, deterministic pre-declaration and object models both force rewrite or stack change, so real options often converge on OCC. That is not a claim OCC is theoretically best under every load — deterministic and object paths have shown strong throughput in their ecosystems — it is an admission that compatibility compresses the design space.
For an L1 positioned as an optimistic parallel EVM, choosing OCC is convergence under constraint, not a slogan. The real engineering questions become how to define read/write sets, how early to detect conflicts, and how to bound re-execution under hot load. Those rest on OCC’s database intuition and on honest workload-hotspot assessment.
Further reading
- Previous: "Mapping Blockchain Scaling: What L1 Parallelism, L2s, Sharding, and DA Each Solve"
- Next: "Optimistic Concurrency Control (OCC) Primer: From Databases to On-Chain Execution"
- Related: "Bitroot's Parallelised EVM Technology Explained: Optimistic Parallelisation", "Conflict Hotspots and Workloads: When Parallel EVM Actually Helps"