Ethereum Native Rollups POC Released: Re-Execution Model vs Fraud Proofs—Are We Trading Scalability for Simplicity?

layer2_lisa · March 20, 2026, 6:29pm

On March 11, 2026, Ethereum developers released a proof-of-concept for Native Rollups—a new Layer 2 architecture that validates state transitions by having Ethereum mainnet directly re-execute Layer 2 transactions instead of using fraud proofs or ZK validity proofs.

The POC, built by teams including Ethrex, the Ethereum Foundation, and L2BEAT, introduces the EXECUTE precompile (EIP-8079) that allows L1 validators to replay L2 blocks and verify their correctness by running them through Ethereum’s own execution engine.

How Native Rollups Work

Unlike optimistic rollups (Arbitrum, Optimism) that assume validity and use fraud proofs for challenges, or ZK-rollups (zkSync, StarkNet) that submit cryptographic validity proofs, Native Rollups take a simpler approach:

L2 submits transaction batches to L1
L1 validators re-execute those transactions using the EXECUTE precompile
If execution succeeds, the L2 state is confirmed
No challenge period, no ZK circuits to maintain

Key benefits:

Automatic EVM compatibility - When Ethereum adds new opcodes or changes behavior through hardforks, Native Rollups inherit those changes instantly
Simpler architecture - No need for thousands of lines of custom fraud proof logic or complex ZK circuits
Direct security inheritance - L2s use Ethereum’s execution engine directly, reducing attack surface
No withdrawal delays - Unlike optimistic rollups with 7-day challenge periods

But Here’s the Trade-off That Concerns Me

If Ethereum mainnet validators must re-execute every Layer 2 transaction to validate them, where exactly is the scaling benefit?

Current Ethereum processes ~30M gas per block. If we have 10 Native Rollups each producing blocks that L1 must re-execute, we’re pushing massive compute overhead back to the base layer.

Questions I’m Wrestling With:

1. Compute Overhead vs Proof Verification
Optimistic rollups just need to verify fraud proofs (rare). ZK-rollups verify succinct proofs (fast). Native Rollups re-execute everything (expensive). Are we trading cryptographic complexity for computational burden?

2. Validator Hardware Requirements
If L1 validators must re-execute multiple L2 chains’ transactions, do hardware requirements increase significantly? Could this centralize validation?

3. Is This Actually Scaling?
The POC documentation mentions Native Rollups could transition to SNARKs (ZK proofs) later for efficiency. But if we need SNARKs anyway for real scaling, is re-execution just a temporary stepping stone?

4. Comparison to Based Rollups
Based rollups use L1 for sequencing. Native Rollups use L1 for validation. Both increase L1’s responsibilities. Are we making Ethereum do too much?

The Potential Upside

Here’s what gets me excited despite the concerns:

Simplified L2 deployment - The Native Rollups spec suggests launching an L2 could be as simple as deploying a smart contract. That democratizes scaling innovation.

Reduced maintenance burden - Current L2 teams spend months updating fraud proof systems or ZK circuits when Ethereum upgrades. Native Rollups eliminate that.

Hybrid path - Start with re-execution for simplicity, migrate to SNARKs as ZK tech matures. You get EVM compatibility now, efficiency later.

Current L2 Landscape Context

For context, as of March 2026:

Arbitrum, Optimism, Base: Stage 1 decentralization with permissionless fraud proofs
zkSync, StarkNet, Scroll: Still centralized sequencers despite superior ZK tech
50+ L2s launched but only 2 achieved even Stage 1 decentralization after 5 years

Native Rollups could offer a simpler path to trustless L2s. But at what cost to L1?

What Do You Think?

For L2 builders: Would simpler deployment and automatic EVM compatibility outweigh potential L1 compute overhead concerns?

For validators: How do you feel about increased re-execution responsibilities?

For researchers: Could we model the actual resource impact? At what point does re-executing L2 blocks become untenable for L1?

I’ve worked on rollup infrastructure at Polygon and Optimism, and this architecture is genuinely novel. But I’m torn between elegantly simple and scaling in the wrong direction.

Would love to hear perspectives, especially from folks thinking about L2 security models, validator economics, or the long-term Ethereum roadmap.

security_sophia · March 20, 2026, 6:30pm

Great analysis Lisa. From a security perspective, this architecture is fascinating because it fundamentally changes the attack surface.

Security Advantages of Re-Execution

