Native Rollups: the Future of Ethereum L2 Architecture

Previous articles in this series:

Gelato's Guide to Avalanche L1s and Native Interoperability

L1 Blockchain Stacks: Avalanche vs Cosmos

Rollup L1s: How ABC Stack's Celestia Sovereign Rollup L1s Compare to Avalanche and Cosmos L1 blockchains

OP Stack vs. Arbitrum Orbit: The Best L2 Rollup Comparison

Beyond Optimistic Rollups: ZK Rollups and zkVMs

TL;DR

● What are Native Rollups? Native Rollups are a new Ethereum scaling model proposed by Justin Drake. They use Ethereum's built-in execution engine via the EXECUTE precompile, eliminating the complex custom verification systems that current rollups rely on.

● What is the EXECUTE precompile and why is it important? This core innovation lets rollups automatically inherit future EVM upgrades and ensures alignment between L1 and L2 execution. It compresses complex rollup logic into a single call that validators can re-execute or verify using zk-proofs.

● How are they different from Optimistic and ZK Rollups? Unlike current rollups that require thousands of lines of custom code and centralized fallback mechanisms, Native Rollups use Ethereum’s core engine directly. They validate state transitions via re-execution (simple but compute-heavy) or SNARKs (efficient but complex), starting with re-execution until zk tech matures.

● What role does Attester-Proposer Separation (APS) play? APS separates beacon proposers (consensus) from execution proposers (block execution), giving execution proposers a full 12 seconds to generate SNARK proofs. Backup "altruistic provers" fill gaps when needed to ensure liveness. But it’s important to note that the latest Same-Slot Proof design eliminates altruistic prover dependencies through self-proving blocks and no-op execution fallbacks.

● How does stateless verification reduce validator overhead? Validators rely on transaction-included state proofs rather than storing the full blockchain state. This shifts validation from a storage-heavy to a computation-focused process while preserving trustlessness.

● Why are Native Rollups Ethereum's scaling endgame? They blur the lines between L1 and L2, enabling seamless cross-rollup interaction and extending Ethereum’s security guarantees to L2s. While deployment likely won’t happen before 2026 due to gas limits and data overhead, they represent Ethereum’s long-term, unified scaling vision.

Today's EVM-equivalent rollups are fundamentally insecure and complex. They require thousands of lines of custom code for fraud proof games or SNARK verifiers that likely contain vulnerabilities, particularly within proving circuits, where incorrect opcode implementations can result in invalid state transitions being cryptographically accepted as correct. To compensate, most rollups rely on centralized sequencing and security councils as safeguards. They also can't maintain true EVM equivalence because they need governance to manually implement Ethereum upgrades, and expensive onchain SNARK verification forces infrequent settlement.

What are Native Rollups and how they’re the solution

Native Rollups represent a game-changing approach to Ethereum scaling, building on ideas that have evolved within the Ethereum R&D community since 2017. It uses a proposed EXECUTE precompile that exposes Ethereum's native EVM execution engine directly to rollups. Instead of building custom verification systems, rollups simply call this precompile with their transaction traces, and Ethereum validators re-execute or verify proofs offchain using diverse zkEL clients.

As Justin Drake put it: "One can think of Native Rollups as 'programmable execution shards' that wrap the precompile within a derivation function to handle extra-EVM system logic, e.g. sequencing, bridging, forced inclusion, governance."

EXECUTE is fundamentally about enabling trustless rollups through L1 security inheritance and eliminating complex custom verification systems, not about making execution computationally cheaper per se. The cost benefits are secondary and come from batching efficiencies and potential subsidization, not from the precompile being inherently more efficient at the computational task.

To understand how Native Rollups achieve this dramatic simplification, we need to examine the technical foundation that makes it all possible: the EXECUTE precompile.

Optimistic Native Rollups vs ZK Native Rollups

Optimistic Native Rollups can use cheap data availability like Celestia for normal operations, only requiring expensive Ethereum DA during fraud disputes. They can process arbitrarily large batches since EXECUTE precompile only verifies small disputed segments during challenges, not entire batches. Users must wait through challenge periods for finality.

