--- id: 11 title: "The Single-Threaded EVM's Performance Ceiling: From Gas Congestion to Confirmation Delay" slug: evm-single-thread-bottleneck date: 2026/08/22 summary: From CryptoKitties to the Otherside NFT mint, every major Ethereum congestion event traces back to the same root cause: the EVM was built to run single-threaded. This piece breaks down why raising the gas limit and EIP-1559 treat the symptom, not the cause, and why fixing throughput means rethinking the execution model itself. keywords: single-threaded EVM,gas congestion,confirmation latency,EIP-1559,Ethereum performance bottleneck heroImage: /images/community-bg.png --- On a weekend in December 2017, a cat-breeding game called CryptoKitties nearly brought Ethereum to a halt. Quaint as it looks in hindsight, this NFT game accounted for close to a quarter of all transactions on the network at its peak, the backlog of pending transactions piled up past 30,000, confirmation times for ordinary transfers stretched from seconds to hours, and gas prices spiked above 450 gwei. It was the crypto industry's first large-scale lesson that a "world computer" built on such high expectations could be pushed to the edge of unusability by a single game-tier application. Eight years on, the same scene keeps repeating. During the 2021 DeFi Summer, composable interactions across Uniswap, Compound, Yearn, and other protocols drove a surge in on-chain activity that kept gas prices elevated for months. In April 2022, Yuga Labs' Otherside "deed" NFT mint burned through more than 55,000 ETH — roughly $158 million — within 24 hours; plenty of users paid over $14,000 in gas just to mint two NFTs, and some were quoted more than $4,500 in fees for a $5 transfer. Ethereum came close to grinding to a halt, and Yuga Labs later published a public apology. These events are years apart and each has its own trigger, but they all point to the same technical root cause: the Ethereum Virtual Machine was designed to run single-threaded, executing every transaction one at a time, in order. That constraint has never been engineered away — it just keeps getting rediscovered, one congestion event at a time. ## Why Ethereum was never built to go fast According to Chainspect's real-time monitoring, Ethereum mainnet currently runs at roughly 15.48 transactions per second, with the peak over the most recent 100 blocks reaching only about 75 TPS, against a theoretical ceiling of around 238 TPS. Those numbers are worth sitting with: even the theoretical peak falls well short of an ordinary credit-card network's throughput, and the gap between everyday performance and that theoretical ceiling is several times wider still. The reason isn't complicated. The EVM's execution model requires every transaction to run to completion and finish updating state before the next one can begin. That strict serial ordering isn't an engineering oversight — it's a deliberate design choice: it guarantees that replaying the same set of transactions on any node produces the same final state, which is the foundation consensus is built on. Ethereum's global state tree compounds the constraint further, because every transaction, whether or not it has any actual data dependency on another, has to interact with the same enormous Merkle Patricia Trie — any transaction's execution can potentially touch any corner of that tree. In other words, Ethereum made a deliberate trade-off at design time between determinism and throughput, and gave up the latter to secure the former. That trade-off made complete sense in the early days, when few participants and light on-chain activity meant it barely mattered — but as more capital, users, and applications piled in, single-threaded execution turned into a hard physical ceiling. That ceiling isn't entirely fixed. The Ethereum community has kept squeezing out more headroom by raising the block gas limit: it went from 30 million to 36 million in February 2024, climbed to roughly 60 million by the end of 2025, and the validator community is now pushing toward a target of 45 million and beyond. These adjustments have genuinely lifted TPS, from about 13.67 in Q1 2024 to about 25.78 in Q1 2026. But this kind of gain is really just "widening the lane" within the same serial execution architecture — the marginal returns diminish quickly, and pushing the gas limit higher directly increases the state-storage and sync burden on every full node. It's a costly trade-off, not an architectural breakthrough. ## Congestion isn't an accident — it's inevitable Picture the Ethereum network as a single-lane highway: every time a hot new application takes off, it's as if every car on the road tries to merge into that one lane at once. CryptoKitties was the earliest example, and every hype cycle since has replayed a version of the same script — the high-frequency interactions of 2020's DeFi Summer yield-farming boom, the buying frenzy around Bored Ape Yacht Club and its spin-offs during the 2021-2022 NFT mint wave — each of which sent gas prices spiking tens of times over in a matter of hours. A more subtle mechanism amplified the intensity of that congestion: the Priority Gas Auction (PGA). Under Ethereum's early first-price auction model, whether a transaction got picked up by a miner depended heavily on how much gas price the user was willing to pay. Whenever a scarce resource showed up — an NFT mint slot, an arbitrage opportunity — participants would keep outbidding each other trying to front-run on-chain, and that bidding war itself pushed up the gas level for the entire network, collateral damage landing on every other user's ordinary transaction, while also opening up room for miners to extract MEV. Ethereum restructured this mechanism at a fundamental level with EIP-1559 in August 2021. Researchers had identified three problems with the old first-price auction model: users routinely bid the gas price their wallet suggested — a price originally calibrated for congestion — which meant they were overpaying two to five times the market-clearing level even under normal conditions; gas prices could swing by more than 50% within a single block; and miners, who collected both the block reward and the entirety of transaction fees, had an incentive to manipulate transaction ordering. EIP-1559 introduced a base fee that adjusts dynamically block by block and gets burned rather than paid to miners, with users only needing to add a small priority fee to get faster inclusion. This design did reduce fee unpredictability and cut off miners' ability to extract extra value from the base fee — but it only reshapes how fees are formed. It doesn't touch the underlying constraint that transactions must still execute serially, one after another. In other words, EIP-1559 manages the price signal congestion produces, not the cause of congestion itself. That's precisely why, even with EIP-1559 live and the gas limit continuing to rise, fee spikes and confirmation delays keep coming back whenever on-chain activity gets dense enough. As long as the execution engine is single-threaded, capacity has a hard ceiling, and once demand crosses that ceiling, the only thing a pricing mechanism can do is squeeze out the excess demand — not absorb it. ## Confirmation delay: an easily overlooked cost of its own TPS tends to be the only metric anyone brings up when discussing Ethereum's performance, but confirmation delay matters just as much — and it's more easily misunderstood than TPS. Since the Merge to proof-of-stake, block time has been fixed at roughly 12 seconds. But a block being produced doesn't mean it's already irreversible. Ethereum uses Casper FFG as its finality gadget: checkpoints are proposed and voted on at the start of each 32-slot epoch, and a checkpoint isn't formally finalized until it has been attested by roughly two-thirds of validators across two full epochs — a process that takes about 12.8 minutes end to end. That means a transaction goes through roughly a dozen or more minutes between being included in a block and reaching classic cryptographic finality. For an ordinary transfer, that delay is probably tolerable — but for large exchange deposits and withdrawals, cross-chain bridging, or high-frequency liquidation, a window of uncertainty lasting over ten minutes is a real, tangible cost. The industry has responded by developing two parallel conventions: "soft confirmation" and "hard finality." Most applications treat a transaction as unlikely to be reorged once it's a few blocks deep, and build an approximate confirmation experience around that assumption; but scenarios that genuinely need cryptographic-grade guarantees still have to wait out the full finality cycle. That layering is a reasonable engineering compromise in itself, but it also reveals something important: Ethereum's current performance constraints show up not just in throughput numbers, but in the fact that users and applications are forced to design their own risk models around those constraints. ## Why staying "EVM-compatible" still means touching the execution model A natural question follows: given how large the EVM ecosystem is and how mature its tooling has become, why not simply keep EVM bytecode and semantics as they are, and improve performance purely through lower-level engineering — a faster storage engine, better network propagation? The answer is that Ethereum's performance bottleneck doesn't mainly come from the efficiency of network propagation or storage I/O — it comes from the serial structure of the execution stage itself. No matter how fast the underlying database is or how optimized the P2P network gets, as long as transactions have to enter the EVM interpreter one after another, throughput will always be capped at single-core CPU speed multiplied by block time. Multi-core processors have long been standard on servers and consumer devices alike, but the traditional EVM execution path simply can't take advantage of those extra cores — a plain waste of available resources. That's exactly why "parallel execution" has become the central point of technical divergence in high-performance chain design over the past several years, and why Solana, Aptos, Sui, Monad, Sei, and a string of other projects have converged on it independently — even though the specific parallelization approach each of them picked (deterministic scheduling, optimistic concurrency control, an object model) differs quite a bit. For projects committed to staying EVM-compatible, the problem gets more specific: how do you give a fundamentally serial execution engine the ability to process transactions in parallel, while preserving Solidity contract semantics and the account/global-state model, without breaking the very property that made the EVM trustworthy in the first place — determinism. This isn't a problem that can be solved by throwing more hardware at it; it requires redesigning the execution engine itself. That's exactly what this series will unpack step by step going forward: what parallel execution actually solves, what approaches are available, what engineering obstacles have to be cleared, and — concretely — how a project like Bitroot, which has chosen the optimistic-parallel EVM route, is tackling all of this. ## Further Reading - Next: ["Mapping Blockchain Scaling: What L1 Parallelism, L2s, Sharding, and DA Actually Solve"](/en/blog/blockchain-scaling-map) --- Sources: [Chainspect - Ethereum](https://chainspect.app/chain/ethereum); [Consensys - The Inside Story of the CryptoKitties Congestion Crisis](https://consensys.io/blog/the-inside-story-of-the-cryptokitties-congestion-crisis); [Decrypt - Otherside NFT Mint Burned More Than $157M in Ethereum](https://decrypt.co/99219/otherside-nft-mint-burned-more-157m-ethereum); [CryptoSlate - Ethereum user spends $44,000 in gas fees](https://cryptoslate.com/ethereum-user-spends-44000-in-gas-fees-to-mint-bored-ape-otherside-nfts/); [Ethereum Improvement Proposals - EIP-1559](https://eips.ethereum.org/EIPS/eip-1559); [eth2book - Casper FFG](https://eth2book.info/latest/part2/consensus/casper_ffg/); [Cointelegraph - Ethereum gas limit target](https://www.fxstreet.com/cryptocurrencies/news/ethereum-is-scaling-tps-gas-limit-up-as-validators-back-45m-target-202507210723)