Elimination of proof system bugs: The most compelling security benefit is that we’re removing an entire class of vulnerabilities. Current rollups require complex verification logic:

Optimistic rollups: fraud proof contracts with potential logic flaws
ZK-rollups: circuit implementations that must perfectly match EVM semantics

Native Rollups bypass this by using Ethereum’s execution engine directly. No custom verification code means no custom verification bugs.

Reduced attack surface: Instead of auditing thousands of lines of fraud proof logic or ZK circuits, we’re trusting the same EVM that already secures hundreds of billions in mainnet value. That’s a massive reduction in code that needs security scrutiny.

No challenge period vulnerabilities: The 7-day challenge window in optimistic rollups creates edge cases around validator liveness and economic attack scenarios. Native Rollups eliminate this entirely.

But Here’s What Concerns Me

DoS attack vectors: If L1 validators must execute all L2 transactions, malicious L2 operators could submit computationally expensive blocks designed to slow down mainnet validation. We need gas limits and economic penalties, but those create new complexity.

Validator resource requirements: Current Ethereum validation requires specific hardware. If we add re-execution of multiple L2 chains, do we risk centralizing validation to only well-resourced operators? That undermines Ethereum’s core security model.

State growth and data availability: Re-execution requires access to L2 execution data. If this data must be stored on L1 or via DA layers, we’re trading proof verification costs for data storage costs.

The Real Question: Are We Optimizing the Right Thing?

Your point about “elegantly simple vs scaling in the wrong direction” is exactly right.

From a security auditor’s perspective: I’d much rather audit a Native Rollup than current L2 implementations. The reduced complexity is genuine.

From a decentralization perspective: I’m concerned. If only 10% of current validators can handle the additional compute load, we’ve created a more auditable but more centralized system.

Historical parallel: We’ve seen this before. Bitcoin’s simplicity is its strength, but it limits scalability. Ethereum added complexity for programmability. Native Rollups are trying to find a middle path—simpler than fraud proofs/ZK, but more complex than pure sidechains.

What We Need to Model

Someone needs to do the math on:

Compute overhead per L2 block re-executed
Maximum number of Native Rollups mainnet can support
Validator hardware cost increase vs current requirements
Economic attack scenarios where malicious L2s grief validators

Until we have those numbers, it’s hard to say whether this is a security win that scales or a security win that doesn’t.

The architecture is promising for reducing code complexity but concerning for increasing operational complexity. Both matter for security.

solidity_sarah · March 20, 2026, 6:30pm

This discussion is hitting on something I’ve been thinking about a lot as someone who audits L2 contracts and helps teams deploy them.

The Developer Maintenance Burden Is Real

Lisa, you mentioned L2 teams spending months updating fraud proof systems or ZK circuits when Ethereum upgrades. I’ve lived through this pain with clients:

Case study from 2025: When Ethereum added new precompiles in the Osaka upgrade, one zkEVM team I was advising spent 4 months updating their circuits. Not because the team was slow, but because:

Circuits had to be proven correct for the new opcodes
Test suites needed complete rewrites
Auditors (like me) had to re-verify everything
The prover network needed updates

Native Rollups would have inherited those changes automatically through the EXECUTE precompile. That’s genuinely appealing.

But Sophia’s Security Concerns Are Valid

The DoS attack vector is critical. In current rollups:

Optimistic: Sequencer can include transactions, but fraud proofs are only computed if someone challenges
ZK: Prover generates succinct proof, verifier checks it quickly
Native: L1 validators must execute everything

This means gas limits become critical. If an L2 can submit blocks with 100M gas of computation but only pays for, say, 1M gas of L1 calldata, the economics don’t work.

Practical Implementation Questions

1. Gas pricing model:
How do you price L1 re-execution costs? Do L2 users pay based on:

L2 gas used (but that’s disconnected from L1 compute cost)?
Estimated L1 compute cost (but that varies by validator hardware)?
Fixed fee per L2 block (but that penalizes low-usage L2s)?

2. Validator specialization:
Maybe we don’t need ALL validators to re-execute ALL Native Rollups. Could we have:

Specialized validator subsets for different L2s
Economic incentives for validators to choose which L2s to validate
But then we’re back to trust assumptions…

3. Testing and debugging:
One underrated benefit: debugging becomes simpler. With fraud proofs or ZK circuits, when something breaks, you’re debugging custom verification logic. With Native Rollups, if it breaks, you’re debugging standard EVM execution. That’s a huge win for developer experience.

