What is the Optimistic Virtual Machine (OVM)?
Written by Alchemy
Reviewed by Brady Werkheiser
The Optimistic Virtual Machine (OVM) is the execution environment for smart contracts running on an optimistic rollup. Optimistic rollups are layer 2 (L2) scaling solutions that help scale throughput and latency on Ethereum through off-chain execution. Rollups are “hybrid scaling solutions” because, while they execute transactions off-chain, they post data required to reconstruct the chain’s state on Ethereum.
Optimistic Virtual Machines (OVMs) are crucial to the functionality of optimistic rollups. OVMs allow developers to run decentralized applications (dApps) on L2 rollups, as they would on Ethereum, without noticeable differences in the user experience.
This guide explains what an OVM means and how it differs from other virtual machines, such as the EVM and zkEVM. We’ll also cover the basic architecture of OVM designs used in popular optimistic rollups, such as Optimism and Arbitrum.
What is an Optimistic Virtual Machine?
The Optimistic Virtual Machine (OVM) is an EVM-compatible virtual machine for running general computation on layer 2 (L2) protocols.
An OVM executes transactions “optimistically,” which means it doesn’t enforce transaction validity, but relies on the L1 chain to arbitrate disputes concerning the correctness of state transitions. These disputes are known as fraud proofs.
We can unpack this definition by considering its key components.
EVM Compatibility
The Ethereum Virtual Machine (EVM) is a “decentralized and global computer,” that enables the execution of programs on the Ethereum blockchain. The EVM is made up of thousands of individual computers (nodes) providing computational resources anyone can access to run software (e.g. smart contracts) on the Ethereum network.
“EVM compatibility” means a particular system is designed to work with programs written or compiled for the EVM. The Optimistic Virtual Machine is EVM-compatible because it supports the EVM’s instruction set (opcodes) as specified in the Ethereum Yellow Paper. This allows the OVM to execute Ethereum smart contracts without any significant changes to the code.
Optimistic Execution
Virtual machines can also function as state machines, allowing them to transition between various states in response to inputs. In blockchains, the consensus protocol governs state transitions and outlines rules guiding state transition functions. For example, the rules for updating Ethereum’s state are defined by the EVM and enforced by the network’s proof-of-work (PoW) consensus.
The OVM relies on an “optimistic execution” model—the protocol doesn’t check if a state transition is valid or not before accepting it. This increases efficiency since the need to reach consensus on the validity of state updates slows down processing on layer 1 (L1) blockchains, like Ethereum. By assuming all transactions are valid by default, the OVM can make progress much faster.
However, to provide security, OVM designs allow anyone to dispute the validity of state transitions—with the L1 chain serving as the judge. This process relies on “fraud proofs”, which we explain in a later section.
General Computation on L2
If a virtual machine (VM) supports general computation, it can perform most tasks, given the right instructions and enough resources. Because the OVM can execute arbitrary logic (i.e., it is Turing-complete), developers can apply it to running different kinds of smart contracts.
Also, the OVM runs on a layer 2 blockchain, a protocol that operates on top of a base blockchain (Ethereum in this case). L2 protocols are an extension of the parent chain and are managed by smart contracts on the L1 blockchain. More importantly, the L1 chain guarantees the correctness of state transitions in the L2 OVM and the availability of data behind the execution.
How is the OVM different from the EVM?
The OVM is similar to the EVM since they both serve to execute computation. However, the OVM merely serves as an interface to the EVM.
The EVM is the virtual machine used to process transactions on L1, but the L1 VM is slow because each computation must be re-executed by all nodes in the network before it is accepted. It is also expensive since there are so many transactions to process, and nodes can only process a small number of transactions at a time.
The OVM (running on L2) allows users to use the L1 EVM without updating the latter’s state directly. Instead, the OVM executes transactions “off-chain” (i.e. outside the L1 chain), but uses the off-chain data to guarantee what will happen on layer 1.
Here's an example:
Say Alice has 2 ETH on the optimistic rollup and sends 1 ETH to Bob.
An aggregator submits the transaction to the rollup contract on layer one which, if not challenged, is included as a part of a mined transaction on Ethereum.
In this way, we have guaranteed that a transaction paying Bob 1 ETH on the rollup will pass consensus on the main Ethereum chain and be finalized as part of the latter’s state.
This guarantee stems from the following facts:
The OVM uses the EVM’s rules to guide the execution of transactions. If the optimistic rollup executes a transaction correctly, it’ll be accepted on L1.
The aggregator publishes the transaction data on L1, allowing anyone to dispute the transaction if it was executed incorrectly.
Bob and Alice can decide to withdraw their funds from the rollup or continue transacting.
Either way, they will have benefited from the EVM without executing any transactions on L1.
Other differences between the OVM and EVM include:
Enforcing validity
Instant finality
Transaction speed
Enforcing validity
The OVM doesn't enforce the validity of a state transition function. For example, a malicious operator can transfer Alice's balance to himself and submit the transaction to L1. If the transaction is unchallenged, the OVM simply accepts it.
Conversely, every state transition on the EVM must follow the network's consensus rules before getting accepted.
For example, the scenario described above wouldn't be following these rules since the sender's signing key wouldn't match their public key (which is a criteria for valid transactions).
Instant finality
The EVM guarantees instant finality. This means a state transition is permanent once accepted on the network and cannot be altered or reversed.
The OVM cannot guarantee instant finality because it doesn't enforce transaction validity (finalizing invalid transactions would corrupt the chain).
Instead, updates to the OVM's state are only final if and only if accepted on the L1 chain.
Transaction speed
As explained, the OVM has a higher processing capacity compared to the EVM due to design differences. A single node (the sequencer) can write to the chain without having to wait for approval from other nodes.
This is unlike the EVM, where nodes cannot write to the chain unless a transaction has been verified and accepted by other peer-to-peer nodes. This reduces the number of transactions that can be processed in the EVM.
How is the OVM different from zkEVMs?
As explained, the OVM primarily focuses on execution and relies on the layer one EVM to enforce rules on state updates. Thus, transactions performed in the OVM are simply submitted to L1 without any proof of their validity. That increases scalability, but it increases the risk that invalid transactions will be finalized on L1, particularly if no one challenges them.
A zkEVM (Zero-Knowledge Ethereum Virtual Machine) solves this problem by generating cryptographic proofs attesting to the correctness of off-chain computation. This gives L1 strong guarantees of the validity of state updates.
The zkEVM is EVM-compatible, like the OVM, and can run smart contracts. However, it differs from the OVM in several ways:
Near-instant finality
Objective proof
Complexity
Let's explore these a little more.
1. Near-instant finality
State transitions are finalized immediately because the validity proof is verified on-chain. This removes the need for delays in finalizing L2 transactions on L1.
2. Objective proof
Zero-Knowledge proofs are used to guarantee the correctness of VM computation. This removes the need for subjective proofs (i.e., waiting for the challenge period to elapse) or fraud proofs to determine transaction validity.
3. Complexity
A zkEVM is more difficult to implement than the OVM because generating validity proofs for multiple steps of computation is expensive. OVMs are not encumbered by the need to verify off-chain computation upfront and only use fraud proofs when necessary. This makes them easier to implement than zkEVMs.
How does the Optimistic Virtual Machine work?
Like the EVM, the Optimistic Virtual Machine functions as a runtime environment for executing computation. However, the OVM also needs to account for proving computation because optimistic rollups rely on fraud proofs to detect invalid state transitions.
Execution
The OVM provides the functionality for deploying and executing contracts, monitoring balances, and other tasks a smart contract platform must perform. The OVM receives input in the form of transactions sent by a node on the L2 chain. These inputs cause the OVM to change its state and produce outputs, such as emitting events or processing payments.
Other details about execution in the OVM include gas, bytecode, and transactions.
Gas
“Gas” refers to computational resources for executing programs in the EVM. Like the EVM, the OVM uses the notion of gas to limit execution steps for each transaction.
Transaction senders must set a gas limit to specify how much gas they're willing to spend on a transaction. This prevents malicious transactions from running infinitely and consuming all network resources. Gas fees also compensate L2 nodes for providing computational resources for executing transactions.
Bytecode
Bytecode refers to low-level instructions that the Optimistic Virtual Machine (OVM) can interpret to execute functions. Smart contracts written in high-level EVM-compatible languages, such as Solidity, must be compiled to bytecode before deployment. The bytecode itself executes as a series of opcodes that perform operations on transaction inputs.
The OVM is compatible with the EVM at the bytecode level, except for a few differences. This means you can deploy compiled EVM bytecode in the OVM with minimal changes.
Transactions
A transaction in the OVM works similarly to the EVM. A transaction can be initiated by an externally owned account (EOA) or a contract account. Transactions from EOAs can either be any of the following:
Transfer of assets (e.g. Alice sends 5 ETH to Bob)
Contract creation (e.g. Bob sends a transaction to the network with the compiled bytecode as a data payload)
Smart contract execution (e.g. Alice pays for 5 UNI tokens)
Similarly, contract accounts can initiate transactions (called “message calls”) with an EOA as the recipient or another contract. A contract can also create a new contract in the OVM using a contract-creation transaction.
Fraud proving
As mentioned, the OVM relies on a fraud proving scheme to detect and reverse invalid state transitions. For fraud proofs to work, the OVM’s state is hashed as a Merkle tree, with the root stored in the rollup contract on layer 1. Merkle trees and roots allow nodes to make claims about different parts of the OVM’s state.
For example, a rollup operator—after initiating a state transition by executing transactions—is expected to publish a new state root when submitting rollup blocks. The state root is the equivalent of saying: “This sequence of transactions, when executed, transitions the VM from an old state (referenced in the old state root) to a new state (referenced in the new state root).”
However, the rollup contract cannot know if the state transition was valid or not (the system is “optimistic”). To prevent nodes from executing invalid state updates in the OVM, rollups use fraud proofs.
What is a fraud proof?
A fraud proof is simply a claim that a transaction, if correctly executed, leads to a state root different from the one computed by the block producer. This is possible because anyone monitoring the L2 chain can download transactions submitted to the rollup operator, re-execute them using their copy of the rollup’s state, and calculate the state root independently.
Say Alice's balance was 5 ETH in the OVM’s old state (cryptographically fingerprinted by the root hash: “0x67989898…”). If she transfers 4 ETH, the rollup enters a new state (cryptographically fingerprinted by the root hash: “0x7879056…”).
If the transaction was invalid (e.g. maybe the signature was incorrect), then it should revert, which would leave the VM's state unchanged.
However, let’s imagine a malicious operator applied the invalid update (perhaps transferring Alice’s ETH to their wallet), they can publish the new, albeit incorrect, state root to finalize the transaction.
Thus, it is the challenger's role to publish the correct state root and declare the rollup block invalid. It is the equivalent of saying: “This transaction, if executed correctly, leads to a different state root.”
What are the two ways to prove fraud in OVM-based rollups?
There are generally two approaches to proving fraud in OVM-based rollups: re-executing transactions and the bisection protocol.
1. Re-executing transactions
Here, the OVM is “containerized” in a smart contract running on the L1 chain. The smart contract acts as a sandboxed environment that allows us to replay an OVM transaction within the EVM to get the correct state root. This is done by supplying other context-related inputs, such as state and storage, as well as the disputed transaction.
In the example of the malicious operator described previously, the transaction would revert—leaving the state root as is. The computed state root would inevitably match the challenger’s state root, exposing the malicious operator and preventing the invalid state transition.
2. Bisection protocol
The bisection protocol is a different approach to fraud proving that attempts to minimize the work the L1 chain has to do in fraud proving. It is called a bisection protocol due to its unique design:
The process starts with a challenger disputing an assertion (rollup blocks are called “assertions” as they are disputable).
The asserter then divides the disputed assertion into two equal assertions, with the challenger choosing what part they wish to challenge.
After the challenger has chosen another assertion to challenge, the asserter again divides the assertion.
This process continues until both parties are disputing the results of one step of computation performed in the OVM.
The asserter is then required to provide a one-step proof showing that the disputed step of execution is correct.
If the asserter fails to submit the proof, or the L1 contract deems the proof invalid, they lose the challenge.
Unlike re-executing transactions, bisection removes the need to re-execute a whole block/transaction on-chain, which is expensive. It also makes it unnecessary to publish state roots for every transaction, which is necessary when re-executing transactions to prove fraud..
The bisection protocol is used in Arbitrum, with other optimistic rollups, such as Optimism planning to use a bisection protocol for fraud proving.
Final Thoughts
The Optimistic Virtual Machine is key to scaling Ethereum by moving computation off-chain to rollups. With the OVM, developers can deploy smart contracts on L2 chains without facing high gas fees and slow processing times that plague Ethereum. Moreover, fraud proving means the OVM can offer the same security guarantees as the EVM on Ethereum's main network.
Alchemy supports building on optimistic rollups utilizing the Optimistic Virtual Machine, including Optimism and Arbitrum.
Sign up for a free Alchemy account to start building ultra-fast, scalable, EVM-compatible dApps today.
Related overviews
Learn about ZKsync Era - the EVM-compatible ZK rollup powering Ethereum scaling.
Learn About Where Rollups as a Service Fit In The Ethereum Layer 2 Ecosystem
Definitions, Distinctives, Functions, and a List of Top Optimistic Rollup Tools
