State Growth is the Real Constraint. Every transaction modifies Ethereum's global state. The state size expands with each new contract and account, increasing the cost for nodes to sync and validate. This imposes a hard TPS ceiling independent of gas market dynamics.
the-ethereum-roadmap-merge-surge-verge
Blog
What Caps Ethereum Transactions Per Second
A technical breakdown of Ethereum's true scalability bottlenecks: state growth, consensus overhead, and the path forward via Danksharding and data availability sampling.
introduction
THE STATE SYNC
The Misconception: Gas is the Only Bottleneck
Ethereum's TPS is constrained by state growth and data availability, not just gas fees.
Data Availability Drives Finality. Layer-2s like Arbitrum and Optimism post transaction data as calldata to Ethereum for security. The blob data bandwidth from EIP-4844, not gas, is the primary limit for their aggregated throughput. This creates a shared data layer bottleneck.
Evidence: The current blob target is ~0.375 MB per block. With an average L2 tx size of 12 bytes, the theoretical data-limited TPS for all L2s combined is ~3,125 TPS. This is the network's new scaling frontier.
key-trends
WHAT CAPS ETHEREUM TPS
The Three Real Bottlenecks
Ethereum's ~15 TPS limit isn't a single flaw, but a deliberate trade-off between decentralization, security, and scalability. Here's where the rubber meets the road.
01
The Problem: Global Consensus is a Shared Hard Drive
Every full node must process and store every transaction. This synchronous execution creates a physical ceiling.
- Bottleneck: Node hardware (CPU, I/O, storage) must remain accessible to hobbyists.
- Consequence: Throughput is limited to the slowest viable node, not the fastest.
- Real Limit: ~1-10 MB/s of block data is the practical network-wide ceiling.
~15 TPS
Base Layer
~1.5 MB
Block Size
02
The Problem: State Growth is a Ticking Clock
The 'state'—the current balance of every account and smart contract—must be readily accessible. Its unbounded growth strangles node performance.
- Bottleneck: State bloat increases sync times and hardware requirements, threatening decentralization.
- Consequence: Gas costs must price in the permanent cost of state storage (via EIP-1559 burn).
- Real Limit: Throughput is throttled to keep annual state growth below ~50 GB.
~800 GB
Current State
Days
Sync Time
03
The Solution: Execution Sharding Was Wrong; Rollups Are Right
Ethereum abandoned complex execution sharding for a rollup-centric roadmap. Rollups (Arbitrum, Optimism, zkSync) batch and execute transactions off-chain, posting only compressed proofs to L1.
- Key Insight: Moves execution and state growth off the base layer.
- Result: Base layer secures data & settlement; rollups provide ~1000-4000 TPS per chain.
- Future: Proto-Danksharding (EIP-4844) introduces data blobs, reducing rollup costs by ~10-100x.
1000x+
Scalability Gain
~$0.01
Target Cost
ETHEREUM TPS CAPS
Bottleneck Impact Matrix
A first-principles breakdown of the fundamental constraints limiting Ethereum's transaction throughput, measured in transactions per second (TPS).
| Bottleneck Layer | Current Ethereum (L1) | Proto-Danksharding (EIP-4844) | Full Danksharding (Post-4844 Vision) |
|---|---|---|---|
Execution Throughput (Gas/sec) | ~30M gas/block (~12.5 sec) | ~30M gas/block (~12.5 sec) | ~30M gas/block (~12.5 sec) |
Block Space for Data (Bytes/block) | ~90 KB (calldata, expensive) | ~1.3 MB (blobs, cheap) | ~16 MB (blobs, cheap) |
Dominant TPS Constraint | Execution Gas Cost | Execution Gas Cost | Consensus & P2P Propagation |
Max Theoretical TPS (Simple Transfer) | ~30 TPS | ~30 TPS | ~30 TPS |
Max Theoretical TPS (ZK-Rollup Batch) | ~3,000 TPS (data-limited) | ~100,000 TPS (execution-limited) | ~1,000,000+ TPS (consensus-limited) |
Data Availability Guarantee | On-chain, Full L1 Security | On-chain, Full L1 Security | On-chain, Full L1 Security |
Requires Consensus Change |
deep-dive
THE SCALING CAP
The Surge Roadmap: Breaking the Bottlenecks
Ethereum's transaction throughput is fundamentally limited by its monolithic architecture, which the Surge roadmap addresses through data sharding.
Block Gas Limit is the primary hard cap. Each block has a finite computational budget, currently ~30M gas, which directly limits transactions per second (TPS) to ~15-30 for simple transfers.
Synchronous Execution Bottleneck forces every validator to process every transaction. This monolithic design creates a physical ceiling, unlike parallelized chains like Solana or Sui which separate execution from consensus.
Data Availability is the Real Constraint. The cost of posting transaction data to Layer 1 is the dominant expense for rollups like Arbitrum and Optimism. This is the bottleneck the Surge's Danksharding specifically targets.
Evidence: Proto-danksharding (EIP-4844) introduced blob data, reducing L2 transaction costs by over 90% by decoupling data storage from execution. Full Danksharding will scale this to ~1.3 MB per slot.
FREQUENTLY ASKED QUESTIONS
Scalability FAQ: Beyond the Hype
Common questions about the fundamental bottlenecks limiting Ethereum's transaction throughput.
Ethereum's base layer currently processes about 15-30 transactions per second (TPS). This hard limit is defined by the 30 million gas per block cap and the average gas cost of a simple transfer. Layer 2 rollups like Arbitrum and Optimism are the primary solution, bundling thousands of transactions off-chain to increase effective TPS into the thousands.
takeaways
THE BOTTLENECKS
Key Takeaways for Builders
Ethereum's ~15 TPS ceiling is a function of its decentralized security model, not a design flaw. Here's what's actually capping throughput.
01
The Block Gas Limit is a Physical Constraint
Each block has a finite gas budget (~30M gas). More complex operations (e.g., Uniswap swaps) consume more gas, directly capping the number of transactions per block. Raising it increases node hardware requirements, threatening decentralization.
- Key Constraint: ~30M gas/block hard cap.
- Builder Impact: Your contract's gas efficiency is a direct scaling lever.
~15 TPS
Current Cap
30M
Gas/Block
02
State Growth is the Hidden Tax
Every new storage slot (e.g., an NFT mint, a wallet balance) permanently increases Ethereum's state size. Larger state slows node synchronization and increases hardware costs, disincentivizing participation. This creates a long-term scaling trade-off.
- Core Trade-off: More state = higher node costs = less decentralization.
- Builder Mandate: Design for state minimalism; use stateless architectures or Layer 2s.
1TB+
Archive Size
~650 GB
Full Node
03
Synchronous Execution is Non-Negotiable
Every validator must re-execute every transaction to verify state transitions. This serialized computation is the bedrock of Ethereum's security but is inherently slow. Parallelization (EVM) or sharding (Danksharding) are the only paths forward without breaking the security model.
- First Principle: Security requires full re-execution by all validators.
- Future Path: EVM for parallel execution, Danksharding for data availability.
1 Core
Execution Thread
~12s
Block Time
04
The Real Solution is Layer 2 & Modular Design
Ethereum's scaling roadmap explicitly offloads execution. Rollups (Arbitrum, Optimism, zkSync) batch 1000s of transactions into a single L1 proof. The future is a modular stack where L1 provides security and data availability, while L2s and alt-DA layers (Celestia, EigenDA) handle execution.
- Architecture Shift: Build on L2s; treat L1 as a settlement/DA layer.
- Throughput Multiplier: 100-1000x effective TPS via rollups.
100-1000x
L2 Multiplier
$30B+
L2 TVL
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall