Rollups & Optimism

Introduction

Optimistic Rollup Architecture

Optimistic Rollups sound too good to be true. Without compromising security guarantees, an ORU could scale transactions on a blockchain. It can increase the chain's throughput by leveraging fraud proofs and off-chain computation.

The supply and demand of blockspace determine the transaction fee for using a permissionless blockchain. Since blockspace is scarce, whales often outbid others. It means that Ethereum could price out many of its most loyal users at a time of high traffic.

By compressing the computation, rollups can fit more transactions in the same number of blocks, reducing congestion and making the blockchain more affordable.

Optimism implements the generic idea of an optimistic rollup on Ethereum. In this post, we will look at basic primitives underlying the Optimistic Rollup design and zoom in on the core components of Optimism's architecture.

Layer 2 Alternatives

Since the early days of Ethereum, it was clear that 13-second block time is slow. Adjusting parameters such as block size (or block gas limit) only can, at best, be a short-term solution.

Before the Ethereum community aligned itself towards a rollup-centric roadmap, they explored various solutions in parallel. Most notably state channels, side chains, and plasma. Compared to rollups, all of them come with certain limitations.

A state channel is like a bar tab. Two parties can make countless transactions with each other offline. Only the last one, where one party wants to exit, must settle on-chain. It works well for micro-transactions, for example, incrementally paying a storage service to retrieve a large file.

In a State Channel, only a fixed set of parties could transact. New parties cannot be added to the existing channels. Also, for many use cases, it requires high upfront capital.

A side chain is an independent blockchain that routinely checkpoints with the main chain. The side chain is responsible for its own security and hence doesn't benefit from the already established security faculty of the base chain. This begs the question, how censorship-resistant could a side chain be?

Plasma has a dynamic set of transactors and doesn't need upfront capital. It is like a side chain that is anchored within Ethereum. Still, it doesn't inherit the security from the base chain. It is not fully censorship-resistant.

Moreover, channels, side chains, and plasma do not guarantee data availability¹. These solutions put the burden of security in the users' own hands. Plasma and State Channels require users to store their transaction history. If the system cheats, the user should be able to produce evidence to the main chain to settle the dispute. Side Chains rely on their own validators for security. In a nutshell, state channels are not general-purpose, and plasma and side chains are not secure enough.

Rollups Overview

Rollups are at a sweet spot in the scalability versus security trade-off space. It can inherit the security of the main chain. Intuitively, a rollup is an ordered mempool (an ordered set of transactions) combined with a general-purpose virtual machine. Any computation that EVM can execute, a rollup can run it too.

There are two varieties of Rollups: optimistic rollups and ZK rollups. As the name suggests, ZK rollups are built using Zero-Knowledge magic. Covering them is beyond the scope of this post.

On the other hand, Optimistic Rollups only require implementing the challenge verification game. It builds upon two assumptions.

1. At least one node verifies the computation that the sequencer executes (1:N trust model). In case of a dispute, the verifier generates a fraud-proof.²

2. The underlying blockchain is secure and decentralized. That means it is resistant to censorship and block reorganizations.

Traditional side chains are independent blockchains but commit the block hashes to the main chain. A rollup is a blockchain that is tightly coupled with its main chain. A valid rollup block eventually ends up on the main chain as long as it is not under a Sybil attack.

Rollups publish the block data on-chain, but transactions remain unverified for some time (a trial window, for example, 2 weeks). During this time, blocks are tentatively accepted.

The sequencer "rolls up" the computation required to execute transactions and publishes their results on-chain. The overall throughput increases because every other node on the main chain doesn't have to re-execute the unrolled transactions to verify it.

A tentative block is up for a challenge by an independent verifier. If the challenger could prove, within the trial window, that a particular block is indeed invalid, it will earn a bounty³. At the same time, the sequencer (block producer) has to pay the penalty.

Unlike the other layer 2 solutions, rollups publish the entire transaction data on-chain to ensure "data availability". Storing raw data on the blockchain is cheaper than performing computation over that data. Optimistic Rollup implementation such as Optimism and Arbitrum optimally compresses the transaction data, so they don't have to overpay for L1 gas.

Bridging

SOL tokens in Uniswap on Ethereum

