Forward the Original Title: Unpacking The Next Generation Of Ethereum L2s (III): Native Rollups

Over the past two years, Ethereum has fully committed to a “rollup-centric” roadmap. This strategy involves locking ETH in bridge contracts, executing transactions off-chain, and using proofs—either fraud proofs or zero-knowledge proofs (ZKPs)—to verify the state of layer 2 (L2) and handle withdrawals.

However, there’s a significant challenge: Ethereum does not natively validate EVM execution, forcing rollups to independently implement their own proof systems on-chain to validate state transitions.

Ethereum frequently undergoes hard forks that can modify the EVM, which means rollup teams must take responsibility for maintaining and updating their custom implementations. This often necessitates forming a security council or adopting a token-based voting governance system to manage updates to their bridge contracts and proof mechanisms.

In our previous series, we explored based rollups and booster rollups. Now, we’re turning our attention to delve deeper into the concept of native rollups.

Based, Booster, Native… What’s the difference?

There can be a lot of confusion between definitions of based rollups, booster rollups, and native rollups. In the previous series, we went through based rollups and booster rollups already, so it’s recommended to check those before reading this article. However, we will quickly remind you about those three types.

Based Rollups use the L1 validator set for transaction sequencing, promoting decentralization but potentially affecting throughput due to the relatively long L1 block times, such as 12 seconds. However, efforts are being made to improve this experience with pre-confirmation techniques, allowing users to benefit from much faster transaction finality as the community continues to innovate.

Booster Rollups scale execution and storage by mimicking L1 processing on L2, enabling applications to grow without redeployment. While this approach provides scalability, it introduces additional complexity compared to traditional rollups, requiring more sophisticated engineering efforts to develop and maintain.

Native Rollups leverage L1’s own state-transition function (STF) in the application layer as a verifier for state transitions. However, while Optimism, Arbitrum, and other rollups operate in EVM-equivalent environments, they often include custom modifications that can be complex—or even infeasible—to implement directly on Ethereum.

Native rollups, once known as enshrined rollups, have been discussed in detail in various writeups. Also, the term “canonical rollup” was briefly employed by @apolynya. However, “enshrined” was eventually replaced with “native” to indicate that existing EVM-equivalent rollups could potentially upgrade to this model. The term “native” was proposed by @danrobinson and an anonymous contributor from Lido.

How do native rollups work?

The native rollup proposal introduces the EXECUTE precompile, designed to act as a verifier for rollup state transitions. This precompile would allow rollup teams to use it within their verifier contracts, providing a base for proof systems and enabling rollups to inherit Ethereum’s native validation.

Since this new precompile is somewhat similar to the “EVM in EVM” concept, it will be updated through Ethereum’s hard-fork process under its social consensus. This ensures that changes to the EVM are mirrored in the precompile, allowing rollups to inherit Ethereum’s validation and relieving rollup teams of governance responsibilities like security councils or multisigs, ultimately making rollups inherently more secure for users.

The EXECUTE precompile functions as a verifier for EVM state transitions, enabling rollups to utilize Ethereum’s native infrastructure at the application layer. It validates transitions using inputs such as pre_state_root, post_state_root, trace, and gas_used, leveraging an EIP-1559-like gas pricing mechanism.

Validators can enforce the correctness of rollup state transitions through either re-execution or SNARK proofs, depending on the rollup’s scalability needs. Additionally, a one-slot delay is incorporated to mitigate centralization risks, such as MEV-driven proof competition.

The precompile simplifies rollup development by enabling “trustless rollups” in terms of proof systems. If combined with a based rollup design, where both sequencing and proof systems are managed by Ethereum, this structure could achieve full trustlessness, often referred to as an “ultrasound rollup.” It enhances composability with the potential for real-time settlement, thereby encouraging more composable and secure rollup designs.

The proposed precompile behaves similarly to the EVM, re-executing rollup transactions to verify correctness. This contradicts the core advantage of rollups, which is off-chain execution with only validity proofs submitted to Ethereum. Instead, the precompile essentially mirrors what Ethereum already does, adding no value in terms of offloading computational burden from L1.

The choice of an EVM-like verifier over zk-verifiers stems from the current immaturity of ZK technology. Even widely used zkVMs have shown vulnerabilities, and the rapid evolution of ZKPs makes hardcoding specific zk-verifiers on-chain risky and inflexible. Ethereum instead prioritizes diversity and neutrality, enabling experimentation with various zk-clients without locking into a single verifier.

However, this does not mean that the precompile fails to contribute to Ethereum’s scalability. While Ethereum ensures its security by keeping zk-proof verifiers off-chain, it leverages this precompile to validate zk-proofs submitted by rollups. This allows Ethereum validators to avoid fully emulating all rollup transactions from start to finish. Instead, by relying on off-chain zk-proofs, the network maintains its security guarantees while striving to achieve scalability in terms of execution.

