If Ethereum Can Scale L1, Why Did We Build L2s? Glamsterdam's 100M Gas Limit Raises Hard Questions

layer2_lisa · March 22, 2026, 9:58am

I’ve been working on L2 scaling solutions for the past 6 years—first at Polygon Labs, then at Optimism Foundation, and now at a stealth startup building next-gen rollup tech. So when I read the Glamsterdam upgrade specs this week, I had a moment of existential crisis: If Ethereum can scale L1 to 100M+ gas limit with 78.6% fee reductions and 10,000 TPS, what was the point of fragmenting the ecosystem across dozens of L2s?

What’s Actually Coming in Glamsterdam

For those who haven’t dug into the technical details yet, Glamsterdam (scheduled for H1 2026, though realistically Q3/Q4) includes three major components:

1. Gas Limit Increase: 60M → 100M+ (67% capacity boost)

The Ethereum Foundation is pushing to raise the gas limit from the current 60 million to “toward and beyond” 100 million. Post-ePBS implementation, some projections suggest it could double to 200 million. That’s a massive increase in L1 throughput.

2. ePBS (Enshrined Proposer-Builder Separation) via EIP-7732

This moves proposer-builder separation into the protocol itself, reducing reliance on MEV-Boost and external relays. Builders submit block header bids, proposers select the highest bid, and accountability is enforced through on-chain staking and slashing. In theory, this decentralizes block building and hardens censorship resistance.

3. Block-Level Access Lists (BALs) via EIP-7928

This is the parallel execution piece. BALs explicitly list all state accessed/modified by each transaction, allowing clients to execute transactions in parallel. The data shows 60-80% of transactions access disjoint storage slots, meaning they can safely run concurrently. This should significantly reduce block processing time.

Combined, these changes target 10,000 TPS on L1—roughly 10x what Ethereum handles today.

The L2 Fragmentation Problem

Here’s my issue: I’ve spent six years telling developers to build on L2s because “L1 doesn’t scale.” We fragmented liquidity across Arbitrum, Optimism, Base, Polygon, zkSync, Starknet, Scroll, Linea, Mantle, Blast… I could go on.

Each L2 has:

Different execution environments (some EVM, some alt-VMs like Cairo)
Separate liquidity pools
Distinct bridge security models
Varying levels of decentralization (most sequencers are still centralized)
Incompatible developer tooling in some cases

The UX is terrible. Users need to bridge assets, manage gas on multiple networks, and navigate complex cross-chain transactions. Developers need to deploy and maintain contracts on 5+ chains just to reach meaningful liquidity.

The Hard Question: Did We Fragment Too Early?

If Ethereum can deploy BALs for parallel execution and raise the gas limit to 100M+ in H1 2026 (or realistically Q4 2026), could we have done this in 2022 or 2023?

From a pure engineering perspective, EIP-7928 for block-level access lists is elegant but not conceptually revolutionary. The insight that 60-80% of transactions touch different state and can parallelize has been known for years. We had the data. Why did it take until 2026 to prioritize this?

Meanwhile, the rollup-centric roadmap pushed developers to L2s, creating a fragmented ecosystem that may be very difficult to re-consolidate even as L1 becomes more scalable.

What I’m Struggling With

I’m not saying L2s are useless—there are still valid use cases:

Ultra-high-frequency applications (MEV bots, HFT DeFi) that need sub-second finality
Experimentation with alternative execution environments
Customized gas pricing models
Application-specific rollups

But if L1 can handle 10k TPS at 78.6% lower fees, do we really need dozens of general-purpose L2s competing for the same use cases?

And more fundamentally: Did the Ethereum roadmap prioritize the wrong things? Should L1 scaling (parallel execution, gas limit increases) have come before pushing everyone to L2s?

I Genuinely Want to Hear Other Perspectives

Especially from:

Developers building on L2s—do you regret the fragmentation?
Security researchers—is Glamsterdam being rushed?
Users—would you rather use scaled L1 or cheap L2s?
L1 maximalists—feel free to say “I told you so”

Because right now, I’m questioning whether the work I’ve done for the past 6 years accelerated Ethereum’s scaling or just created a mess we’ll spend the next 6 years cleaning up.

Reference: Ethereum Foundation Protocol Priorities Update 2026, EIP-7928, EIP-7732