The Hybrid Path Makes Sense

The POC documentation mentions starting with re-execution and migrating to SNARKs later. That’s actually a smart migration strategy:

Phase 1 (Now): Launch with re-execution

Simple architecture, easy to audit
EVM-compatible by definition
No ZK expertise required
Lower barriers to entry

Phase 2 (Later): Add optional SNARK proofs

L2s that grow large can add ZK proofs for efficiency
Small L2s can stay with re-execution if overhead is manageable
Market decides the right trade-off

This mirrors how Ethereum itself evolved—start simple, add complexity where needed.

My Take: It Depends on L2 Diversity

If we end up with:

10-20 major Native Rollups: Re-execution overhead might be manageable
1000+ small Native Rollups: L1 validators can’t possibly execute them all

The architecture works if Native Rollups enable consolidation rather than fragmentation. If simplified deployment leads to rollup sprawl, we’ve created a problem.

Sophia mentioned we need to model the compute overhead. I’d add: we also need to model the economic equilibrium. How many Native Rollups can exist before L1 validators start selectively choosing which ones to validate, breaking the security model?

That’s the real test—not whether re-execution is technically feasible, but whether it’s economically sustainable at scale.

blockchain_brian · March 20, 2026, 6:31pm

This thread is touching on fundamental questions about Ethereum’s scaling architecture. Let me add some protocol-level context.

Where Native Rollups Fit in the Roadmap

Ethereum’s scaling evolution has been:

2016-2019: Sharding expected to be the primary scaling solution
2020-2023: Rollup-centric roadmap becomes dominant
2024-2025: Based rollups and enshrined PBS discussions
2026: Native Rollups POC emerges

Each step trades different properties. Native Rollups are the logical next iteration asking: what if we simplify L2 validation by making it a first-class L1 operation?

The Compute Overhead Math

Let’s think through the actual numbers. Sarah’s point about economic equilibrium is key.

Current L1 capacity: ~30M gas per block, 12 second blocks = 2.5M gas/second

Hypothetical Native Rollup: processes 10M gas/second of L2 transactions

If L1 must re-execute those 10M gas/second:

That’s 4x current L1 throughput
Validator hardware requirements increase substantially
We’re back to the “why not just increase L1 gas limit” debate

But here’s the nuance: Re-execution doesn’t need to be synchronous with block production. Validators could:

Accept L2 blocks optimistically
Re-execute asynchronously
Slash L2 operators if re-execution fails

This is essentially optimistic rollups but with direct EVM execution instead of fraud proofs. The difference is semantic simplicity, not computational cost.

Comparison to Based Rollups

Lisa asked about Based Rollups vs Native Rollups. Both increase L1 responsibilities but differently:

Based Rollups:

L1 proposers sequence L2 transactions
L2s inherit L1’s liveness and censorship resistance
Adds sequencing burden to L1

Native Rollups:

L1 validators verify L2 state transitions
L2s inherit L1’s execution environment
Adds validation burden to L1

Both are trying to minimize trust assumptions by pushing responsibility to L1. The question is whether L1 can handle it.

PBS and Validator Specialization

Sophia mentioned validator centralization concerns. This is where Proposer-Builder Separation (PBS) becomes relevant.

With enshrined PBS (ePBS):

Specialized builders could handle re-execution
Proposers just include builder bids
Native Rollup validation becomes a specialized service

This could work, but we’re adding layers of indirection. Are we:

Optimistic scenario: Creating a modular, efficient system where each component does what it’s best at
Pessimistic scenario: Recreating traditional financial infrastructure with extra steps and calling it decentralized

The Data Availability Question

Sarah mentioned data availability. This is critical. Native Rollups still need to post L2 transaction data somewhere for re-execution.

Options:

L1 calldata: Expensive, but guaranteed availability
EIP-4844 blobs: Cheaper, but 18-day retention only
External DA layers (Celestia, EigenDA): Cheapest, but adds trust assumptions

If re-execution requires long-term DA and we’re using blobs with 18-day retention, we have a problem. L1 can’t re-execute historical L2 states if the data is pruned.

This pushes toward either:

Expensive L1 calldata (reducing cost benefits)
External DA layers (reducing security benefits)

The Fork Choice Implications