A rollup has a separate blockchain. It is important to note that most users only care about applications and their assets. A rollup is only helpful if it seamlessly interoperates with the underlying chain. An end-user should be able to bring their assets to the rollup chain and withdraw back to the main chain. The rollup and the application deployed on it should support common uses like lending, borrowing, trading assets, voting on proposals, etc.

In the context of blockchains, bridging means locking up an asset on one side and then minting a proxy representation on the other. The proxy token can trade on the other blockchain like any other token and remains redeemable for the original asset. For example, the Wormhole bridge between Ethereum and Solana enables defi users to trade a representation of the Solana token with any other Ethereum based token on Uniswap.

The security of cross-chain bridges is a complicated matter on its own. It is well known that the current bridge architectures are not secure enough relative to the money they carry. Unlike cross-chain L1 to L1 bridging, L1 to Rollup bridging is safe against issues related to consensus because of shared security. However, users are still vulnerable to the risks associated with execution while bridging their assets from L1 to a Rollup.

Million Dollar Bug Bounty

In February 2022, Saurik uncovered a critical bug in Optimism's execution environment (OVM). Which led to a well-deserved bug bounty of more than $2m! This bug would have allowed a malicious hacker to print an unlimited amount of "bridged" Ethereum tokens (OETH). Fortunately, it was never exploited.

One of the reasons why this bug was lurking in the system was that Optimism's execution environment was not fully compatible with Ethereum's. This event motivated the team to double down EVM equivalence. Since then Optimism team has addressed the issue. It will be deployed in their latest bedrock release.

EVM Equivalence

The execution layer is the core of a rollup. Rollups can scale transactions because it relaxes the requirement of every network participant having to run each piece of computation. Instead, it allows a dedicated node (the sequencer) to execute transactions and create a proof. Every node in the network can verify that the block producer is not cheating. Also, a rollup must submit all the transaction data on-chain. If the sequencer disappears, another node can take over.

Notice that Ethereum doesn't require that rollup's execution environment comply with the EVM. The only requirement is that the Rollups post the compressed transaction data on the chain. However, the sequencer can execute code in any programming language or VM if it produces the required chunk of bytes.

Fuel is a perfect example. Similar to Optimism and Arbitrum, it is an Optimistic rollup. However, it has its own VM that can execute transactions in parallel. Offers a UTXO-based transaction model similar to bitcoin. Provides a Rust-inspired programming language called Sway that promises a safer contract development method.

With that said, we can now turn to the numerous benefits that EVM equivalence offers. It can prevent compatibility-related bugs like the one described above. Also, EVM equivalence can offer a better developer experience in different ways.

Contract developers can reuse their existing code. They don't have to re-write their applications from scratch while migrating from Ethereum to Optimism. While doing so, they also gain access to many mature Solidity or Vyper focussed tools, libraries, and frameworks.

In recent years the security community has developed a set of best practices for auditing solidity-based contracts. It is hard to find reputed auditors to review the solidity code. With an unfamiliar language, it is going to be even more complicated.

Optimism Architecture

We don't need to go into tiny details at this point. In the following paragraphs, we will examine a few essential components of Optimism's architecture. That should be enough to understand the whole system at a higher level.

Canonical Transaction Chain

The CTC is a contract on Ethereum L1. It contains an append-only log of transactions (the L2 blockchain) ready to be applied to the current L2 state.

It includes two important data structures (queue and batches) and two methods (enqueue and appendSequencerBatch) we should zoom in on.

enqueue:

Canonical Transaction Chain contract

As the name suggests, this method adds transactions to the queue. These transactions are not batched yet. There is no restriction on who calls this it. If the transaction is enqueued, the sequencer is bound to roll it up.

There is a possibility that the sequencer could become malicious. It may start to censor users' transactions. In such a scenario, a user can force the sequencer to include their transaction by directly adding it to the queue.

However, we should note that when the sequencer adds transactions to the queue, an individual user only pays the amortized gas cost. If an individual directly adds a transaction to the queue, it will be as expensive as an ordinary L1 transaction.

appendSequencerBatch:

appendSequencerBatch method

The appendSequencerBatch method picks up transactions from the queue and rolls them up into a batch. The batches data structure is a ring buffer that defines the order of the transactions. Under the hood, the ChainStorageContainer library implements it.

