Decoding the next generation of Ethereum L2: Native Rollups

Native rollups use their own STF on L1 as validators for the Application Layer state transition.

Author: Dengechain Community

Over the past two years, Ethereum has been fully committed to the 'Rollup-centric' roadmap. This strategy involves locking ETH in bridging contracts, executing transactions off-chain, and using proofs—whether fraud proofs or zero-knowledge proofs (ZKP)—to verify the state of Layer2 (L2) and process withdrawals.

However, there is a major challenge: Ethereum itself does not natively verify EVM execution, forcing rollups to independently implement their own proof system on the chain to verify state transitions.

Ethereum frequently undergoes hard forks, which may modify the EVM, meaning that rollup teams must be responsible for maintaining and updating their custom implementations. This typically requires the establishment of a security committee or the adoption of token-based voting governance systems to manage updates to their bridging contracts and proof mechanisms.

In our previous series, we discussed the Application Layer and Booster rollup. Now, we will turn to a more in-depth exploration of the concept of native rollup.

What are the differences between Based, Booster, and native?

There may be a lot of confusion between the definitions of Based rollup, Booster rollup, and native rollup. In the previous series, we have introduced Based rollup and Booster rollup, so we suggest you check those before reading this article. But we will quickly review these three types.

Based Rollups use the L1 validator set for transaction sequencing to promote decentralization, but due to the relatively long L1 block time (e.g. 12 seconds), it may affect throughput. However, efforts are being made to improve this experience by using pre-confirmation technology, allowing users to enjoy faster transaction final confirmation while the community continues to innovate.

Booster Rollups extend execution and storage by simulating L1 processing on L2, allowing applications to grow without redeployment. While this approach provides scalability, it introduces additional complexity compared to traditional rollups, requiring more sophisticated engineering efforts for development and maintenance.

Native rollups use the L1's own State Transition Function (STF) as the Application Layer validator for state transitions. However, while Optimism, Arbitrum, and other rollups operate in an EVM-equivalent environment, they typically involve complex or impractical custom modifications that cannot be directly implemented on Ethereum.

Native rollups were once known as fiat rollups and have been discussed at length in various writings. In addition, the term "canonical rollup" was briefly used by @apolynya. However, the term "fiat" was eventually replaced by "native" to indicate that existing EVM equivalent rollups might be upgraded to such a model. The term "native" was coined by @danrobinson and an anonymous contributor from Lido.

How does the native rollup work?

The native rollup proposal introduces EXECUTE precompilation, aiming to serve as a validator for rollup state transitions. This precompilation will allow rollup teams to use it in their validator contracts, providing a base for the proof system and enabling rollup to inherit Ethereum's native verification.

Because this new precompile is somewhat similar to the concept of 'EVM within EVM' in some ways, it will be updated through the Ethereum hard fork process under its social consensus. This ensures that changes to the EVM are reflected in the precompile, allowing rollups to inherit Ethereum's validation and reduce the governance responsibility of the rollup team in terms of security committees or multisignatures, making rollups more inherently secure for users.

As a pre-compiled validator for EVM state transitions, EXECUTE allows rollups to leverage Ethereum's native Based infrastructure at the Application Layer. It uses inputs such as pre_state_root, post_state_root, trace, and gas_used to verify transitions, utilizing a gas pricing mechanism similar to EIP-1559. Depending on the scalability requirements of the rollup, validators can enforce the correctness of rollup state transitions through re-execution or SNARK proofs. Additionally, it integrates a slot delay to mitigate centralization risks, such as MEV-based proof competition.

This precompile simplifies rollup development by supporting 'trustless rollups' in the proof system. When combined with Based rollup design, where both the ordering and proof systems are managed by Ethereum, this structure achieves complete trustlessness, often referred to as 'ultrasound rollup'. It improves composability and has the potential for real-time settlement, thereby encouraging more composable and secure rollup designs.

The proposed precompiled behavior is similar to the EVM, re-executing rollup transactions to verify correctness. This is contrary to the core advantage of rollups, which lies in off-chain execution, only submitting validity proofs to Ethereum. Instead, precompilation essentially reflects what Ethereum has already done and does not add any value in reducing the computational burden from L1.

Choosing EVM-like validators instead of zk validators is due to the current immaturity of ZK technology. The widely used zkVM has shown vulnerabilities, and the rapid evolution of ZKP makes hard-coding specific zk validators on the chain risky and inflexible. Ethereum instead prioritizes diversity and neutrality, allowing for experimentation with different zk clients rather than locking into a single validator.