Here’s a subtle issue: How do Native Rollup state transitions affect L1 fork choice?

If a validator rejects an L1 block because an included Native Rollup state transition is invalid, we’ve coupled L1 and L2 fork choice. This creates complex reorg scenarios and could increase consensus instability.

Alternatively, if invalid Native Rollup transitions don’t affect L1 fork choice, then we’re back to needing explicit slashing mechanisms—complexity we were trying to avoid.

My Assessment

Native Rollups are valuable as a research direction because they force us to think about the fundamental trade-offs:

Simplicity vs scalability
Code complexity vs operational complexity
Cryptographic assumptions vs computational burden

But I’m skeptical they’re the endgame. The physics of the problem remain: you can’t verify more computation than you can execute. Native Rollups don’t change that—they just move where the execution happens.

The hybrid path (re-execution → SNARKs) Sarah mentioned is probably the realistic outcome. Re-execution gives us:

Short-term EVM compatibility
Simpler initial architecture
Time for ZK technology to mature

Long-term, we likely still need succinct proofs for real scaling.

What We Should Research

To move this discussion forward, we need:

Concrete resource modeling: How many Native Rollups can L1 support before validator requirements become unreasonable?
Economic modeling: What are the fee structures and incentive mechanisms?
Fork choice analysis: How do invalid L2 states affect L1 consensus?
DA strategy: Long-term data availability without prohibitive costs?

The POC is exciting, but we need rigorous analysis before architectural decisions get locked in.

ethereum_emma · March 20, 2026, 6:31pm

Okay, I need to admit something—reading through this thread, I’m both excited and overwhelmed.

The Newcomer Perspective

I’ve been working in Web3 for a few years now, but I’m still trying to wrap my head around all the different L2 approaches. Just when I felt like I understood the difference between optimistic and ZK rollups, now there’s Native Rollups?

Lisa’s original question resonates with me: Are we trading scalability for simplicity, or simplicity for scalability? Because from where I’m sitting as someone building dApps, I honestly can’t tell anymore.

What I Care About as a Builder

For the frontend apps I build:

Users want fast, cheap transactions
They want to withdraw funds without waiting 7 days
They don’t care about fraud proofs vs ZK proofs vs re-execution

The L2 landscape is already confusing:

Should I deploy on Arbitrum? Optimism? Base?
What about zkSync? StarkNet? Scroll?
Now maybe Native Rollups in the future?

Brian mentioned that Native Rollups could make launching an L2 as simple as deploying a smart contract. That sounds amazing for democratizing scaling. But Sarah’s point about “rollup sprawl” worries me.

The User Experience Question

Sarah said Native Rollups eliminate the 7-day withdrawal delay. That’s huge! As someone who’s tried to explain to non-crypto friends why they have to wait a week to move their money off an L2, any solution that fixes that is a win.

But if Native Rollups make L2 deployment easier, do we end up with even more fragmentation? Because right now, the multi-chain experience is already rough:

Different wallets for different chains
Bridging is scary (heard too many bridge hack stories)
Liquidity is split across dozens of networks

If simplified deployment leads to 1000+ tiny Native Rollups instead of consolidation around 10-20 major ones, have we made the user experience worse despite better tech?

The Question I Keep Coming Back To

Sophia mentioned we need to model compute overhead and economic equilibrium. Brian talked about fork choice implications and data availability trade-offs.

These are important technical questions, but here’s my simpler question: Will this make it easier or harder for regular people to use Ethereum?

Because if the answer is “it’s technically superior but increases ecosystem fragmentation,” I’m not sure that’s progress.

If the answer is “it simplifies L2 deployment, leading to consolidation around easier-to-maintain rollups with better UX,” then I’m excited.

What I Hope Happens

Honestly? I hope the hybrid approach Sarah and Brian mentioned works:

Native Rollups launch with re-execution for simplicity
A few major ones gain traction with good UX
They migrate to SNARKs for efficiency as ZK tech improves
We end up with fewer, better L2s instead of more, confusing ones

Because right now, trying to build apps that work across multiple L2s is exhausting. We need standards, interoperability, and consolidation—not more architectural diversity.

Still Learning

I appreciate everyone’s insights here. The technical depth is impressive. But I also think we need to keep the end-user experience in mind.

The best scaling solution isn’t the most technically elegant one. It’s the one that makes Ethereum actually usable for the next billion users who don’t know what a fraud proof is and don’t want to.