Native Rollups - Promises and Challenges

Written by Mohammad Jahanara.

We would like to thank Tom Lehman, Alexander Hicks, Avi Zurlo for their thoughtful reviews and comments on an initial draft of this post, and acknowledge contributions from other Scroll team members Péter, Ye, and Alejandro.

Are rollups really as secure as L1?

If you are reading this, chances are you believe Ethereum is secure! The protocol has been battle-tested over the years, benefiting from client diversity that mitigates implementation risks. More importantly, Ethereum boasts a resilient social layer and a rigorous core-development governance mechanism, ensuring that most security issues are detected before deployment—and those that slip through are swiftly addressed.

A rollup has to trustlessly settle/prove its state transitions on L1, ensuring correct execution of every committed batch of transactions. This is how rollups (or more accurately, the rollup's validity bridge) inherit the security of L1, assuming the settlement logic is sound and complete. Implementing a proof system for trustless settlement is notoriously the most complex part of building a rollup system. Despite massive efforts, it took our community years to build fully functional proof systems, and even now we can’t be confident that these proof systems are completely bug-free. Security risks are exacerbated by ongoing rollup upgrades, whether to maintain EVM compatibility or introduce new functionalities. This is why many major rollup operators still rely on multisigs for emergency upgrades. Even Stage 2 (No Training Wheels) rollups—the current industry standard for security—depend on security councils and governance mechanisms.

Native Rollups: Taking rollup centric roadmap one step further

The Ethereum Virtual Machine (EVM) is the most mature and widely adopted smart contracts execution environment. Almost all Ethereum L2s (along with many competing L1s) choose EVM compatibility (though not strict equivalence). The key idea behind native rollups is to introduce a new EVM precompile that enables stateless verification of correct state transitions of other EVM instances. Rollups can use this precompile to trustlessly settle on L1, offloading the burden of building and maintaining a proof system while inheriting more of Ethereum’s security guarantees.

The EXECUTE Precompile

The proposed precompile follows this format:

EXECUTE(pre-state-root, post-state-root, transactions_batch_and_state_witness)

Where:

• pre-state-root and post-state-root represent the Merklized state before and after the transition.
• transactions_batch_and_state_witness includes the transactions to be executed along with Merkle proofs for necessary state reads and writes (referred to as "trace" in Justin Drake’s recent post).
• The precompile returns True if execution of transactions_batch from pre-state-root with state_witness results in post-state-root.

Note that transactions_batch_and_state_witness is a blob versioned hash, just a pointer to the data that is available to Ethereum validators.

Since Ethereum execution clients already handle EVM transaction execution, supporting this precompile shouldn’t be overly complex. Additionally, most EXECUTE calls in a single block are likely independent, enabling parallel execution.

Scaling Up: Re-execution vs SNARKification

In this design, every L1 node must re-execute each EXECUTE call. While parallelization helps, maximum number of invocation per block linearly increases computational requirements of L1 nodes, hence the number of invocations per block remains limited, constraining rollup throughput. Once again, SNARKs to the rescue!

L1 execution clients could integrate SNARK provers and verifiers for EXECUTE. Naively, when a node receives a block which includes EXECUTE invocations without accompanying proofs, after re-execution, it can generate the proofs and propagate it to its peers along the block. So instead of every node re-executing, most would simply verify a SNARK proof per invocation. Note that different clients are expected to choose different proof systems, to maintain client diversity and act as a built-in multi-prover for rollups that will be using this precompile.

However, generating a SNARK proof for a rollup batch currently takes 5–20 minutes, much longer than Ethereum’s 12-second slot time. This gap is expected to narrow to 5–10 seconds in the near future, making this approach viable alongside delayed post-state inclusion proposed in EIP-7862:

This EIP proposes that, for each block n, the state_root in block n's ExecutionPayload references the post-state of block n-1. As a result, block n no longer needs to compute & include or verify the post state root for block n.

With EIP-7862, validators will attest to a block’s execution results with one slot delay, so they can delay execution of the block by 1 slot; hopefully enough time for proofs to be generated and propagated to validators. Note that block builders, that are expected to be sophisticated entities under proposer-builder separation, will still need to eagerly execute the block.

DA inefficiencies

Remember that L1 nodes don’t have full-state of every rollup and they can only re-execute a batch of transactions for said rollup in an stateless mode; This necessitates state_witness as an input for EXECUTE precompile. It creates a significant additional DA cost for rollups that are posting full transaction data. With Merkle Patricia Trie a worst-case state witness size for an EVM block with 30M gas limit is ~300 MB! This number for alternative data structures, Verkle Trees and Binary Trees, is respectively roughly 3 MB and 10 MB. All of these numbers are far too large comparing to the typical 125 kb - 750 kb size of a rollup batch, with gas limit often significantly exceeding 30M. That means there will be 5-10x overhead for DA usage imposed to the rollups using EXECUTE precompile. See EIP-7864 and Vitalik’s post on stateless Ethereum clients for more context.

Secondly, rollups that are using this precompile can not operate in a state-diff mode or use any state-full compression methods.

Rollup STF vs EVM STF

While most Ethereum rollups are EVM-compatible, their state transition function is not equivalent to EVM, and they are not EVM-equivalent in different ways! Often they have new transaction types to handle deposits and withdrawals, or additional opcodes/precompiles, or even different behaviour defined for standard EVM opcodes. So they can’t just use the EXECUTE precompile right out of the box. It is important to note that, it is intended by design for rollups to be diverse and heterogeneous, so it wouldn’t be acceptable to force all rollups to adopt a uniform execution environment.

Making EVM in EXECUTE more flexible

Partial Settlement via Auxiliary Proofs

One rough solution for rollups is to split the settlement into two parts, verify the correct execution of EVM-equivalent part of their execution environment with EXECUTE precompile and verify the rest with an auxiliary proof! This can be achieved by allowing the users to input a list of opcodes/precompiles that should be skipped by EXECUTE, and include the intermediary post-state-root after each skipped operation as witness. Then the rollup should use its own bespoke proof system to verify correct execution of those skipped parts!

Custom Opcode Overrides

Another sketch solution is to allow rollups to over-ride behaviour of any existing opcode or define behaviour of new opcodes/precompiles/transactions within EVM in an smart contract, and feed that smart contract as input to EXECUTE! I am sure to most of the readers this sounds so many alarms about efficiency and practicality.

Generalizing EXECUTE beyond EVM to RISC-V

A different approach is to generalize EXECUTE beyond EVM to RISC-V, then rollups can feed in their custom state transition function as RISC-V byte-code and verify correct execution thereof! Almost all zkVMs are based on RISC-V ISA and it would be a SNARK-friendly choice, also there is a mature tool-chain for RISC-V compilation so it would be convenient to use as well. However, this requires implementing a RISC-V execution environment in all Ethereum execution clients. Also not all zkVMs are using the RISC-V ISA, many have their own modifications. So this may just be pushing the problem to another part of the stack rather than solving it.

Fundamental tension of customizability and achieving L1 security

Native rollups aim to eliminate security councils and governance dependencies by maximizing L1 security inheritance. However, deviations from EVM-equivalence mean rollups must partially govern their own settlement logic, reducing this benefit. It is important to keep custom logic limited so that it remains possible to formally verify, audit, and potentially be immutable!

Conclusion

The idea of exposing stateless verification of EVM execution inside EVM is truly powerful! Native rollups can be EVM-equivalent, governance-free, and immutable with no need for security councils whatsoever. There is also a great potential to create an economic zone of based and native rollups that share sequencers and settlement, and can interoperate more easily as a result. However, it would be fundamentally challenging for many existing rollups to adopt this paradigm since they are EVM-compatible in different ways and they use stateful or otherwise customized data compression for DA efficiencies.

The next steps are standardizing the format for transactions_batch and state_witness (which may include a stateless compression scheme), and exploring ways to extend or override certain EVM behaviours in EXECUTE, to make it desirable to a more diverse set of rollups. Finally, SNARKifying EVM is necessary to unlock the full potential of native rollups, which is well underway with efforts such as ETHProofs!