# [WIP] Native Rollups - Promises and Challenges

# 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 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)](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) 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](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517) 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](https://scroll.io/blog/scaling-security) 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](https://eips.ethereum.org/EIPS/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](https://ethereum.org/en/roadmap/pbs/), 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](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-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](https://eips.ethereum.org/EIPS/eip-7864) and [Vitalik’s post](https://vitalik.eth.limo/general/2024/10/23/futures4.html) 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 figuring out a way 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](https://ethproofs.org/)!