However, this does not mean that the precompile did not contribute to the scalability of Ethereum. Despite Ethereum ensuring its security by keeping zk proof verifiers off-chain, it uses this precompile to verify zk proofs submitted by rollups. This enables Ethereum validators to avoid fully simulating all rollup transactions from start to finish. Instead, by relying on off-chain zk proofs, the network maintains its security guarantee while striving for scalability in execution.

What are the main advantages of native rollups?

Through native rollups, many complex tasks can be pre-processed, making fraud proofs or SNARK checks simpler. This means less code needs to be written and maintained, without the need for additional systems such as proof networks or security committees.

The on-chain SNARK verification cost is high, so many zk-rollups do not settle transactions frequently in order to save costs. The EXECUTE precompilation can help reduce these costs by using SNARK recursion to pack multiple proofs together. This approach can make rollups more effectively verify transactions, making off-chain verification more cost-effective.

In traditional rollups, ensuring error-free operations is a challenge that typically requires extensive checks. Many teams reduce risks by adopting centralized sequencing to prevent the generation of malicious blocks. However, with pre-compiled native execution, a more secure and permissionless sequencing mechanism may be achieved. This approach allows rollups to inherit not only the security of L1 but also the fungibility of assets, as transactions are verified directly in Ethereum's trusted environment.

There are many rollups compatible with the EVM, but few are equivalent to the EVM: keeping in sync with the main blockchain typically requires a team or voting system to update the rollup, which can bring risks. Native rollups can automatically update with the main blockchain, keeping everything in sync without the need for additional rules or voters.

For zk-rollups, achieving ultra-low proof time, such as 100 milliseconds, is a highly challenging engineering task. In contrast, native rollups may allow a more "relaxed" proof time schedule, extending it to a complete slot. This approach alleviates the pressure of generating proofs immediately, potentially enhancing reliability and strengthening integration with L1.

Will all rollups be native?

All current rollup stacks, such as the OP Stack and Arbitrum Orbit Stack, have the potential to evolve into 'native rollups,' directly inheriting Ethereum's security features. This upgrade will make users feel more satisfied as security is enhanced, and the rollup teams will feel more at ease as they no longer need a security committee. At the same time, rollup teams can still compete by providing efficient shared ordering layers, capturing ordering fees, and maximizing MEV.

However, not all rollups will transition to the native form. Some L2 features are inherently incompatible with native rollups, including unique transaction types, different gas accounting methods, and precompiles not found on the main L1 blockchain. The diversity of VMs between L2 rollups, each sharing a common security Based, is a major advantage of today's L2 ecosystem, for example

• @EclipseFND is SVM rollup
• @movementlabsxyzMoveVM rollup
• @Starknet is CairoVM rollup

As pointed out by @doganeth_en, future rollups will be divided into three categories: enterprise rollups, performance-oriented rollups, and "aligned" native rollups.

Enterprises will focus on managing, ordering, and owning their rollups, which is perfect for those who want to have similar web2 control over transaction order, execution, and applications.

Performance-focused rollups will use Ethereum's settlement, but rely on alternative data availability for optimal performance, such as @megaeth_labs with @eigen_da for data availability. These rollups are less decentralized, but increase the utility of ETH at the expense of certain Ethereum features.

Native rollups will be fully integrated with Ethereum's Based infrastructure, providing Ethereum-level decentralization, shared execution with direct state access, and cheaper off-chain ZK proof verification. These rollups contribute to the network effect of Ethereum, may share revenue, but their sustainability depends on natural economic incentives.

Conclusion

Native rollups represent a significant advancement in the Ethereum rollup roadmap, providing a more aligned approach with Ethereum-based infrastructure. By introducing the EXECUTE precompile, native rollups simplify governance, eliminating the need for multisig, security committees, or token-based voting systems. This approach not only enhances security but also enables rollups to scale more efficiently, leveraging off-chain zk-proofs to ensure trust minimization and scalability.

Although the proposal has broad prospects, it is not without challenges. Despite the fact that most existing rollups are claimed to be EVM-equivalent, they usually have slight modifications to the EVM. Therefore, transitioning to a native rollup model may bring additional development burden to rollups with customized EVM implementations.

However, native rollups provide a compelling path to combine Ethereum's security and flexibility with rollup design. By promoting alignment with L1, they encourage innovation while reducing fragmentation, making Ethereum's ecosystem more cohesive and resilient in the future.