ZK Native Rollups on the other hand, must store all transaction data on Ethereum DA since validators need immediate access to execution traces. They're constrained by EXECUTE_CUMULATIVE_GAS_LIMIT for batch sizes but achieve real-time settlement (one-slot delayed execution) without requiring the ultra-fast proving that current ZK rollups need.

The speed advantage of ZK Native Rollups creates major cost savings and unlocks new capabilities. Fast finality enables capital-efficient bridging protocols like Across, where market makers provide instant liquidity without extended fund lockups, dramatically reducing bridging fees that often offset ZK rollup premiums. Real-time proving also enables seamless cross-rollup composability and completely trustless bridging, where users bridge directly through ZK interoperability rather than relying on third-party attestation bridges with their trust assumptions and delays.

While optimistic native rollups have lower operational costs, their slow finality introduces hidden costs like capital lock-up during challenge periods, increased bridging fees due to delayed settlement, and reduced capital efficiency across applications. When accounting for these indirect costs, ZK native rollups often prove more economical despite their higher upfront operational expenses.

But, this assumes EXECUTE's primary value is execution efficiency. If the real cost savings come from batching EXECUTE calls using SNARK recursion, optimistic native rollups could abandon complex fraud proofs for simple re-execution, becoming far more competitive. Without knowing how much batching reduces costs versus current rollup verification, it's hard to determine which native rollup approach is actually more economical long-term.

The EXECUTE precompile function is designed to expose the Ethereum L1 execution engine to applications.

It takes four inputs: pre_state_root (the starting state), post_state_root (the resulting state), trace (the execution details), and gas_used (computational resources consumed).

When called, the precompile processes the provided trace beginning from the starting state and confirms that it produces exactly the claimed ending state while consuming precisely the specified amount of gas.

An EIP-1559-style mechanism meters and prices the cumulative gas consumed across all EXECUTE calls in an L1 block, with parameters for cumulative gas limit and target to manage resource usage.

State transition and stateless verification

State transition is the process of moving from one blockchain state to another by executing transactions. Each transaction changes the blockchain's state such as updating account balances, modifying contract storage, or creating new accounts.

Stateless verification is a method where validators can confirm the correctness of these state transitions without maintaining a full copy of the blockchain's state. Instead of storing all account balances and contract data locally, validators receive state access proofs (cryptographic proofs) that demonstrate what the relevant state values were before and after transactions.

Why is stateless verification important for Native Rollups?

Stateless verification enables efficient validation of state transitions for Native Rollups. Rather than requiring validators to store complete blockchain state to verify transitions, they can use provided proofs to reconstruct only the specific state data needed for verification. This transforms state transition validation from a storage-intensive process to a computation-focused one.

This is crucial because state storage is the most expensive resource for Ethereum validators. With ZK proofs, Native Rollup computation becomes extremely cheap as validators simply verify compact cryptographic proofs rather than re-executing entire state transitions step-by-step, making rollup validation dramatically more efficient.

Implementation in Native Rollups

Native Rollups will launch with a phased verification approach that evolves as ZK technology matures:

1. Simple Re-execution (launch strategy): Validators directly rerun the rollup's transactions to check correctness. This approach is straightforward but limited by validator computational resources.

2. SNARK Verification (long-term vision): Instead of re-executing everything, validators check compact mathematical proofs. This dramatically increases throughput while reducing computational overhead. As ZK proving becomes faster and cheaper, SNARK verification will likely fully replace re-execution as the primary verification method.

An intermediate approach could use optimistic assumptions with ZK fault proofs for disputes, similar to current optimistic rollups but with cryptographic proofs instead of fraud proof games. However, this becomes less attractive as ZK proving costs decrease and proving speeds increase, since the main benefit of optimistic approaches is avoiding proof generation overhead, but at the cost of introducing a lot of slowness into the system (challenge periods) which can introduce its own costs, like capital inefficiencies for bridging assets in and out of the rollup.

It's unclear how Native Rollup bridges will handle state transitions. Current L2s post proofs onchain for smart contract verification, but since Native Rollup proofs are verified offchain by validators, additional onchain verification for bridge interoperability remains an open design question.

