Gas is physical compute. Every transaction consumes gas, which represents a unit of computational work on the Ethereum Virtual Machine. The network's total capacity is the block gas limit, a finite resource that defines the system's maximum throughput.
the-ethereum-roadmap-merge-surge-verge
Blog
Why Gas Limits Define Ethereum Scale
Ethereum's scalability is not defined by TPS dreams but by the hard, physical constraint of its gas limit. This analysis deconstructs the Surge roadmap, proving that every scaling upgrade—from blobs to danksharding—is fundamentally a gas limit expansion strategy.
introduction
THE BOTTLENECK
The Scaling Illusion: It's All About Gas
Ethereum's scalability is defined by its gas limit, a hard physical constraint that all scaling solutions must ultimately navigate.
Layer 2s are gas arbitrageurs. Protocols like Arbitrum and Optimism scale by executing transactions off-chain and posting compressed proofs or data back to Ethereum. Their capacity is still bounded by the cost and speed of this final settlement layer.
Data availability is the real constraint. Rollups like Arbitrum Nova and zkSync use external data availability layers to reduce costs, but this trades Ethereum's security for scalability. The core limit shifts from execution gas to data publishing gas.
Evidence: The 30M gas ceiling. Ethereum's mainnet block gas limit has remained near 30 million for years. Even with full rollup adoption, this caps theoretical throughput to roughly 100-1000 TPS for simple transfers, not the millions often claimed.
key-trends
THE FUNDAMENTAL CONSTRAINT
Executive Summary: The Gas Limit Reality
Ethereum's scalability is not a software problem; it's a physical one, bounded by the gas limit of a single block.
01
The Problem: The Single-Threaded Bottleneck
Every transaction competes for space in a linear block. This creates a zero-sum auction where demand spikes cause fees to soar, pricing out all but the highest-value transactions.\n- ~30M gas/block is the current hard cap.\n- ~100 TPS is the practical throughput ceiling.\n- $100+ fees during peak demand.
~100
Max TPS
30M
Gas/Block
02
The Solution: Execution Sharding (Danksharding)
Decouples data availability from execution. Proto-Danksharding (EIP-4844) introduces blob-carrying transactions, creating a dedicated, cheap data layer for rollups like Arbitrum and Optimism.\n- ~1.3 MB of cheap data per block via blobs.\n- ~100x cost reduction for rollup data.\n- Enables modular scaling by specializing the base layer.
~100x
Cheaper Data
1.3 MB
Blob Capacity
03
The Solution: Rollups as the Scaling Primitive
Move execution off-chain, batch proofs on-chain. ZK-Rollups (zkSync, Starknet) and Optimistic Rollups (Base, Arbitrum) inherit security while operating at ~2,000-10,000 TPS.\n- ~$0.01 average transaction cost.\n- ~90% of L2 activity now occurs on rollups.\n- $40B+ TVL secured by Ethereum.
~$0.01
Avg. L2 Cost
$40B+
L2 TVL
04
The Trade-off: The Modular vs. Monolithic Debate
Ethereum chooses modularity (security + scalability) over monolithic chains (Solana, Monad) that push a single chain's limits. This creates complexity but ensures decentralization.\n- Modular: Specialized layers (Data, Execution, Settlement).\n- Monolithic: One chain does everything, risking centralization.\n- Celestia, EigenDA emerge as specialized data layers.
3+
Specialized Layers
1
Security Source
thesis-statement
THE PHYSICS OF BLOCKSPACE
The Core Argument: Scalability = Gas Limit * Utilization
Ethereum's transaction throughput is a simple, immutable product of its gas limit and how efficiently that gas is used.
Scalability is a math problem. Ethereum's base layer processes a finite number of transactions per block, defined by the product of its gas limit and average transaction gas cost. This is the hard throughput ceiling.
Gas limits are a security parameter. Raising the block gas limit increases potential throughput but also increases state growth and hardware requirements for validators, directly impacting network decentralization and security.
Utilization is the optimization variable. Protocols like Uniswap V4 with hooks and EIP-4844 blobs achieve higher scale by packing more economic value into each unit of gas, maximizing the utilization term in the scalability equation.
Evidence: Post-Dencun, Arbitrum processes ~2M daily transactions by leveraging blob data for cheap data availability, demonstrating that scaling occurs by optimizing utilization, not just raising limits.
BLOCK SPACE ECONOMICS
The Gas Limit Evolution: From Constraint to Strategy
Comparing key scaling dimensions defined by gas limit policies across Ethereum's evolution and its primary scaling solutions.
| Scaling Dimension | Ethereum Mainnet (Status Quo) | L2 Rollups (Execution Scale) | Ethereum + EIP-4844 (Data Scale) | Monolithic L1s (Alternative Scale) |
|---|---|---|---|---|
Target Block Gas Limit | 30M gas | N/A (Inherits L1) | 30M gas |
|
Effective TPS (Simple Transfer) | ~15-30 TPS | 2,000 - 10,000+ TPS | ~15-30 TPS | 3,000 - 50,000+ TPS |
Primary Constraint | Execution & State Growth | L1 Data Publishing Cost | Blob Data Bandwidth | Validator Hardware & Network |
Cost to Fill a Block (USD) | $500k - $2M+ | $50 - $500 (via L1 calldata) | $5 - $50 (via blobs) | $1k - $10k (native gas) |
State Growth Management | Gas costs for SSTORE | Forced via L1, zk-SNARK proofs | Forced via L1, Blob expiry | Often unbounded, pruning required |
Max Data per Block | ~0.1 MB (calldata) | ~0.1 MB (bound by L1) | ~1.3 MB (6 blobs @ 128 KB each) | Varies (e.g., 10-100 MB) |
Settlement Finality Anchor | Itself (PoS) | Ethereum L1 | Ethereum L1 | Itself (varies) |
Developer Strategy Shift Required | Minimize gas at all costs | Arbitrage L1 data vs. L2 execution | Batch data into blobs, use DA layers | Optimize for high throughput, manage state |
deep-dive
THE BOTTLENECK
Deconstructing The Surge: A Gas Limit Expansion Playbook
Ethereum's scalability is directly governed by its gas limit, a hard cap on computational work per block.
Gas limit is throughput. The block gas limit defines the maximum computational work per block, directly capping transactions per second (TPS). Raising it is the simplest path to higher throughput without protocol changes.
State growth is the constraint. Every transaction expands Ethereum's global state. Higher gas limits accelerate this growth, increasing node hardware requirements and centralization risk. This is the core trade-off.
EIP-4444 and statelessness are prerequisites. Client implementations like Geth and Erigon must adopt EIP-4444 to prune historical data. Full Verkle tree-based statelessness is required before the gas limit can increase significantly.
Evidence: The current ~30M gas limit supports ~15-30 TPS. A 2x increase to 60M gas would double this, but historical data bloat would grow at 400 GB/year, exceeding consumer hardware limits without EIP-4444.
risk-analysis
SCALABILITY'S HARD LIMIT
The Inevitable Trade-offs: Risks of Pushing the Gas Ceiling
Ethereum's gas limit is a security parameter, not just a throughput knob. Raising it amplifies systemic risks.
01
The State Bloat Problem
Higher gas limits accelerate the growth of the state trie, the database every node must store. This centralizes the network by raising hardware requirements for validators, pushing out home stakers.
- Exponential Growth: Each block adds more data, compounding storage costs.
- Node Churn Risk: Requires >2TB SSDs today; could demand >10TB within years if unchecked.
- Sync Time Crisis: New nodes take weeks to sync, degrading network resilience.
>2TB
Node Storage
Weeks
Sync Time
02
The Block Propagation Wall
Larger blocks from higher gas limits take longer to propagate across the peer-to-peer network. This increases the rate of reorgs and consensus instability.
- Network Latency: A 32MB block (proposed) can take ~12s to propagate vs. ~1s for current blocks.
- Reorg Risk: Slower propagation increases chances of competing blocks, threatening finality.
- Validator Centralization: Proposers with superior bandwidth (e.g., AWS) gain an advantage.
~12s
Propagation
32MB
Block Size
03
The DoS Attack Vector
A higher gas limit expands the attack surface for Denial-of-Service (DoS). Attackers can cheaply fill blocks with complex, computationally heavy transactions to cripple node performance.
- CPU Exhaustion: Complex CALL operations or SLOADs in a single block can max out validator CPUs.
- Historical Precedent: The 2016 Shanghai DoS attacks exploited low gas costs for specific opcodes.
- Security Tax: Mitigations like EIP-1559 and opcode repricing are constant, reactive battles.
100%
CPU Load
2016
Historic Attack
04
The L2 Escape Hatch
Rollups (Arbitrum, Optimism, zkSync) are the canonical scaling solution because they sidestep these trade-offs. They process transactions off-chain and post compressed proofs or data back to L1.
- Offloads Computation: L1 only verifies proofs or stores data, not executes.
- Preserves Decentralization: Base layer security remains intact with low hardware reqs.
- Economic Reality: >90% of user tx activity now occurs on L2s, proving the demand shift.
>90%
Tx on L2
10-100x
Cheaper Gas
05
The Data Availability Frontier
Even L2s push data to L1, creating a data availability (DA) bottleneck. Solutions like EIP-4844 (blobs) and EigenDA exist to raise this ceiling without the same risks.
- Blob Space: Dedicated, ephemeral data channel that doesn't bloat Ethereum state.
- Modular DA: Alt-DA layers like Celestia and Avail offer cheaper data posting for sovereign rollups.
- Key Trade-off: Security vs. cost. Using Ethereum for DA is maximally secure but more expensive.
~0.1¢
Blob Cost
128KB
Per Blob
06
The Parallel Execution Gambit
Chains like Solana and Monad attempt to raise the gas ceiling fundamentally by changing execution, not just parameters. They use parallel execution and optimized state access.
- Sealevel & MonadDB: Parallel transaction processing requires aggressive client optimization.
- Different Trade-off: Tolerates higher hardware requirements (>1Gbps net, 128GB+ RAM) for raw throughput.
- Ethereum's Path: Pectra upgrade's Verkle Trees and eventual EVM parallelization follow this cautiously.
1Gbps+
Net Req
10k+ TPS
Theoretical Peak
future-outlook
THE BOTTLENECK
The Endgame: Modular Chains and the L1 as a Settlement Co-processor
Ethereum's scaling ceiling is defined by its gas limit, which modular architectures treat as a fixed settlement resource.
Gas limit is the ceiling. Ethereum's maximum computational throughput is a hard, in-protocol constant. This defines the total settlement bandwidth available to all L2s, rollups, and validiums. The L1 becomes a co-processor for finality, not execution.
Modular design optimizes for this constraint. Chains like Arbitrum and Optimism compete for this limited L1 block space to post proofs and data. Their scaling is bounded by the cost and speed of writing to this global settlement layer.
Execution migrates, settlement consolidates. High-throughput execution moves to specialized chains like Base or zkSync, but their security and interoperability depend on Ethereum's consensus. This creates a predictable, auction-based market for L1 block space.
Evidence: The Blob Fee Market. EIP-4844 introduced blob-carrying transactions, creating a dedicated resource for rollup data. The separate fee market proves L1 scale is managed via resource segmentation, not monolithic expansion.
takeaways
THE BLOCK GAS LIMIT BOTTLENECK
TL;DR for Builders and Investors
Ethereum's scalability is not defined by TPS, but by the hard cap on computational work per block. This is the root constraint for all L1 scaling.
01
The Problem: The 30M Gas Ceiling
Every Ethereum block has a ~30 million gas hard cap. This creates a zero-sum auction for block space, directly capping network throughput and driving up transaction fees during demand spikes.\n- Fixed Supply: Blocksize doesn't elastically scale with demand.\n- Congestion Pricing: Fees are a function of gas price, not cost.\n- Throughput Cap: Limits complex DeFi interactions and mass adoption.
~30M
Gas/Block
Fixed
Supply
02
The Solution: Execution Sharding (Danksharding)
Proto-Danksharding (EIP-4844) introduces blobs—a separate data lane that doesn't compete with EVM execution gas. Full Danksharding will scale this to 64 data blobs per block, decoupling data availability from execution.\n- L2 Scaling: Enables ~100k TPS across rollups like Arbitrum, Optimism, zkSync.\n- Cost Reduction: Blob data is cheap and ephemeral, slashing L2 fees.\n- Modular Design: Ethereum becomes a secure settlement and DA layer.
64x
More Data
-90%
L2 Costs
03
The Workaround: L2 Rollups & Alt-L1s
While Ethereum scales its security layer, builders must bypass its gas limit today. Optimistic Rollups (Arbitrum) and ZK-Rollups (Starknet, zkSync) execute transactions off-chain, posting compressed proofs. Alt-L1s (Solana, Avalanche) implement different consensus and execution models to raise the base-layer limit.\n- Scalability Now: L2s offer ~100x cheaper transactions.\n- Security Trade-off: Alt-L1s sacrifice decentralization for throughput.\n- Ecosystem Fragmentation: Liquidity and users are split across chains.
100x
Cheaper Tx
Multi-Chain
Reality
04
The Investor Lens: Value Accrual Shifts
The gas limit bottleneck redirects where value is captured. Ethereum L1 becomes a high-value security and settlement hub, accruing fees from L2 proofs and high-value settlements. L2 sequencers (e.g., Arbitrum, Base) capture execution fees. Application-specific chains (dYdX, Aevo) optimize for their own use case.\n- Modular Stack: Value fragments across settlement, execution, and DA.\n- L2 Tokens: New asset class tied to sequencer revenue.\n- Infrastructure Bets: Bridges (LayerZero, Axelar) and oracles (Chainlink) become more critical.
L1 -> L2
Value Flow
Modular
Stack
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