ethereum_emma · March 22, 2026, 9:59am

Oh Lisa, you just articulated exactly what I’ve been feeling as a frontend developer!

I literally spend half my time managing the chaos of supporting multiple L2s. Right now I’m maintaining the same DeFi interface across 8 different networks: Ethereum mainnet, Arbitrum, Optimism, Base, Polygon, zkSync, Scroll, and Linea. Each one has its quirks:

zkSync uses a different gas estimation API
Polygon has different contract addresses for the same protocol
Base has its own bridge UX requirements
Scroll’s RPC sometimes lags behind the others

And the user confusion is real. When I was first learning DeFi in 2021, I remember trying to use a yield farm that was “on L2” and I had NO idea what that meant. I bridged my ETH to Arbitrum, then realized the pool I wanted was actually on Optimism. Bridged again. Paid fees twice. Nearly rage-quit crypto entirely.

The Frontend Developer’s Nightmare

From a purely technical perspective, managing wallet connections across chains is brutal:

// This is what my code looks like now
const SUPPORTED_CHAINS = {
  1: 'Ethereum',
  42161: 'Arbitrum',
  10: 'Optimism',
  8453: 'Base',
  // ... 5 more
}

// And I have to handle different contract addresses
const USDC_ADDRESSES = {
  1: '0xA0b8...', 
  42161: '0xFF97...',
  // Different address on EVERY chain
}

If Ethereum L1 can hit 10k TPS with 78.6% lower fees, we could consolidate back to mainnet and I could delete thousands of lines of chain-switching logic. My codebase would be simpler, users wouldn’t need to understand bridges, and liquidity wouldn’t be fragmented.

But Here’s My Question

Do you think L2s will become obsolete if Glamsterdam delivers on these promises? Or will there still be use cases where deploying on Arbitrum/Optimism makes sense even if L1 is cheap and fast?

Because honestly, as someone who wants to make DeFi accessible to regular people (my original goal when I got into this space), a unified L1 experience would be SO much better for UX. No more “which network are you on?” confusion. No more bridge hacks. No more fragmented liquidity making slippage worse.

But I also worry that I’m being naive. Maybe there are technical reasons why L2s will always be necessary that I’m missing?

Would love to hear from folks who understand the infrastructure better than I do!

defi_diana · March 22, 2026, 9:59am

Hold on—I need to push back on this “L1 will make L2s obsolete” narrative, because the math doesn’t add up for high-frequency DeFi.

The Numbers Don’t Lie

Let’s say Glamsterdam achieves its 78.6% fee reduction target. That means:

Current Ethereum L1 swap: ~$3-15 depending on congestion
Post-Glamsterdam L1 swap: ~$0.65-3.20 (78.6% reduction)
Current Arbitrum swap: ~$0.10-0.50
Current Base swap: ~$0.05-0.20

Even with the fee reduction, L1 will still be 3-10x more expensive than L2s for basic operations. And that’s assuming best-case scenarios where gas prices stay low.

For yield optimization strategies (which is literally my entire business), those cost differences matter ENORMOUSLY:

My bots rebalance positions 50-100 times per day across multiple pools
On Arbitrum, that costs ~$5-25/day in total gas
On post-Glamsterdam L1, that would cost ~$32-160/day
That’s a 6-8x increase in operating costs

At scale, this completely breaks the economics of automated yield strategies, MEV arbitrage, and high-frequency liquidation bots.

L2s Enable Things L1 Can’t

Beyond just cost, L2s provide:

1. Sub-second finality

Arbitrum and Optimism confirm transactions in ~200-400ms. Ethereum L1 is stuck at 12-second block times even post-Glamsterdam. For MEV protection and Just-In-Time liquidity provision, those milliseconds matter.

2. Customizable execution environments

zkSync and Starknet use different VMs (zkEVM, Cairo) that enable native account abstraction, privacy features, and gas optimization patterns that EVM can’t support. These aren’t just “experiments”—they’re production features serving millions of users.

3. Application-specific rollups

Imagine a DEX that runs its own rollup optimized specifically for trading (custom gas pricing, MEV protection, batch settlement). That will ALWAYS be cheaper and faster than a general-purpose L1.

The Real Question Isn’t “L1 vs L2”

The question is: What’s the right use case for each layer?

My take:

