An Introduction to Optimism’s Optimistic Rollup

Update 1: Optimism is currently planning its newest upgrade “Bedrock”. To get a good look and understanding of the changes that will occur, please read “Optimism Transaction Trails Behind the Scenes, Current Version vs Bedrock” by Yufei Li (L2 Security Engineer at the Ethereum Foundation).

Update 2: This article was written mid 2021, and many things have changed in the Optimism codebase. One of the biggest changes since then, is Optimism’s switch from replayable tx fraud proofs to interactive fraud proofs. Please keep in mind that details in this article may be outdated.

Optimism is a company that has implemented the Optimistic Rollup protocol and aims to greatly increase the throughput of the Ethereum network. This guide is an introduction to how the Optimism design works and is meant for anyone looking to get a brief overview on this layer 2 solution. This article assumes that the reader has some knowledge of Ethereum and optimistic rollups. The following links may be helpful to those who would like more info on optimistic rollups:

1. Optimistic Rollups
2. An Incomplete Guide to Rollups
3. A Rollup-Centric Ethereum Roadmap
4. (Almost) Everything you need to know about the Optimistic Rollup

Optimism currently has 2 types of nodes — sequencer and verifier (and eventually proposer) — to run its own network. The sequencer and verifier nodes both run L2Geth — a slightly modified version of Geth created by Optimism. Geth is the most popular implementation of the Ethereum protocol. Therefore, the Optimism network is very similar to the Ethereum network but with slight differences explained later on. For the launch of Optimism, there will only be one sequencer node managed by the Optimism team. There are plans to decentralize this role after the launch is stable and secure. For the rest of this article, L1 (layer 1) refers to the Ethereum mainnet chain and L2 (layer 2) refers to the Optimism network chain.

Basic Workflow

1. The basic workflow is that users will send transactions to the sequencer, and the sequencer will process these transactions on its copy of the L2 chain.
2. Once processed, the sequencer will submit both the transaction data and the new L2 state root to L1.
3. Then, all other L2 nodes mentioned above will process the transaction on their copy of the L2 chain.
4. In order to ensure that the new state root submitted to L1 is correct, verifier nodes will compare their new state root to the one submitted by the sequencer.
5. If there is a difference, they will begin what’s called a fraud proof. The fraud proof will execute the L2 transaction but on L1 so that the resultant state root cannot be faked.
6. If the fraud proof’s resultant state root is different from the one submitted by the sequencer, the sequencer’s initial deposit (known as a bond) will be slashed. The state roots from that transaction onward will be erased and the sequencer will have to recompute those lost state roots correctly this time.
7. Once the sequencer role has been decentralized, if the sequencer’s bond gets slashed, a new sequencer will replace it.

The following diagram illustrates this basic workflow for steps 1–4.

Steps 1–4 of the basic workflow

Transactions

There are two types of transactions important to this system — L2 transactions that occur between two addresses on the L2 chain and cross chain transactions that occur between the L1 and L2 chains. The following workflow goes into a little more detail than the basic workflow on how L2 transactions work.

L2 Transaction Workflow

1. Users will send transactions to the sequencer node and the sequencer will immediately add it to the L2 chain if it is a valid transaction (Note: at this point, only the sequencer node has added this transaction to its copy of the L2 chain). The block sizes for L2 are 1 transaction only, so immediately a new block is added to the chain with the new transaction. There are no miners competing for mining new blocks in L2 because the sequencer has replaced the miner functionality.
2. Then, after the sequencer has added a few transactions to the L2 chain, it will call a smart contract on L1 (deployed by the Optimism team before release) and send it the transaction data for all of those L2 transactions along with the new state roots of the L2 chain after applying each transaction.
3. The smart contract on L1 will store the transaction data and state roots in an efficient manner (rollups) in another smart contract designed for storage.
4. Once the transaction data has been stored on L1, the verifier nodes will include the transaction in their copies of the L2 chain.

If the sequencer is censoring a particular user, that user will be able to submit the transaction data and call the smart contract themself. The sequencer will then be forced to process that transaction within a certain time frame. If they don’t, their bond may be slashed.

Additionally, so far it has been mentioned that the verifier checks the transactions posted to L1 by the sequencer. However, verifiers can also choose to sync from L2, which means that they will get new transactions directly from the sequencer, possibly before they are posted to L1. This sync from L2 method reduces latency, but does not guarantee that the sequencer will post this transaction to L1.

Cross Chain Transactions

Cross chain transactions are necessary in this system in order for users to be able to call contracts on other chains or to send ETH/tokens from one chain to another. These transactions have a slightly modified workflow than L2 transactions since they involve both chains.

L1 -> L2 Transactions

Transactions from L1 to L2 are quite fast and simply rely on the sequencer to relay the message to the L2 chain. User’s will send their transaction data to a bridge smart contract on L1 and this smart contract will add the transaction to the queue of transactions that the sequencer must add to L2 within a certain time frame. Therefore, the sequencer will eventually relay that transaction to the L2 chain.

For example, if a user wants to send 10 ETH to their address on L2 so that they can interact with smart contracts on L2, the following steps will happen:

1. The user sends 10 ETH to a bridge contract on L1.
2. The contract locks the ETH on L1.
3. The contract also adds the user’s transaction to the queue of transactions that the sequencer must add to L2.
4. The sequencer processes this transaction and the ETH is successfully deposited to the user’s L2 account.

Note: On L2, ETH has been replaced by a wrapped ERC20 token — WETH. This is to help the replayability of transactions on L1, which will be explained later. So, the transaction will deposit 10 WETH to the user’s L2 account. Additionally, in reality the bridge contract may be 2 smart contracts working together when a token or WETH is being transferred to L2. These bridge contracts will be provided by the Optimism team at launch.