Only the sequencer can call appendSequencerBatch

Only the sequencer can call this function. Once a transaction is batched, it will eventually be included in the blockchain. However, at this point, it is only tentative. It is not safe to consider it final until the challenge period is over.

Data Transport Layer Service

Data Transport Layer

Data Transport Layer is a typescript service that runs within the Optimism node. Ethereum nodes download new blocks from the peer-to-peer network. In the case of Optimism, the DLT service monitors Optimism's L1 contracts to download new blocks.

When the DTL detects a new relevant event on the L1 blockchain, it downloads the corresponding transactions. It inspects these transactions to reconstruct the blocks in the standard Ethereum block format.

The L2 blocks are stored in the DTL's database and exposed via HTTP APIs. sequencers and verifiers can download these blocks and proceed with the execution. After executing, the sequencer proposes the new state by adding it to the SCC contract. If the verifier finds the computation incorrect, it creates a fraud-proof.

SCC

The State Commitment Chain (SCC) is an L1 contract. It contains a list of proposed state roots called batches. Similar to batches in CTC, it is implemented using the ChainStorageContainer.

The batch elements here have a 1:1 correspondence with transactions in the CTC. Each one represents a unique state root. Each state root results from the sequencer applying the canonical transactions one by one over the last batch element.

State roots and Transaction batches

There are three essential methods in SCC.

appendStateBatch:

appendStateBatch method

Anyone can enqueue a transaction in CTC, but only the sequencer can propose a state root in SCC by calling this function. The sequencer asserts that the proposed state root is correct by appending a new state batch.

deleteStateBatch:

deleteStateBatch method

Transactions enqueued in the CTC are valid Ethereum transactions. A sequencer can only cheat by proposing an inconsistent state root (for example, the one where they reward themselves $1B). In that case, a verifier can detect fraud by independently executing the transactions.

If the verifier finds and proves the fault within the challenge window, it can delete the faulty state by calling this function.

The verifier gets a bounty for its service, and the sequencer incurs a penalty for attempting to cheat. The Sequences eventually proposes new batches to replace the deleted state roots.

Notice that the CTC batch doesn't roll back even after the verifier deletes the corresponding SCC batch. The fault proving-verification game doesn't alter the order of transactions in CTC.

verifyStateCommitment:

verifyStateCommitment method

Batches in the SCC finalize if they remain unchallenged until the end of the challenge period. This function doesn't change the state. It only returns true or false. With the given state batch and a Merkle proof, this function verifies the inclusion of a transaction. Any contract on Ethereum can call it to determine the status of any transaction on Optimism.

Standard Bridge

Optimism's Standard Bridging Protocol

Optimism's bridge protocol has two central contracts: Layer1StandardBridge and Layer2StandardBridge. The Standard Bridge contracts connect L1 and L2 applications. It is possible to deploy your own bridge. However, Optimism's bridging protocol provides a standard way of passing messages and assets around. Developers can make asynchronous calls between the two layers. It is worth noting that safely relaying a message from L2 to L1 takes at least 7-14 days (challenge period).

Known Issues, Criticisms, and Caveats

Until now, in this post, we looked at all the benefits that rollups provide. How it can meaningfully increase the throughput of a blockchain without compromising on security. Rollups will play a significant role in making blockchains ready for mainstream adoption. However, in engineering, there are no benefits without inherent cost. This section will look at common issues related to rollups.

The first and most obvious criticism is a high withdrawal time. Withdrawing tokens from an optimistic rollup back to the main chain takes a long time. The 7-14 day withdrawal time is due to the challenge period. The challenge verification game is inherent to the security of an optimistic protocol. Unfortunately, there is no way around it.

Optimistic rollups treat the underlying blockchain as a court. The layer one chain doesn't have to execute undisputed transactions. It only has to run the disputed ones. The challenge period is crucial because we want network participants to have enough time to gather evidence against the misbehaving sequencer. We want the verifiers to catch a sequencer trying to sneak in an invalid final state.