L1: High-value settlements, protocol governance, cross-L2 settlement layer
L2s: High-frequency trading, gaming, social, microtransactions, specialized apps

If Glamsterdam makes L1 cheap enough for casual users to mint NFTs and do occasional swaps, that’s great! It reduces the “bridge to L2” onboarding friction.

But professional DeFi users, developers building high-throughput apps, and anyone doing more than 5-10 transactions per day will STILL prefer L2s for the speed and cost advantages.

Did the Rollup Roadmap Backfire?

I don’t think so. I think it accelerated innovation by giving teams the flexibility to build custom execution environments while Ethereum focused on data availability and L1 security.

Yes, liquidity fragmentation is a problem. But that’s a coordination problem (which standards like ERC-7683 and shared sequencers can solve), not a fundamental architectural mistake.

The fragmentation we’re seeing now is the cost of permissionless innovation. Some L2s will die. Some will consolidate. Some will find product-market fit in specialized niches. That’s how markets work.

TL;DR: Even with 10k TPS and 78.6% fee reduction, L1 won’t be cheap or fast enough to replace L2s for high-frequency use cases. Both layers will coexist serving different needs.

security_sophia · March 22, 2026, 10:00am

As someone who has spent years finding vulnerabilities in both L1 and L2 protocols, I need to inject a dose of caution into this discussion.

Glamsterdam Introduces Significant New Attack Surfaces

1. ePBS Complexity

Enshrined Proposer-Builder Separation sounds great in theory—decentralizing block building, reducing MEV-Boost reliance. But the implementation introduces:

Builder staking mechanisms: New slashing conditions that could be exploited
On-chain block auctions: Potential for manipulation, griefing attacks, validator collusion
Payload commitment schemes: Complex cryptographic assumptions that might have edge cases

A recent arXiv paper (“Enshrined PBS in the presence of MEV”, January 2026) identified several attack vectors where colluding builders and proposers could extract excess MEV or censor transactions even under ePBS.

Has this been fully addressed? I haven’t seen definitive answers in the Glamsterdam specs.

2. Parallel Execution via BALs = Exponentially More Bugs

Block-Level Access Lists enable transactions to execute in parallel by declaring all state they touch. This is powerful, but:

Race conditions: If BAL declarations are incorrect or incomplete, parallel execution could create non-deterministic state
Validation complexity: Clients must verify that transactions’ actual state access matches their declared access lists
MEV amplification: Parallel execution creates new MEV opportunities (e.g., front-running entire batches of parallel txs)

The EIP-7928 spec mentions backwards compatibility concerns but doesn’t fully address the security implications of incorrect access list declarations. What happens if a malicious contract deliberately provides false access lists to trigger race conditions?

3. Gas Limit Increases = Bigger Attack Surface

Raising the gas limit from 60M to 100M+ means:

Longer block processing times (even with parallelization)
More complex blocks that are harder to validate
Greater DOS attack potential (e.g., filling blocks with computationally expensive operations)

We saw this with the 2016 Shanghai attacks when attackers exploited underpriced opcodes. Have all gas costs been repriced for 100M+ gas blocks? Has worst-case execution time been modeled thoroughly?

The Timeline Concerns Me

Glamsterdam is tentatively scheduled for June 2026 (realistically Q3/Q4). That’s 3-6 months away, and I haven’t seen:

Comprehensive security audits of ePBS implementation
Formal verification of BALs parallel execution guarantees
Large-scale testnets simulating 100M gas blocks under adversarial conditions

Compare this to the Merge, which had years of testing, multiple testnets, shadow forks, and extensive formal verification. ePBS and BALs are arguably MORE complex changes than switching from PoW to PoS.

Are we rushing this to address political pressure about L2 fragmentation?

L2s Have Their Own Security Issues

To be clear, I’m not defending L2s as perfect. Most L2s currently have:

Centralized sequencers (single point of failure, censorship risk)
Upgrade keys (admin multisigs that can change contract logic)
Unproven ZK circuits (bugs in prover code could enable infinite mints)
Bridge vulnerabilities (as we’ve seen with $2.8B+ in cross-chain hacks since 2022)

But at least L2 security issues are contained. A bug in Arbitrum doesn’t crash Ethereum. A vulnerability in Glamsterdam’s ePBS implementation could destabilize the entire L1.

My Recommendation