L1 to L2 Transaction Workflow

L2 -> L1 Transactions

Transactions from L2 to L1 can be more complicated because in many cases the L1 chain must make sure that the L2 state root after the transaction (which originated on L2) is valid. Generally, the user will send the transaction to a specific smart contract on L2. Then a relayer will read it and send it to L1. Optimism has provided a javascript service that runs as the relayer. It uses the sequencer and verifier nodes to interact with L2.

To give an example of an L2 to L1 transaction, if a user wants to transfer their 10 WETH on L2 back to ETH on their L1 address, the following steps will happen:

1. The user sends 10 WETH to a bridge contract on L2.
2. The bridge contract burns the WETH and sends the transaction info to another smart contract known as the L2ToL1MessagePasser. This smart contract records the data for transactions that need to be sent from L2 to L1.
3. The relayer node reads this transaction data from the L2ToL1MessagePasser and waits for the fraud proof window (7 days) to complete before sending the transaction to L1.
4. The transaction is processed on L1 and the user can now withdraw their ETH. They will withdraw their ETH from the bridge contract that locked it when it was first sent to L2.

This fraud proof window gives verifier nodes enough time to identify if the state root posted by the sequencer is accurate for this transaction.

L2 to L1 Transaction Workflow

Transaction and state root storage on L1

Since the transaction data and resultant state root for each transaction must be stored on L1, minimizing the size of this data is crucial to lower the storage costs of the system. This is where the term “rollup” comes in. The following steps explain how the data for each L2 transaction is stored on L1:

1. The sequencer takes the calldata for a number of sequential L2 transactions and combines them into a single batch.
2. Then, the sequencer sends this batch to a smart contract known as the CanonicalTransactionChain.
3. The smart contract then hashes the calldata for each transaction and creates a merkle tree of these hashes.
4. The CanonicalTransactionChain takes the merkle root of this batch and sends it to a smart contract specifically meant for storage.

This process is basically rolling up a number of transactions, creating a merkle tree, and storing the root. The same process occurs for storing state roots as well. The contract used to rollup state roots is called the StateCommitmentChain. Now, the only change to the L1 state for a series of L2 transactions is the addition of a new merkle root to the storage contract. This makes the system much more efficient than storing each transaction separately in the storage contract. The following diagram illustrates this process.

L2 Calldata Storage on L1

Fraud Proofs

Fraud proofs are a very important part of the Optimism system and they are what keep the sequencer honest. If the sequencer posts a fraudulent state root to L1, the verifier node can start a fraud proof and execute the corresponding L2 transaction on L1. Then, the resultant state root from the fraud proof can be compared to the state root the sequencer submitted to L1. If they are different, the sequencer’s bond will be slashed and the state roots from that transaction onward will be erased and re-computed. Therefore, it is necessary that all L2 transactions are able to be executed on L1 in a deterministic manner.

Executing Fraud Proofs — the OVM

One of the main differences between Geth and L2Geth is that L2Geth executes transactions using the OVM — Optimistic Virtual Machine — instead of the EVM. The OVM is very similar to the EVM but has been modified so that context dependent opcodes (such as TIMESTAMP and ORIGIN) have either been modified or removed. These opcodes would give different outcomes depending on which chain they were executed on. But after the modifications in the OVM, all transactions are replayable on both chains with the same outcome. Essentially, the OVM is a sandboxed environment that allows L2 transactions to be replayable and deterministic on either chain. These features are necessary so that verifiers can create fraud proofs and replay the transactions on L1 to prove what the resulting state root should be.

Fraud Proof Contracts

Fraud proofs can be initiated by anyone, but are usually initiated by verifiers since they are checking the validity of every state root submitted by the sequencer. The entire process of fraud proofs are managed by a set of smart contracts on L1 provided by Optimism. Using these contracts, users can replay L2 transactions on L1 to generate the correct state root. The smart contracts will then take care of slashing the sequencer’s bond if the resultant state root doesn’t match the state root posted by the sequencer. In that case, the smart contracts will also handle erasing the corresponding state roots from that transaction onward.

Conclusion

How does this raise Ethereum’s transaction per second and lower transaction costs?

Optimism, along with all optimistic rollups, greatly improves the scalability of the Ethereum network and therefore lowers the gas costs (holding throughput constant). In L1 every Ethereum full node in the network will process the transaction, and since the network contains so many nodes, computation becomes very expensive. With Optimism, transactions will only be processed by the small set of nodes — the sequencer and verifiers. So, the computation of each transaction has been moved off of L1 while the transaction calldata remains on L1. This clears a lot of space on L1 and allows many more transactions to be processed. The greater throughput then reduces the gas costs since the competition for getting a transaction added to a block is lower. It remains to be seen exactly how much gas prices and throughput change as Optimism adoption increases.

Anything special about Optimism’s implementation of Optimistic Rollups?

One of the great benefits of Optimism’s design is the use of L2Geth and the OVM. Since these systems only make small modifications to Geth and the EVM, they inherit a lot of the well vetted security standards that these components have already demonstrated. This makes security audits of the Optimism design less complicated since there is less brand new software involved. As in most blockchain projects, security is absolutely necessary for the success of the application. Therefore, this feature of Optimism may prove to be invaluable.

If you’re interested in reading more on Optimism’s optimistic rollup, their documentation goes into much more detail. Additionally, Paradigm has a great article that explains a lot more of the technical details.

• Optimism Documentation
• Paradigm Research: How does Optimism’s Rollup really work?