What are the main benefits of native rollups?

With native rollups, much of the complex work can be handled by a precompile, making things like fraud proofs or SNARK checks much simpler. This means less code to write and maintain, and no need for extra systems like proving networks or security councils.

On-chain SNARK verification is expensive, so many zk-rollups settle transactions less frequently to save costs. The EXECUTE precompile could help reduce these costs by bundling multiple proofs together using SNARK recursion. This approach allows rollups to validate transactions more efficiently, making off-chain verification more affordable.

Ensuring bug-free operation in traditional rollups is challenging and often requires extensive checks. Many teams mitigate risks by employing centralized sequencing to prevent the creation of malicious blocks. Native execution via a precompile, however, could enable a more secure and permissionless sequencing mechanism. This approach can allow rollups to inherit not only the security but also the asset fungibility of L1, as transactions are validated directly within Ethereum’s trusted environment.

There are a lot of rollups which are EVM-compatible, but hardly any of them are EVM-equivalent: keeping up with changes on the main blockchain often requires a group or voting system to update rollups, which can be risky. Native rollups can update automatically with the main blockchain, keeping everything in sync without needing extra rules or voters.

For zk-rollups, achieving ultra-low-latency proving times, such as 100ms, is a highly challenging engineering task. Native rollups, by comparison, could allow a more “relaxed” proving schedule, extending it to one full slot. This approach reduces the pressure to generate proofs instantly, potentially improving reliability and integration with L1.

Will every rollup be native?

All current rollup stacks, like the OP Stack and Arbitrum Orbit Stack, have the potential to transform into “native rollups,” directly inheriting Ethereum’s security features. This upgrade would make users happier due to enhanced security and rollup teams more content by eliminating the need for security councils. Meanwhile, rollup teams can continue to compete by offering an efficient shared sequencing layer, still capturing sequencer fees and maximizing MEV.

However, not every rollup will transition to being native. Some L2 features are inherently incompatible with native rollups, including unique transaction types, distinct gas accounting methods, and precompiles not found on the main L1 blockchain. The variety in VMs among L2 rollups, each sharing a common security foundation, is one of the strengths of today’s L2 ecosystem, like @EclipseFND being an SVM rollup, @movementlabsxyz being a MoveVM rollup, or @Starknet being a CairoVM rollup.

As noted by @doganeth_en, future rollups will fall into three categories: enterprise rollups, performance-focused rollups, and “aligned” native rollups.

Enterprises will be focused on managing, sequencing, and owning their rollups, perfect for businesses wanting web2-like control over transaction order, execution, and applications.

Rollups focused on performance will use Ethereum’s settlement but rely on alternative data availability for top performance, like @megaeth_labs does using @eigen_da for data availability. Less decentralized, these rollups boost $ETH utility but compromise on some Ethereum features.

Native rollups will be fully integrated with Ethereum’s infrastructure and offer: Ethereum-level decentralization, shared execution with direct state access, and cheaper off-chain ZK proof verification. These rollups contribute to Ethereum’s network effects, potentially sharing revenue, but sustainability depends on natural economic incentives.

Conclusion

Native rollups represent a major advancement in Ethereum’s rollup-centric roadmap, offering a more aligned approach with Ethereum’s infrastructure. By introducing the EXECUTE precompile, native rollups simplify governance, removing the reliance on multisigs, security councils, or token-based voting systems. This approach not only enhances security but also enables rollups to scale more efficiently using off-chain zk-proofs, ensuring both trust-minimization and scalability.

While the proposal holds great promise, it is not without challenges. Most existing rollups, despite being labeled EVM-equivalent, often include slight modifications to the EVM. As a result, transitioning to a native rollup model could introduce additional development overhead for rollups with customized EVM implementations.

Nevertheless, native rollups offer a compelling pathway to integrate Ethereum’s security and flexibility with rollup design. By fostering alignment with L1, they encourage innovation while reducing fragmentation, making Ethereum’s ecosystem more cohesive and resilient for the future.

If you haven’t already, be sure to check out part I and part II of our Rollups 2.0 series that focus on based rollups and booster rollups, respectively. In our next post, we will dive deeper into the concept of gigagas rollups and explore how this innovative approach to rollup design could push the boundaries of Ethereum’s scalability and further enhance the rollup ecosystem.

Disclaimer:

1. This article is reprinted from [2077 Research]. Forward the Original Title: Unpacking The Next Generation Of Ethereum L2s (III): Native Rollups. All copyrights belong to the original author [2077 Research]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.