Different types of optimistic rollups
Rollups have emerged as highly effective solutions for scaling the Ethereum network. They use Ethereum as the settlement layer that establishes undeniable security and objective finality. This means they execute Ethereum transactions off-chain and collect them into a batch they later submit on-chain.
ZK rollups use Zero Knowledge technology to verify that the batch of transactions is valid and ready to be submitted on Ethereum. In contrast, optimistic rollups use fraud proofs and settlement periods to achieve the same.
EVM Compatibility in ZK Rollups
Vitalik Buterin categorizes the EVM equivalence of ZK rollups into four groups. Type 1 being the most and Type 4 being the least EVM-compatible. The argument is that while everything comes with a tradeoff and there is no "good" or "bad" over time, the goal is to achieve Type 1 EVM compatibility for all rollups.
| Type | Approach | Example | Compatibility |
|---|---|---|---|
| Type 1 | No changes to Ethereum data structures, hashes, or precompiles | Scroll, Taiko (in progress) | Fully Ethereum-equivalent |
| Type 2 | Changes internal state structures not accessible to the EVM | zkSync Era | Fully EVM-equivalent |
| Type 3 | Executes EVM bytecode using different architecture or semantics | Polygon zkEVM | Almost Ethereum-equivalent |
| Type 4 | Compiles high-level code into ZK-friendly bytecode, changes addresses | StarkNet, Aleo | High-level language equivalent |
Type 1 ZK-EVM Equivalence means that no part of the Ethereum system has been changed to make it easier to generate proofs. These projects are often referred to as EVM-Native.
The challenge with ZK rollups that comes at the cost of EVM compatibility is the time and power to generate the ZK proof. The lower the compatibility, the cheaper the transaction cost, and vice versa. For optimistic rollups, there are different metrics that point to higher EVM compatibility compared to ZK rollups' prover time and cost.
Statistically, optimistic rollups have faster execution than ZK rollups because they don't have to compute a big ZK proof to prove the validity of every transaction. But to not compromise the security of the rollup, they need to have a top-notch Fraud-proof system.
What does EVM-native mean in optimistic rollups?
The challenge of achieving higher EVM compatibility for optimistic rollups lies in the fraud-proof mechanism.
If the categorization for higher EVM compatibility for ZK rollups lies in achieving the highest EVM compatibility for the ZK proof generation, for optimistic rollups it lies in the fraud-proof system as the core component of ORUs.
EVM compatibility in optimistic rollups, the different types:
| Type | Approach | Example | Compatibility |
|---|---|---|---|
| Type 1 | EVM-level fraud proofs | Specular | Fully Ethereum-equivalent |
| Type 2 | Low-level VM + whitelisting | Arbitrum | Modified EVM-compatible |
| Type 3 | Low-level VM, custom client | Optimism | Partially EVM-compatible |
An interactive fraud-proof system is an interactive protocol for the challenger and the defender to narrow down the dispute into a single instruction depending on the compiled client binary.
A Challenger entity is a part of the protocol that monitors every submitted transaction. If it notices a faulty transaction, it can create a challenge against the transaction creator/defender. Modern optimistic rollups like Arbitrum and Optimism perform the interactive fraud-proof over a compiled L2 client binary. What does that mean one might ask? An L2 client consists of a custom L2 consensus layer and an existing but modified L2 execution layer. The L2 client is compiled to a lower-level virtual machine code like MIPS and WASM and is submitted to the L1 contracts as a Trusted Computing Base(TCB).
This makes the TCB that is submitted on-chain strongly coupled to the client challenging to audit and infeasible to formally verify. Every time a client is updated, the TCB must also be updated. All of this precludes trust minimization and client diversity.
EVM Native interactive fraud-proof.
One approach to achieving full Ethereum compatibility in optimistic rollups is to construct fraud proofs directly over EVM state transitions at the EVM instruction level, not relying on a compiled client binary.
In this model, the TCB consists solely of on-chain smart contracts. This shift not only simplifies the system but also makes it formally verifiable using tools like Dafny EVM. By eliminating reliance on off-chain binaries, the architecture becomes easier to audit, easier to upgrade and therefore scale, more transparent, aligned with first principles.
This design reduces the need for frequent on-chain upgrades, allows any client to permissionlessly participate in the network, and simplifies dispute resolution. Most importantly, it enables intrinsic client diversity, since the verifier is no longer tightly coupled to any specific client binary.
From lower-level VMs and binary-based fraud proofs to approaches that operate directly on EVM state transitions, each ORU reflects different tradeoffs in performance, security, and decentralization. The move toward EVM-native fraud-proof systems, which rely only on on-chain contracts and closely follow Ethereum's own execution logic, signals a deeper alignment with Ethereum's values of transparency, auditability, and permissionless access.