Through stateless verification, while validators don't store rollup state long-term, they still must temporarily hold an explicit copy of trace because blob data is only sampled via DAS, not fully downloaded, but validators need complete trace access to verify EXECUTE calls. For re-execution enforcement, they use this trace to re-execute the computation themselves. This creates additional DA overhead compared to traditional optimistic rollups, which only need state access proofs during fraud proof challenges rather than for every state transition verification. For SNARK enforcement, they use the trace to verify it is well-formatted while relying on cryptographic proofs for correctness.

For SNARK enforcement, execution proposers generate and share proofs offchain via peer-to-peer networks, with validators only attesting to new execution blocks if valid proofs exist for the previous block. Native rollups use the EXECUTE precompile to verify their state transitions by calling it with execution traces and the precompile returns true if the trace correctly transforms the pre-state to post-state.

How do validators actually verify these proofs?

There is no common ZK proof format. ZK proofs remain completely offchain and non-standardized, each validator can use whatever ZK proof system and format they want from teams they trust. What Ethereum's consensus layer standardizes is only the format for state access proofs (the Merkle proofs showing which state was read/written), not the ZK proof verification implementation details.

The key point is that different validators could make different choices. Some might use Succinct, others Risc0, others entirely different proving systems and they'd all be participating in the same network. As long as they can all verify that the EXECUTE call correctly transitions from the pre-state to post-state, the system works.

Because proofs are not standardized or enshrined in consensus, multiple proof formats may need to be generated for the same execution trace, one for each zkEL client used by validators. Validators don’t verify each other’s proofs but instead, they verify traces independently using their chosen client.

This design does create a potential minority zkEL problem where some validators using less popular proof systems might rely on altruistic provers to generate compatible proofs, though the proposal suggests this is manageable. Is this complexity and sacrifice of simplicity really necessary to avoid technology lock-in? Or maybe we’ll see the development of a unified ZK proof specification that can allow different proving systems to implement the same proof format similar to how Ethereum execution clients work today?

How Ethereum Consensus Works Today

Before diving into Attester-Proposer Separation (APS), it's important to understand how Ethereum's current consensus mechanism operates with proposers and attesters.

Current Ethereum consensus roles

In Ethereum, validators take turns being "proposers" (who select blocks and earn rewards) while committees of other validators act as "attesters" (who vote on block validity to finalize the chain). Today, when a validator is selected as proposer, they receive both small consensus rewards and potentially massive execution rewards (from MEV and fees).

Even though most proposers now use PBS (Proposer-Builder Separation) via MEV-Boost to outsource block building, they still receive all the execution rewards. While PBS was designed to keep proposers decentralized by removing the need for sophisticated block-building infrastructure, in practice some actors are running vertically integrated builder-proposer operations that can outcompete pure proposers who simply select from external builders. This creates pressure for validators to become sophisticated builder-proposers themselves to remain competitive, undermining PBS's decentralization goals.

Understanding Attester-Proposer Separation

With APS, instead of beacon proposers getting execution rewards when it's their turn, APS separates this so that beacon proposers still propose the beacon block and get beacon rewards only, while a separate "execution proposer" actor gets the execution rewards. So while beacon proposers are always validators selected by the protocol, execution proposers are market-determined actors who could be anyone willing to pay for execution rights.

Source: Barnabé’s slides from CCE

Currently under PBS, we have beacon proposers (who handle consensus but also execution proposing) and builders (who construct blocks). APS splits the beacon proposer role further, creating: beacon proposers (purely consensus/attestation), execution proposers (timing and block release decisions), and builders (block construction). Important to note that APS and PBS are not mutually exclusive.

How APS is crucial for Native Rollups

APS enables one-slot delayed execution, a timing structure originally proposed to solve Ethereum's execution bottleneck by allowing validators to attest to blocks before fully executing transactions.

With APS, since beacon proposers and execution proposers are different entities with different jobs, the protocol can give them different timing (see diagram below for implementation of APS):