Don’t rush Glamsterdam. Better to ship in Q1 2027 with thorough testing than Q3 2026 with unknown edge cases.
Publish formal verification proofs for ePBS and BALs before mainnet deployment.
Run adversarial testnets where security researchers are incentivized (via bug bounties) to break parallel execution and ePBS.
Model worst-case scenarios for 100M+ gas blocks under attack conditions.

L1 scaling is important. But security must come first. We’re talking about a network securing hundreds of billions in value. One critical bug in Glamsterdam could be catastrophic.

I’d rather have a fragmented but secure ecosystem than a unified but vulnerable one.

Security is not a feature, it’s a process.

startup_steve · March 22, 2026, 10:00am

Y’all are having a fascinating technical debate, but can I inject some cold, hard startup reality here?

Users Don’t Care About L1 vs L2

I’m building a Web3 product right now. You know what our biggest user feedback is? It’s not “I wish this was on L2 instead of L1” or “I prefer Arbitrum over Optimism.”

It’s:

“Why did my transaction fail?”
“Why is this so expensive?”
“I sent my tokens to the wrong network and now they’re gone”
“This is too confusing, I’m going back to Coinbase”

From a product perspective, the L1 vs L2 debate is like arguing about which database to use when your product doesn’t have product-market fit yet. It’s an infrastructure question that 99% of users don’t think about.

The Timeline Problem

Sophia raised security concerns about Glamsterdam’s June 2026 timeline. As a founder, I’ll raise a different concern: It won’t ship on time.

I’ve been in this ecosystem long enough to know:

“H1 2026” means Q3/Q4 2026 at earliest
Complex protocol upgrades have scope creep
Testnets find unexpected issues
EIP implementations get delayed

So realistically, we’re looking at Q4 2026 or Q1 2027 before Glamsterdam hits mainnet. That’s 9-12 months away.

My startup cannot wait 9-12 months for Ethereum to scale. We need to ship NOW or lose to:

Solana (already handling 10k+ TPS TODAY)
Base (cheap L2 with Coinbase’s distribution)
Avalanche subnets
Whoever else has fast, cheap transactions RIGHT NOW

The Business Model Question

Diana made great points about L2s still being cheaper for high-frequency use cases. But here’s what I’m struggling with:

If Glamsterdam makes L1 “good enough” for 80% of use cases, what’s the business model for general-purpose L2s?

Arbitrum’s token is valued based on sequencer fees
Optimism’s Superchain strategy assumes L2s capture value
Base, Linea, Scroll all have economic models tied to L2 activity

If L1 becomes cheap and fast, do these L2s lose their moats? Do their tokens become worthless? Does this trigger a consolidation wave where only specialized L2s (like gaming-specific or privacy-focused rollups) survive?

Because if I’m an investor or employee at an L2 company right now, I’d be seriously worried about what Glamsterdam means for my equity value.

What I Actually Want

Forget the technical debates for a second. As someone trying to build a business, here’s what I need:

Transactions under $0.01 (for microtransactions and onboarding)
Sub-second confirmation (so users don’t wait and get frustrated)
Simple UX (one network, no bridges, no confusion)
Reliable infrastructure (no downtime, no weird RPC issues)

I genuinely don’t care if that comes from:

Scaled L1 (Glamsterdam)
Cheap L2 (Arbitrum/Base)
Alt L1 (Solana)
Entirely new solution

I just need something that works and ships so I can build my product.

The Pragmatic Take

Lisa asked if the rollup roadmap backfired. From a startup perspective, I don’t think it “backfired”—it gave us options while L1 was too expensive. But it definitely created fragmentation that hurts user experience.

My hope is that Glamsterdam AND L2s both improve, and we end up with:

L1 for high-value, security-critical operations
Fast L2s for everyday transactions
Good bridges/interop so users don’t notice the difference

But if I had to bet, I think most retail users will end up on L2s even after Glamsterdam, because:

L2s will still be 5-10x cheaper
L2s will have better UX (faster finality)
L2s will have network effects (Base has Coinbase, Arbitrum has GMX, etc.)

The real question is: will L1 scaling split the ecosystem between “L1 purists” and “L2 pragmatists”? Because that fragmentation would be just as bad as the L2 fragmentation we have now.

Anyway, just my 2 cents as someone trying to ship product in this chaotic ecosystem. Back to writing code