--- id: 20 title: Conflict Hotspots and Workloads: When Parallel EVM Actually Helps slug: parallel-evm-workload-hotspots date: 2026/09/13 summary: Parallel EVM rarely fails on transfer benchmarks, but often collapses on AMM, lending, and NFT mint traffic. This article explains how conflict hotspots form, how read/write-set granularity drives conflict rates, and how peak TPS degrades under real workloads. keywords: parallel EVM,conflict hotspot,workload,read/write set,AMM,TPS heroImage: /images/community-bg.png --- Parallel execution sounds like “turn on more cores and throughput goes up.” For low-conflict workloads, that intuition is roughly right: transactions that never touch the same state slots can be consumed by different execution engines at once, and multi-core utilization rises. But the traffic that actually congests public chains is rarely clean peer-to-peer transfers. It is contract calls that repeatedly read and write the same hot accounts or storage slots. Then parallelism is no longer bounded by CPU count; it is bounded by **conflict rate**. Once you see that, you can read any “parallel EVM” performance number correctly: the same engine can differ by an order of magnitude across workloads. ## Low conflict vs high conflict: two different games Low-conflict load looks like many unrelated simple transfers, moves between independent NFT holders, or read-only queries against distinct contract instances. Read/write sets barely overlap, so optimistic parallelism can approach an “ideal speedup”: N engines absorb nearly N times the conflict-free work, minus a fixed scheduling and version-check cost. High-conflict load is the opposite. The same AMM pair, the same lending interest index, or the same NFT mint counter packs many transactions into a tiny state set. Optimistic execution still runs ahead in parallel, but validation discovers version conflicts and many transactions must be redone in serial order. The engines look busy while effective throughput collapses toward single-thread levels, plus rollback and re-execution overhead. So “is parallel EVM fast?” is not a yes/no question. It is “how much faster, under which conflict distribution?” ## Why AMM, lending, and NFT mint hurt throughput Automated market makers concentrate liquidity and price into a small number of pool-contract storage slots. Multiple swaps in the same block often read and write the same `reserve` or price-related slots, so conflict is structural. Even when user addresses differ, **contract-side hotspots** are enough to flatten parallelism. Lending is similar: interest indices, global borrow totals, and shared liquidation parameters become meeting points across users. A “user A deposits” transaction may share global variables with user B’s borrow and user C’s liquidation. NFT mint is more extreme: sequential IDs, supply counters, and allowlist bitmaps are often a single write point under short-lived contention. Historic mint rushes on Ethereum pushed gas auctions into absurd ranges not only because “many people showed up,” but because the execution layer could not split those tightly coupled writes. ## Read/write-set granularity: the hidden knob on conflict rate Optimistic parallelism uses read/write sets to decide whether two transactions are conflict-free. Sets can be as coarse as the account level or as fine as individual storage slots. - Coarser sets over-report conflicts: two transactions that touch different slots of the same contract get serialized anyway. - Finer sets raise analysis and version-management cost: the dependency graph fragments and metadata grows, but true parallelism also grows. Engineering usually balances account-level heuristics and slot-level precision, with static dependency analysis before execution, version watches during execution, and a post-execution state-root check (see [Optimistic Concurrency Control (OCC) Primer](/en/blog/optimistic-concurrency-control-intro)). For application developers the implication is concrete: splitting unrelated state across slots, reducing global counters, and avoiding a single hot `totalSupply` path often improves confirmation experience more than switching chains. ## How peak TPS degrades on hotspots Benchmarks prefer synthetic conflict-free loads because the curves look good. Real blocks are mixed: some transfers parallelize; some DeFi calls jam on hotspots. Effective throughput is roughly constrained by (illustrative, not an exact formula): effective throughput ≈ parallel gain on the conflict-free share + near-serial throughput on the conflicting share − rollback/re-execution cost. As the conflicting share rises, the last two terms dominate. That produces a common marketing-versus-engineering mismatch: materials quote “peak TPS on ideal load,” while users on mint day or during volatile markets feel slower confirmation and more retries. Honest disclosure shows **both low-conflict and high-conflict** figures, with hardware, client version, and transaction mix stated (see [Performance Metrics Glossary](/en/blog/performance-metrics-glossary)). Optimistic parallel EVM chains that choose to confront composable DeFi—rather than only optimizing transfer benchmarks—make conflict detection and dynamic grouping quality the gap between poster throughput and user-visible throughput. ## Practical implications for contract and protocol design 1. **Find hot slots**: map high-frequency writes during audits; global counters, single liquidity pools, and shared config bits are prime suspects. 2. **Split state**: isolate writes by user, pool, or shard whenever possible instead of funneling them into one slot. 3. **Drop implicit ordering assumptions**: logic that relies on “implicit same-block order” is more brittle under optimistic parallelism; encode ordering explicitly or make the design conflict-tolerant. 4. **Interpret benchmarks via conflict rate**: when you see a TPS number, ask about transaction mix first; a peak without conflict distribution has limited reference value. ## Closing: parallelism is not a free lunch Parallel EVM uses multiple cores only when the workload contains enough conflict-free transactions. Hot contracts do not vanish because the execution engine changed; they move the bottleneck from “single-thread interpreter” to “conflict detection and re-execution.” Explaining that is more useful than another elevator pitch: it tells developers whether to change storage layout, and it tells readers how to doubt the next performance poster. ## Further reading - Previous: [Decentralization vs Performance: Validator Thresholds, Hardware, and Geography](/en/blog/decentralization-performance-tradeoff) - Related: [Three Paths to Parallel Execution: Deterministic, Optimistic, and Object Models](/en/blog/parallel-execution-approaches) - Related: [Optimistic Concurrency Control (OCC) Primer: A Database View of Blockchain Execution](/en/blog/optimistic-concurrency-control-intro) - Related: [Performance Metrics Glossary: TPS, BPS, Confirmation Latency, Finality, Conflict Rate](/en/blog/performance-metrics-glossary)