Fast Withdrawals in Optimistic Rollups— Part 1

Published in

Onther

8 min readJul 19, 2021

Note: We have written several articles related to cross-layer transfer, and the below list will help the readers to navigate through them quickly.
An Introduction to Cross Layer Transfer
Fast Withdrawals In Optimistic Rollups — Part 1
Fast Withdrawals In Optimistic Rollups — Part 2
Standardising Cross-Domain Asset Transfer

This post is the first piece of our Fast Withdrawal in Optimistic Rollup series. Here we explain to the masses how deposits and withdrawals work in optimistic rollups (OR), withdrawal delays in OR, and how we can enable users to perform instant withdrawals in OR . Eventually, these thoughts are fine-tuned in the subsequent posts to arrive at a perfect approach for a fast withdrawal mechanism in the Tokamak network.

Introduction

Scaling Ethereum Blockchain is one of the long term researched topics by researchers all over the world. A collective outcome of all the newly proposed solutions aims to bring low latency and high throughput to the Ethereum network under tight resource constraints. Most importantly, these scalability solutions shouldn’t come at the cost of increasing trust or cost assumptions (less decentralized) of the network.

Generally, we encounter two schools of thought while discussing scaling a public blockchain. These are:

On-chain scaling

It mainly aims to increase the capacity of the core blockchain layer by different techniques such as sharding (ETH 2.0)

2. Off-chain scaling

The core idea behind this technique is to use the core blockchain layer as a trust and arbitration layer. The bulk of the user activity happens on the secondary layer. The main chain contract tracks the deposits and withdrawals w.r.t the secondary layer and verifies the proof to ensure that everything is happening according to the rules.

Layer 2 solutions are off-chain scaling solutions whose security is rooted with the base layer of Ethereum. Unlike sidechains, which has their separate consensus mechanism, layer 2 solution primarily relies on the security of the base layer.

This post will discuss one of the most popular layer-2 scaling solutions, known as optimistic rollups(OR). More specifically, we will delve into one of the major criticisms of OR, long withdrawal periods. We will try to understand how deposits and withdrawals work w.r.t optimism and the reason for the withdrawal delay. In the second part of this series, we will introduce some possible ways to deal with this delay.

Optimistic Rollup

QUICK OVERVIEW

Rollups are considered to be the saviour of Ethereum to deal with its high gas fees and less throughput. Rollups comes primarily in two different flavours, which are:

Optimistic Rollup and
ZK Rollup

The best analogy to think about optimistic rollup is the cheque-based transactions in real life. If the bank honours the cheque, everything will go smoothly, and the bank will release the cash. But, if the cheque bounces, the person must go to a court of law to get justice. Similarly, all the transactions that happen on a layer 2 rollup and its corresponding state changes are considered valid unless a verifier disputes it by submitting fraud proof to the base layer (Layer 1). If a fraud proof is submitted, the base layer will execute the transaction on-chain and verify whether the state change is valid or not. In the event of an invalid state, the person who submitted the invalid state gets punished (fidelity bond).

Okay, let’s explore more about Optimistic rollups with the help of diagrams.

Important note: To keep it simple, the below diagrams are explained with a single transaction and its corresponding state change, which is then rolled up to a layer 1 block. In reality, it is not a single transaction, but a batch of transactions and the corresponding state root is published to a layer 1 block. Usually, a sequencer batches a set of rollup transactions and publishes it to the layer 1 block (explained later in this post).

Layer 2 transaction and state rolled up to the Layer 1

In the above diagram, you can see that a state change has happened from S₀ to S₁ due to a transaction tx₀, and it is rolled up to the base layer. The transaction data is passed as calldata to the base layer to ensure data availability. Please note that there is no need to execute this transaction in the base layer unless there is a dispute within the withdrawal window. Storing raw transaction data on-chain is much more gas efficient than executing the transaction on-chain.

Moving on, an invalid state S₃ is rolled up to the base layer. This state transition should be challenged in the withdrawal period by a verifier.

The Base layer will execute the transaction on-chain to check the validity of the state transition. The state change will get reverted once the fraud proof is verified.

CORE COMPONENTS

Now, it is better to introduce some of the core technical components of optimism. Please note that we will not discuss each bit and piece of optimism architecture that is out of the scope of this article. We limit our discussion to those components that help you to understand the deposit and withdrawal flow.

Optimistic Virtual Machine as its runtime/state transition function — OVM provides a sandboxed environment that guarantees deterministic smart contract execution between L1 and L2. You can read more about OVM here.
Optimistic Geth as the L2 client with a single sequencer — The sequencer is responsible to order and append the transaction batches to a main chain contract (discussed next)
Chain Contracts — An optimistic chain is composed of a set of contracts running on the Ethereum mainnet. These contracts help to store the list of all transactions applied on the L2 state, store the corresponding proposed state roots, and contracts that help to challenge the transactions. We will discuss two of them below.

