In public-chain performance debates, TPS is often treated as the only yardstick. Ask why Ethereum mainnet has long sat in the low teens of transactions per second in everyday conditions, and the answer is rarely “not enough hardware.” It is the execution model itself: the Ethereum Virtual Machine is designed to finish one transaction before starting the next. That constraint buys deterministic replay across the network — and nails throughput to a single-threaded physical bound.
Understanding that bound matters more than memorizing any instantaneous TPS figure. Later pieces cover the scaling map, parallel-execution paths, and optimistic concurrency control. This article pins the problem down first: why a single-threaded EVM caps TPS, how historical congestion repeatedly confirmed it, and why neither a higher gas limit nor EIP-1559 fixes the execution model.
Serial execution is not a bug — it is the price of determinism
EVM semantics require transactions in a block to run in canonical order. Only after one transaction’s state writes complete may the next begin reading state. The upside is immediate: any honest node replaying the same sequence reaches the same state root. Consensus only needs agreement on transaction order and block contents, not on how a parallel interleaving should resolve writes.
The cost is equally direct. Modern servers expose dozens of logical cores, yet a classic EVM node still behaves on the hot path roughly like “one core works while the others watch.” Two unrelated transfers — A pays B, C pays D — cannot advance together under the serial model, because the scheduler assumes any transaction might touch any corner of the global state tree. The Merkle Patricia Trie hangs accounts and storage slots on one enormous structure, reinforcing the engineering habit of refusing parallelism without prior dependency information.
The structural gap follows: bandwidth and disk I/O can scale vertically, while execution throughput stays stuck at “one at a time.” When demand stays under that hard ceiling, users barely notice. When demand crosses it, excess transactions queue in the mempool and the fee market takes over — the technical definition of congestion.
Historical congestion: the same disease, different symptoms
CryptoKitties in 2017 was the first widely documented large-scale congestion episode. At peak, the cat game occupied a substantial share of on-chain transactions, the pending queue ballooned, ordinary transfers stretched from seconds to hours, and gas prices pushed into the hundreds of gwei. Postmortems often blamed a “game that got too popular.” More precisely, a hot application merely exposed a capacity ceiling that was already there.
The script repeated. During dense DeFi composability in 2020–2021, gas stayed elevated for long stretches. During land-deed-style NFT mints such as Otherside in 2022, short bidding wars drove fees to extremes — including cases where tiny transfers were quoted astronomical fees. Triggers differed — games, yield farming, NFT rushes — but the queueing logic did not: the execution engine can digest only so much “useful computation” per second, and excess demand is rationed by higher bids displacing cheaper transactions.
These episodes also showed how priority gas auctions amplify pain. Under the early first-price model, scarce opportunities (mint slots, arbitrage windows) triggered cascading bids that lifted fee levels network-wide, so ordinary users paid for someone else’s hotspot. Congestion is not only “slow”; it is “expensive,” and expense often pushes marginal users off-chain earlier than latency alone would.
Gas limits: widening one lane, not adding lanes
The Ethereum community has repeatedly raised the block gas limit to squeeze out more capacity. A higher limit lets each block carry more computation, so TPS can move up in the short run. That still happens inside serial execution: you widen a single lane rather than turning the highway into parallel lanes.
The path has clear diminishing returns and external costs. The higher the gas limit, the more state change full nodes must execute, verify, and store per unit time — sync and hardware requirements rise with it. Treating “scaling” as “raise the gas limit forever” eventually pushes decentralized validation beyond what ordinary operators can run. Gas-limit tuning is a useful operational knob, not a substitute for the execution model. It answers “how much more work to pack under a single-thread constraint,” not “how to advance many conflict-free transactions at once.”
Public monitors’ Ethereum TPS figures — teens in daily conditions, higher short peaks, a still-higher theoretical ceiling — belong in the same frame. Exact decimals move with time and measurement windows; what matters is the order of magnitude: the single-thread model pins the ceiling in a range that feels tight for a “global settlement layer” narrative, and everyday operation often sits several times below theoretical peaks.
EIP-1559: fee formation, not execution width
EIP-1559, live since 2021, reworked the fee market. A base fee adjusts with block utilization and is burned; users add a priority fee for faster inclusion. Research motivations included reducing systematic overpayment under first-price auctions, dampening wild within-block quote swings, and cutting miners’/validators’ ability to extract from the base fee itself.
In practice, EIP-1559 improved fee predictability and eased “always bid as if congested.” It never promised to raise the physical throughput of serial execution. When blocks stay full, the base fee rises and squeezes excess demand out of the market — price discovery, not capacity expansion. Reading EIP-1559 as a “scaling solution” is a common mistake; a better label is “cleaner queueing and pricing under fixed execution capacity.”
Priority fees and later MEV-related mechanisms likewise concern how transactions are ordered and how ordering value is captured, still assuming the execution stage finishes serially. No amount of sophistication in the ordering layer removes the hard top while execution digests one transaction at a time.
Confirmation delay: the axis TPS hides
TPS asks how many transactions finish per unit time; confirmation delay asks how long a user waits from broadcast until the result is “trusted enough to be irreversible.” They correlate but are not equivalent. Average TPS can look acceptable while mempool backlog still stretches single-transaction waits beyond product tolerance.
Ethereum also layers consensus confirmation semantics: block interval, finality gadgets, reorg risk — all enter “confirmation” as users experience it. When the execution layer congests, transactions can linger pending; application timeouts, bridge windows, and market-maker inventory risk amplify together. For payments and high-frequency interaction, latency spikes often hurt products more than mean TPS.
The full picture of the single-thread bottleneck is therefore: the throughput ceiling decides how much the system can absorb; queueing and fees decide who gets in; confirmation delay decides how long “in” takes. Same root — insufficient execution width — different symptoms. Any “scaling” claim should be scored on each axis separately.
Conclusion: the thing to change is the execution model
Place historical congestion, gas-limit raises, and EIP-1559 side by side and the conclusion sharpens: fee markets and block parameters manage scarcity; they do not remove its cause. As long as the EVM keeps the classic shape of global state plus one-by-one serial execution, TPS has a hard ceiling, and hot applications will periodically drag the whole network into high fees and high latency.
Breaking that ceiling reframes the problem: how can conflict-free transactions run in parallel while verifiable determinism holds? Answers are not unique — deterministic pre-declaration, optimistic concurrency control, object models, and more. Projects that still want Ethereum bytecode and tooling compatibility face a narrower option set. Those questions belong to the scaling map and parallel-path discussions. This piece only needs the premise: the object of a real fix is the execution model, not another turn of the gas knob.