There also exist cross-rollup bridges. These protocols can significantly reduce users' withdrawal time without risking their funds. In essence, these bridges use money markets to provide an early withdrawal to a user. In exchange, the user gives the bridge the right to withdraw their original tokens. The bridging protocol takes a small fee for its service. It is worth highlighting that ZK rollups don't suffer from this limitation. Since ZK rollups rely on validity proofs instead of fraud proofs, there is no challenge verification game and hence no challenge period.

Rollups are not secure against the base chain re-orgs. Such attacks undermine the security of the underlying blockchain. In such an event, there is no guarantee of a canonical transaction ordering. As we saw earlier, rollups (and layer 2 in general) rely on the base layer being secure against chain reorganizations. Economic security is the most crucial feature of a blockchain. Trying to scale an insecure chain is putting more funds at risk.

There are some concerns regarding the centralization of sequencers. Currently, most rollups, including Optimism, Arbitrum, StarkNet, etc., have a centralized sequencer. It is worth emphasizing that a centralized sequencer cannot censor its user. As we saw, users can force the rollup to include their transactions. Liveness remains an issue until rollups move to an architecture with a decentralized sequencer. The centralized sequencer may go down, and a new one may not come online in time. In such cases, the L2 blockchain will stall. A centralized sequencer also gains exclusive access to the MEV. Other network participants may not consider it fair.

A relatively uncommon but relevant concern is rollup token incentive design. Optimism charges its user a gas fee in ETH tokens. However, one can imagine a rollup implementation that uses its own token for execution fee payment. Such an implementation will increase the transaction throughput on the underlying chain and hence deserves revenue.

At the same, its token may compete with the native asset of the layer 1 chain. Such an incentive design could be parasitic to the layer 1 chain. Increased demand for layer 2 tokens in the free market could come at the cost of the L1 native token. This can, in turn, lead to reduced security of a proof of stake-based layer one chain.

There are a couple of UX-related criticisms. For instance, bridging to a different network adds friction to the user flow. Moving tokens to layer 2 could be tedious to users who are used to a smooth 1-click user experience. Also, unlike ZK rollups, optimistic rollups don't add any feature to enhance transaction privacy. ZK rollups can give privacy as a side effect together with increased throughput.

Conclusion

Gas Fee on Optimism for Uniswap trades and ETH transfers

We started this post by highlighting the supply constraints on the blockspace. We looked at various layer 2 solutions that we have in our toolbox. We briefly went through the security and decentralization properties of each of them. We also analyzed the trade-offs these solutions make to provide higher scalability.

Then we narrowed our focus to Rollups and further narrowed it down to the optimistic variant. We understood the core primitive that optimistic rollups are built on. That is the Fraud proofs and the challenge-verification game between the centralized layer 2 block producer and the independent transaction verifiers.

We briefly looked at what bridging means in the context of blockchains. We also pointed out how Optimism got lucky regarding a critical vulnerability. A compatibility issue between Optimism's execution environment and the EVM led to a counterfeiting bug. Fortunately, before this vulnerability could be exploited, a whitehat hacker jumped in to save the day. We evaluated Optimism's decision to pursue EVM equivalence instead of building a new execution environment from scratch.

Towards the end, we zoomed in on a few components in Optimism's architecture. We saw how different contracts and RPC services interact with each other to implement the complex optimistic rollup design. Finally, we ended the post by looking at some known concerns and caveats related to rollups.

Notes

1. Data Availability is one of the most notorious problems in the blockchain space. It is hard to describe it as a side note. The description deserves an entire post. In summary, it entails preventing attacks where some network participants withhold transaction data to fool participants that don't keep the whole history of the chain.

2. Verifier's Dilemma: There is a monetary incentive for independently verifying the rollup computation. However, suppose every network participant thinks that someone else will be vigilant because there is an incentive, and no one actually is. In that case, a malicious sequencer will be able to steal money. Optimistic Rollups are safe if there is at least an independent verifier.

3. A poorly implemented bounty mechanism could cause a security issue. For example, consider this scenario. The sequencer posts a 50 ETH bond upfront to earn the right to produce blocks. Then the sequencer publishes a fraudulent state, and a verifier notices it and publishes a dispute. If successful, the protocol will take away 50ETH from the Sequence's bond and give it to the verifier. In this case, the sequencer can front run the verifier by publishing a dispute, disputing himself. By doing so, the sequencer can get back its initial capital.