OVM_CanonicalTransactionChain (CTC) — It is an append-only log of transaction which is applied to the OVM state. The sequencer appends the L2 transaction batch to the CTC. Also, it allows an account to enqueue an L2 transaction which the sequencer must eventually append to the rollup state (This concept is important to understand the deposit flow)
OVM_StateCommitmentChain (SCC) — It contains a list of proposed state roots that Proposers assert to be a result of each transaction in the CTC. Elements here have a 1:1 correspondence with the transactions in the CTC.

The below gif will help you to understand how these components interact with each other.

Let’s build on top of these concepts and understand how the deposit and withdrawal transaction flow works.

Before that, it is also essential to know about the messenger contracts and token bridges in optimism.

Messenger Contracts — Communication between L1 and L2 is enabled by two special smart contracts called the “messengers”. These messenger contracts, the OVM_L1CrossDomainMessenger and OVM_L2CrossDomainMessenger come pre-deployed to the network.

Token Bridges — There can be situations where users want to move their assets from Layer 1 to Layer 2 and vice versa. The token bridges enable the user to move tokens across layers, and these token bridges make use of messenger contracts for the L1/L2 communication. (L1 standard bridge, L2 standard bridge)

Okay, now let’s try to understand how a user deposits a token to an L1 Token Bridge and receives its L2 counterpart using L2 Token Bridge.

How do Deposits work?

We will try to transfer 50ABC tokens from the base layer to the layer 2 rollup in this example. The below gif will help you understand the steps involved in minting an L2 representation of the L1 Token. Notice how the transaction is enqueued in the CTC, and as a result the sequencer is forced to execute the enqueued transaction in the rollup state.

STEPS

The User initiates deposit by sending 50ABC token to the token bridge.
The bridge contract escrows the token and invokes a function sendMessage in the Messenger contract. We pass the target as the corresponding token bridge on the L2 side with a request to completeDeposit.
The messenger contract inserts the transaction into the CTC using the enqueue function in the CTC contract.
Sequencer is forced to pick the transaction from CTC and execute the relayMessage function in the L2 Messenger contract.
The Messenger contract asks the bridge to complete the deposit by minting the tokens.
New tokens are released to the user L2 address.

How Withdrawals work?

When a user withdraws the asset from layer 2, the tokens are burned in layer 2 and the escrowed tokens in the Layer 1 bridge contract are released to the user. The below gif will help you to understand the withdrawal steps of 50ABC tokens from layer 2 to layer 1.

STEPS

The user initiates withdrawal of 50 ABC using the L2 Token bridge.
The bridge burns 50ABC and sends a message to the Messenger contract by calling the sendMessage function.
The L2 Messenger contract will put this information in its state tree, i.e the state on L2.
Eventually the initiateWithdrawal request ends up in the CTC once the sequencer updates the CTC with the new transaction batch.
The sequencer publishes the state to the SCC with the msg. Now, the wait period starts where the state change can get challenged in a one week window.
Once the window passes, the msg can be picked up and relayed to the L1 Messenger contract. The messenger contract verifies whether the fraud proof window elapsed.
The messenger contract then sends a request to the token bridge to release the 50ABC tokens to the user.

You might have noticed that the state batches are considered valid only after the dispute period (usually one week). So, a user needs to wait one week for the tokens to be released from the bridge contract. Dispute time delay is an inherent feature of optimism, without which it will be hard to maintain the integrity of the rollup. So, how can users perform instant withdrawals even while the system adheres to the dispute period?

Clue to tackle the Withdrawal Delay

Choosing a short dispute period over a long one provides a better user experience but at the cost of lower security. So, it is not a solution to reduce the dispute period to enable fast withdrawals.

The clue lies within the canonical transaction chain. Anyone running a full L2 node can execute the transaction log in the CTC and verify whether a withdrawal will succeed or not. The verification can happen even before the sequencer publishes the state root. Market makers can jump to monetize this opportunity. They can provide instant liquidity to the users by verifying the CTC and charging the user with a fee. We will expand on this concept in our second article of this series.

Fast Withdrawals in Optimistic Rollups— Part 1

Introduction

Optimistic Rollup

QUICK OVERVIEW

CORE COMPONENTS

How do Deposits work?

STEPS

How Withdrawals work?

STEPS

Clue to tackle the Withdrawal Delay

References

Written by Praveen Surendran