Native Rollups POC Released—Are Optimistic Rollups Already Obsolete?

General
1

On March 11, 2026, Ethereum developers dropped a proof-of-concept that could fundamentally change how we think about Layer 2 scaling. The Native Rollups prototype, implementing EIP-8079, introduces an EXECUTE precompile that allows Ethereum L1 to directly validate Layer 2 state transitions by replaying L2 blocks on the base layer.

What’s Different About Native Rollups?

Instead of relying on fraud proofs (Optimistic Rollups) or validity proofs (ZK Rollups), Native Rollups take a remarkably straightforward approach: just replay the L2 blocks on L1 itself. The L1 confirms validity by re-executing the transactions rather than verifying cryptographic proofs.

According to the technical announcements, the POC includes:

  • EXECUTE precompile via EIP-8079 for L2 block replay
  • Smart contracts to track rollup state
  • Bridge contracts for cross-layer messaging
  • Merkle Patricia proof verification for withdrawals

The participating teams include Ethrex, the Ethereum Foundation, and L2BEAT.

The Potential Benefits Are Massive

If this works at scale, we could see:

  1. Instant finality: No more 7-day withdrawal delays from Optimistic Rollups
  2. Reduced trust assumptions: L1 directly validates instead of trusting external proofs
  3. Native L1/L2 composability: Tighter integration between layers
  4. Security inheritance: True Ethereum security without fraud proof windows

But Here’s My Concern…

We’ve spent three years building Optimistic Rollup infrastructure. Arbitrum has $18B in TVL. Optimism Superchain is being adopted by Base (Coinbase), Mode, and others. Thousands of developers have built on this architecture.

As someone who worked at both Polygon Labs and Optimism Foundation, I’ve seen the enormous engineering effort that went into making Optimistic Rollups production-ready. The fraud proof systems, the challenge mechanisms, the sequencer infrastructure, the bridge security—all of this was hard-won knowledge.

So I Have Some Real Questions

1. Is this Optimistic Rollup obsolescence?
If L1 can natively validate L2 state, why did we spend years building trust-minimized systems with fraud proofs? Was Optimistic Rollup architecture just a stopgap solution?

2. What’s the migration path?
Do existing L2s like Arbitrum and Optimism need to rebuild from scratch to adopt Native Rollups? What happens to deployed contracts and user funds during migration?

3. Will this create more fragmentation?
We already have 90% of Ethereum users on L2s spread across multiple chains. If some L2s migrate to Native Rollups while others don’t, does this make interoperability even worse?

4. Is this actually production-ready?
The announcement says it’s “early exploration and not yet live.” How many years until this is battle-tested enough for mainnet? Can L1 handle replaying all L2 blocks without creating congestion?

The Trade-offs We Need to Discuss

From my scaling experience, I know every approach has trade-offs:

  • Performance: Can L1 validators handle re-executing all L2 transactions? What’s the computational overhead?
  • Decentralization: Does this make running L1 nodes more expensive if they must replay L2 blocks?
  • Developer experience: How different is the programming model? Do we need new tooling?
  • Economic model: How does this affect L2 sequencer revenue and L1 validator incentives?

Looking for Perspectives

I’m genuinely torn on this. The engineer in me loves the elegance of L1 directly validating L2 state. No fraud proof windows, no complex ZK circuits, just straightforward block replay.

But the pragmatist in me worries we’re introducing yet another L2 paradigm when we haven’t even solved interoperability between existing approaches. And the realist in me knows that production-ready systems take years, not months.

For those who’ve read the technical details: What am I missing? Are there security concerns with the EXECUTE precompile approach? How does this handle L2 blocks that fail execution when replayed on L1?

For protocol developers: Would you bet your next project on Native Rollups or stick with proven Optimistic/ZK approaches?

For users: Would instant withdrawals alone justify the ecosystem waiting for Native Rollups to mature?

I want to be excited about this, but I also don’t want to see us chase the newest shiny thing while abandoning infrastructure that’s already working at scale.

What do you all think?

2

Lisa, this is a brilliant breakdown of the trade-offs. As someone who’s been contributing to Ethereum core development and building zkEVM implementations, I share both your excitement and concerns.

The Technical Elegance Is Real

The EXECUTE precompile approach is genuinely clever. Instead of the complexity of:

  • Fraud proof systems (Optimistic Rollups) that require watchers, challenge periods, and bond mechanisms
  • ZK proof circuits (zkRollups) that need specialized cryptography and heavy computational overhead

We get direct L2 block replay on L1. It’s almost too simple, which makes me both excited and cautious.

But Here’s What Keeps Me Up at Night

1. Performance and Resource Constraints

The key question nobody seems to be asking: Can L1 validators actually handle this?

If we’re replaying every L2 block on L1:

  • What’s the computational overhead per L1 block?
  • How many L2 chains can one L1 support before validator hardware requirements become prohibitive?
  • Does this make running an Ethereum node significantly more expensive, thus reducing decentralization?

Remember, we moved to L2s precisely because L1 couldn’t handle the throughput. Now we’re asking L1 to execute not just L1 transactions, but also validate L2 state by re-running all L2 blocks? The math needs to work.

2. Security Attack Surface

The EXECUTE precompile introduces new attack vectors we haven’t fully explored:

What happens when L2 block execution fails on L1?

  • Does the L2 chain halt until the issue is resolved?
  • Can malicious sequencers submit blocks that pass L2 validation but fail L1 replay?
  • How do we handle consensus if validators disagree on L2 block validity?

State transition edge cases:

  • L2 might use different gas limits, precompiles, or EVM opcodes
  • What if L2 and L1 execution environments drift over time?
  • How do we ensure L2 blocks remain L1-executable through future forks?

3. Historical Precedent

I’ve been in this space long enough to remember when Plasma was supposed to solve everything. Then state channels. Then sidechains. Each had elegant theoretical properties that ran into practical challenges.

Native Rollups are in the “looks great on paper” phase. We need extensive formal verification, security audits, and real-world stress testing before betting production systems on this.

What I’d Need to See

Before I’d recommend building on Native Rollups:

  1. Performance benchmarks: Real numbers on validator overhead with 5, 10, 50 L2s using Native Rollups
  2. Security audit: Formal verification of the EXECUTE precompile and state transition logic
  3. Migration path: Clear technical plan for how Arbitrum/Optimism could adopt this
  4. Economic model: How does this affect ETH staking yields and L2 sequencer economics?

My Take

I think Native Rollups are important research that could eventually replace Optimistic Rollups if the performance constraints can be solved. The 7-day withdrawal window is genuinely painful for users and capital efficiency.

But for production systems today? I’d still build on proven Optimistic or ZK Rollup infrastructure. The ecosystem has B+ in TVL on these systems. They work. They’re battle-tested.

Native Rollups need to prove they can match this security and reliability before we start migrating critical infrastructure.

@layer2_lisa - Have you seen any performance benchmarks from the Ethrex team? Specifically, how many L2 transactions per second can L1 validate through replay without increasing block times or validator requirements?