Your Intro to Native Rollups

Published: 2025-03

In traditional rollups, execution happens on L2, but correctness is ensured either:

Optimistically — via fraud proofs (only checked if disputed)
Or through zk-rollups — using validity proofs

Native rollups blur this line by using Ethereum's L1 execution layer to verify L2 transactions. Instead of relying on fraud or zk proofs, native rollups ask Ethereum itself to re-execute L2 transactions, ensuring correctness directly on L1.

This removes the need for external proof systems. Transactions are still processed off-chain, but Ethereum validators validate their execution, enforcing state transitions natively.

Characteristics of Native Rollups

Leverages L1 security: State transitions are verified by Ethereum itself, requiring no extra trust assumptions.
Guaranteed EVM compatibility: Native rollups are always EVM-equivalent — no need for opcode catch-up.
Programmable: Unlike static execution shards, native rollups are fully programmable.
Customizable: Each rollup can have its own fees, governance, and sequencer setup.
Non-EVM support possible: With a translation layer, native rollups could even support non-EVM logic (though with greater effort).

Benefits

Fewer points of failure: Less reliance on governance upgrades to maintain compatibility with Ethereum.
Composability: L1 can validate and interact directly with L2 state. Rollups can interoperate as if on the same chain.
Improved network effects: A unified ecosystem drives better UX and more integrated tooling.
Simplicity: Native rollups reuse Ethereum logic via the EXECUTE precompile — reducing code complexity and bugs.

What Do Native Rollups Need?

EXECUTE Precompile

A hard fork is required to introduce a precompile contract called EXECUTE, exposing the EVM engine to the application layer. This lets an L2 submit a batch of transactions to Ethereum, which then verifies the resulting state.

The execute() function takes:

Pre-state root (current state)
Post-state root (after L2 batch)
Transaction trace
Gas used

If Ethereum accepts the state transition, it finalizes the batch with the same certainty as an L1 transaction.

Gas Accounting for EXECUTE

Justin Drake proposed a separate gas regime for EXECUTE calls, with a per-block gas limit for rollup execution. The cost is dynamic — GAS_PRICE adjusts based on block demand and total EXECUTE usage.

Possible Need: EIP-7862

EIP-7862 proposes that a block's ExecutionPayload references the post-state root of the previous block. This change would give rollup proposers 12 extra seconds to complete state verification.

For native rollups, this means:

A rollup's batch could be included in block N
Its final state root is confirmed in block N+1

This levels the playing field between provers and avoids giving unfair speed advantages to specific validators.

Better Proving

As rollups go native and transaction load increases, improving proof generation becomes key to scalability. ZK rollups with faster provers or hardware acceleration (like ASICs) can help shift L1 validation from re-execution to lightweight zk-proof verification.

Call Data Throughput Enhancements

Native rollups still depend on L1 for data availability. Optimizing calldata costs and throughput helps ensure rollups post data efficiently and cost-effectively.