• Slot N: Beacon proposer does their consensus work
• Slot N+1: Execution proposer does their execution work for slot N

Source: More pictures about proposers and builders

This extra time slot is what makes Native Rollups practical as execution proposers get a full 12 seconds to generate the complex SNARK proofs that Native Rollups need, instead of having to rush everything into one slot.

Without APS, one person (the beacon proposer) has to do both jobs in the same slot, which doesn't leave enough time for heavy computation.

What is delayed execution

Delayed Execution is a proposed enhancement to Ethereum that separates block validation from transaction execution to solve a major bottleneck in the current system. Currently, validators must execute every transaction in a block before they can validate and approve it, which slows down the entire network because transaction execution can be computationally heavy and time-consuming.

Source: https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677

With Delayed Execution, validators can quickly validate a block's structure and approve it for inclusion in the blockchain without running the transactions first. This change could make Ethereum 5 - 8 times faster at processing blocks because validators no longer have to wait for complex transaction execution before moving forward, while still maintaining security through economic incentives where block proposers pay upfront costs for including transactions.

Source: https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677

What is One-Slot Delayed Proof Generation

Now that we understand how delayed execution and APS provide the timing structure, let's see exactly how Native Rollups use this for proof generation.

Native Rollups can use two different enforcement mechanisms depending on throughput needs. For smaller gas limits, validators can simply re-execute traces directly without needing complex proofs. However, for SNARK-enforced EXECUTE calls with large gas limits, Native Rollups use a one-slot delayed proof system for practical verification. As shown in the diagram below, after a block is executed in slot n, its cryptographic proof is generated in the next slot (n + 1). This gives validators enough time to create complex zk proofs. Attesters only attest to execution block n +1 if proofs for execution block n are available, ensuring security.

If a proof is delayed, backup "altruistic provers" step in to keep the system running smoothly.

When validators are selected as execution proposers, they're responsible for generating proofs for the previous block. They have strong economic incentives to do so since failing to provide proof means missing their slot and losing fees and MEV.

However, an open question remains around the backup mechanism: if an execution proposer fails to deliver proofs within one slot, are altruistic provers expected to generate the missing proofs to maintain light client accessibility? Without these proofs, light clients would need to re-execute EXECUTE calls themselves rather than simply verifying cryptographic proofs. Will there reliably be enough altruistic provers willing to generate expensive proofs for free when the incentivized party chooses not to?

The Same-Slot Proof Solution

Recent developments in Native Rollup architecture address these concerns through a "Same-Slot Proof" design that eliminates the need for altruistic provers entirely. By assigning proof responsibility to the builder of slot n (rather than slot n + 1), builders must prove their own blocks to claim execution rewards, creating direct economic incentives.

When proofs are missing, the system automatically treats block execution as a "no-op" where the pre-state carries forward unchanged. This ensures continuous network operation without requiring anyone to generate expensive proofs for free. The chain simply skips the problematic block's execution while maintaining liveness and light client accessibility.

The Timing Challenge

Current zk rollups face intense pressure to generate SNARK proofs extremely quickly, often within hundreds of milliseconds. This creates significant technical barriers and centralization pressures around specialized proving infrastructure.

Native Rollups solve this through one-slot delayed execution and Attester-Proposer Separation (APS): execution proposers get a full slot (several seconds) to generate proofs for block n while attesters validate block n +1 only after block n's proofs are ready.

This architecture enables "real-time settlement without worrying about real-time proving" by trading a small one-slot delay for dramatically more manageable proving requirements, making rollup operation accessible without ultra-fast specialized infrastructure while maintaining fast finality.

Native Rollups are the endgame for Ethereum’s L2 scaling roadmap because they fundamentally blur the line between L1 and L2. By directly leveraging Ethereum’s native execution engine through the EXECUTE precompile, these L2s become an extension of Ethereum itself rather than separate systems with their own trust assumptions. For users and protocols operating across the ecosystem, this creates a more unified, secure environment with minimal systemic risk.

