Everything you need to know about Optimistic Rollups with Optimism (Part1)
This article is the first in a series of theoretical and practical articles about Optimistic Rollups that explores the two main implementations Optimism and Arbitrum.
Introduction
Optimistic rollups are Ethereum layer 2 solutions that provide network scalability and efficiency. This type of rollup assumes that all transactions are valid. To maintain the network, validators in the rollup have a week to query the entire rollup if they believe that it contains fraudulent data. This process is commonly called “Fraud Proof”.
There are many implementations of Optimistic rollups. Optimism is the first solution to be developed. This solution has implemented the basics of optimistic rollup technology. So, let’s dive into learning what Optimism is.
Optimism nodes
Optimism has 2 types of nodes sequencers and verifiers to run its network. The sequencer and verifier nodes both run L2Geth, a slightly modified version of Geth created by Optimism.
L2GETH
L2GETH is a minimally modified version of Geth. Since this system only makes small modifications to Geth, it inherits a lot of the well vetted security standards that this component has already demonstrated.
Optimistic Geth is the L2 Optimism client software with a single sequencer through which can realize the interaction across Layer2 and Layer1.
Sequencer
Sequencers are a centralized mining pool node that is responsible for generating blocks on Layer2. Optimism eliminates the proof of work process by having a single Sequencer as the miner and does not immediately allow other nodes to verify (consensus), which saves a lot of time.
The sequencer is responsible for ordering and executing transactions, verifying transactions, compressing the data into a batch, submitting the batch to Ethereum as a single transaction and publishing the intermediate state roots produced by the transactions as a state batch in the State Commitment Chain.
Verifier
Layer2’s Verifier automatically reads, and reviews content stored by Sequencer to Ethereum, like the consensus on Ethereum. Verifier nodes will compare their new state root to the one submitted by the sequencer. If they find problems with the data submitted by Sequencer, they can challenge and initialize a fraud proof.
Optimistic Virtual Machine (OVM)
The OVM is an execution environment for optimism smart contracts. It works like the Ethereum Virtual Machine (EVM), but with some opcodes differences that give different results when run on layer L1 and layer L2 with the same inputs.
To correct these anomalies, OVM defines the ExecutionManager smart contract. This smart contract virtualizes (redefines) all the functionalities of EVM having different behaviors on L1 and L2 with the same inputs. This virtualization concerns contracts storage, transaction context (block number, timestamp, tx.origin, …), and cross-contract messaging routing. Thus, Execution Manager smart contract presents itself as a hypervisor between layer L1 and layer L2.
The redefinition of specific opcodes makes some opcodes no longer meaningful in OVM. Those opcodes that no longer make sense in OVM are defined in the SafetyChecker smart contract. SafetyChecker thus makes it possible to prohibit the use of these opcodes which no longer have meaning by smart contracts of optimism (check if opcode is safe).
All transactions are checkable by running the fraud proof consensus implemented in the OVM through the FraudVerifier, State Transitioner, and StateManager smart contracts.
For the storage of data transactions and state roots are ensured respectively by the canonicalTransactionChain and StateCommitmentChain smart contracts defined in OVM.
In OVM, the execution of any contract starts by calling the run function of the ExecutionManager smart contract, the opcode is checked in the SafetyChecker smart contract which informs the ExecutionManager if the opcode makes sense or not. If the various opcodes used by the running smart contract to perform the transaction are authorized, then the transaction is executed.
The following figure shows some modules of the OVM.
Contract Overview
The smart contracts in the Optimism protocol can be separated into a few key components. We will discuss each component in more detail below.
- Chain: Contracts on layer-1, which hold the ordering of layer-2 transactions, and commitments to the associated layer-2 state roots.
- Verification: Contracts on layer-1 which implement the process for challenging a transaction result.
- Bridge and messengers: Contracts which facilitate message passing between layer 1 and layer 2.
Chain Contracts
Canonical Transaction Chain (CTC)
The Canonical Transaction Chain is an append-only log representing the official history of all transactions, and in what order of the rollup chain. CTC hashes the calldata for each transaction and creates a Merkle tree of these hashes.
Transactions are submitted to the CTC in 2 ways:
- CTC Transaction Batch: Sequencer add transactions batches on Ethereum via appendSequencerBatch.
- CTC Transaction Queue: Users force the inclusion of their transactions in the CTC in 2 cases when the sequencer doesn’t include their submitted transactions in a batch or when users want to make a transaction from L1 to L2. Users are expected to call enqueue and appendQueueBatch functions. To do that, a time delay is introduced, after which batches can be appended to the queue by non-sequencer accounts.
The SCC contains a list of state roots, corresponding to the result of applying each transaction in the CTC against the previous state. The state roots for each state transition caused by a transaction get published to the SCC. SCC merklize a list of state roots of the intermediate state roots included in a batch.
There are three Chain Storage Containers deployed, two are controlled by the CTC Transactions batches and CTC transaction queue and one by the SCC SCC state roots.
Verification Contracts
Fraud Verifier: Contract which coordinates the entire fraud proof verification process. It calls to the State Transitioner Factory to initialize a new fraud proof.
State Transitioner: Gets deployed by the Fraud Verifier, one per fraud proof. Its responsibility is to call out to the Execution Manager and execute the transaction on-chain according to the rules, to produce the correct post-state root for the disputed transaction.
State Manager: Gets deployed by the state Transitioner, one per fraud proof. Any data provided by the users gets stored on it. Contains information about the state that was touched by the disputed transaction.
Bond Manager: Fraud Verifier Contract finalizes fraud proof once verified invalid, the sequencer submitted the fraudulent state will be punished by BondManager. The sequencer must be marked as collateralized by the Bond Manager by depositing a fixed amount, which he can withdraw after 7 days. If fraud is successfully proven, X% of the sequencer bond gets burned and the remaining (1-X) % gets distributed proportionally to every user that provided data for the fraud proof. Bond Manager also handles the accounting of gas costs spent by a Verifier during the course of a challenge.
Bridge and Messengers Contracts
The bridge works by locking up funds on L1 and minting the equivalent on L2. To withdraw funds, the bridge burns the L2 funds and releases the locked L1 funds. This is the way the Optimism standard bridge. The Standard Bridge is composed of two main contracts, the L1StandardBridge and the L2StandardBridge.
- L1StandardBridge: The L1 part of the Standard Bridge. Responsible for finalizing withdrawals from L2 and initiating deposits into L2 of ETH and compliant ERC20s.
- L2StandardBridge: The L2 part of the Standard Bridge. Responsible for finalizing deposits from L1 and initiating withdrawals from L2 of ETH and compliant ERC20s.
The cross-domain messenger broadcasts messages between L1 and L2.
- L1CrossDomainMessenger: The L1 Cross Domain Messenger contract sends messages from L1 to L2 and relays messages from L2 to L1.
- L2CrossDomainMessenger: The L2 Cross Domain Messenger contract sends messages from L2 to L1 and is the entry point for L2 messages sent via the L1 Cross Domain Messenger.
If you’re interested in diving even deeper, you should check our second part of this article.