By integrating directly with Ethereum’s execution engine, Native Rollups make it easier for different rollups to interact and share information securely with it. One rollup can verify the state of another without additional trust assumptions. This means that applications and users could move assets or call smart contracts across multiple rollups.

New solutions, such as shared/based sequencers and shared settlement layers, are being developed to help rollups "talk" to each other in real time. While Native Rollups simplify the technical side of this problem, fully automatic and instant cross-rollup transactions are still a work in progress for the whole ecosystem.

The implementation roadmap involves EIPs for both the EXECUTE precompile and one-slot delayed execution to allow sufficient time for proof generation. Deployment is likely not before 2026, starting with re-execution approaches under strict gas limits that will significantly constrain throughput while zero-knowledge solutions mature. Technical challenges are substantial: witness data creates 5-10x DA overhead, deposit/withdrawal interfaces need standardization, and only strictly EVM-equivalent rollups can transition to this model. Existing rollups would require extensive code refactoring, making adoption a complex technical undertaking rather than a simple upgrade.

Notably, the Native Rollup vision has received strong support from leading ZK teams. Uma Roy, CEO of Succinct, has been especially vocal, sharing enthusiasm around how Native Rollups simplify ZK integration and align with the rollup-centric roadmap. In this Bankless podcast episode, Uma explains that Succinct’s zkVM infrastructure could help power the proving layer for Native Rollups, enabling scalable, real-time execution with Ethereum-level security. A key piece of public infrastructure supporting this vision is ethproofs.org, a site that tracks and compares zkVM performance, specifically proof cost and latency, to help drive progress toward real-time proving across Ethereum’s rollup infrastructure.

The Future Ecosystem: Ethereum as the Security Exporter

For critical financial applications and high-value assets, Ethereum's settlement layer continues to offer unmatched security guarantees, and native rollups will eventually extend this security to compatible L2s.

Native rollups represent an exciting vision for the future of Ethereum scaling, where rollups truly become extensions of Ethereum itself rather than separate systems with their own trust assumptions.

For developers looking to integrate their applications with Gelato Web3 Services, check out Web3 Functions, Relay, and VRF! Visit our Discord server for developer support and engagement, and stay updated with the latest developments by following us on X.

Definitions

• What is an Altruistic Prover?: Backup actors in the proof-generation process who step in to generate and submit proofs when primary provers are delayed or fail. Their role is critical to liveness but raises questions about incentive alignment.

• What is a Based Sequencer?: A based sequencer is a rollup transaction ordering system that derives its sequencing rights directly from Ethereum Layer 1 block proposers. Instead of running independently, the sequencer is integrated into Ethereum’s proposer-builder separation (PBS) flow, aligning transaction ordering on the rollup with L1 block production. This enables censorship resistance, MEV minimization, and tight L1 finality alignment, but depends on Ethereum proposer cooperation and enshrined sequencing infrastructure.

• What is a Native Rollup?: A Native Rollup is a type of Ethereum Layer 2 that leverages Ethereum’s built-in execution engine via the EXECUTE precompile, enabling tight integration with Ethereum and eliminating the need for custom EVM verification or fraud proofs.

• What is re-execution?: A method of state verification where validators replay a rollup’s transaction trace to confirm that the resulting state matches the claimed post-state. It’s simple but computationally intensive.

• What is a Shared Sequencer?: A shared sequencer is a decentralized network that orders transactions for multiple rollups at once, enabling cross-rollup coordination and reducing centralization risks.

• What is a Shared Settlement Layer?: A shared settlement layer is a blockchain that acts as the final source of truth for multiple rollups, providing advanced security and irreversible finality for all settled transactions.

• What is SNARK Verification?: A cryptographic method for proving correctness of computations. In rollups, SNARKs allow validators to confirm state transitions using succinct, verifiable mathematical proofs without re-executing transactions.

• What is Stateless Verification?: A validation method where validators do not store full blockchain state. Instead, each transaction batch includes all necessary state data (e.g. Merkle proofs), allowing correctness to be verified without local state access.

• What is an attester?: Attesters are validators in Ethereum's proof-of-stake system who vote on the head of the chain and contribute to the finality of blocks by submitting attestations.