# Arbitrum Rollup Mechanism

>RIG Open Problem 3 (ROP-3)

>The post [Rollup economics](https://barnabe.substack.com/p/understanding-rollup-economics-from) introduced a framework to understand how rollups deal with costs and revenues. We expanded on the framework during [a talk](https://youtu.be/BmQnb7TN3Ho) at EthCC (see also, [slides](https://docs.google.com/presentation/d/1ycfr9f0Ppcxf8LK9--C0ie9co7c0Pb2RaMdl4-vn9iY/edit?usp=sharing)).

>**IMPORTANT NOTE:** This write-up is a ***work-in-progress***. I have been including contents I learned from multiple sources in the list below without a clear structure. Once I have finished reviewing all the materials, I will write-up a final draft of the article about Arbitrum rollup.

Some concepts that need to be understood with absolute clarity:
- *Rollup protocol*
- *Rollup Blocks:* RBlocks. A validator creates an RBlock and other validators will check it. Accept it if it is correct and challenge it if it is wrong.
- *L2 Blocks*
- *L1 Contract*
- *L2 Contract*
- *Arbitrum chain:* Once we have the notion of chain, we have blocks and full nodes to store the state of the chain. They also provide an API that others can use to interact with the chain.
- *Offchain Labs*
- *L2 Operators*

## Resources
1. [Inside Arbitrum Nitro](https://developer.offchainlabs.com/inside-arbitrum-nitro/)
2. [Arbitrum Nitro Whitepaper](https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf)
3. [The Complete Guide to Rollups](https://members.delphidigital.io/reports/the-complete-guide-to-rollups/)
4. [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html)
5. [Understanding rollup economics from first principles](https://barnabe.substack.com/p/understanding-rollup-economics-from)
6. [(Almost) Everything you need to know about Optimistic Rollup](https://www.paradigm.xyz/2021/01/almost-everything-you-need-to-know-about-optimistic-rollup)
7. [How does Optimism's Rollup really work?](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work)
8. [Ethereum Rollup Call Data Pricing Analysis](https://forum.celestia.org/t/ethereum-rollup-call-data-pricing-analysis/141)
9. [A Technical Introduction to Arbitrum's Optimistic Rollup](https://medium.com/privacy-scaling-explorations/a-technical-introduction-to-arbitrums-optimistic-rollup-860955ea5fec)

## Rollups?
First of all, rollups are a scaling solution for Ethereum blockchain. The ultimate goal is to improve scalability, one of the three trilemma of Ethereum blockchain. Rollups first execute transactions outside of Layer 1 (L1) then post the transaction data on L1. Those posted transaction data on L1 from Layer 2 (L2) are only some of the rollup transaction data (compressed data). L2 rollups post transactions on L1 in batches.

The whole process executes transactions, takes the data, compresses it and rolls it up to the main chain in a single batch.

Each rollup deploys a set of smart contracts on L1 that are responsible for processing deposits and withdrawals and verifying proofs. Proofs are the main difference between different types of rollups. There are two main types of proofs:
- Optimistic rollups use fraud proofs.
- Zero Knowledge (zk) rollups use validity proofs.

In order to be able to execute a rollup transactions on L1, optimistic rollups have to implement a system that is able to replay a transaction with the exact state that was present when the transaction was originally executed on a rollup. This is usually achieved by creating a separate manager contract that replaces certain function calls with a state from the rollup.

In zk rollups, there is no dispute resolution at all. This is possible due to a clever piece of cryptography called zero knowledge proof. In this model, every batch posted on L1 includes a cryptographic proof called ZK-Snark. The proof can be quickly verified by L1 contract when the transaction batch is submitted to L1. If the batch is invalid, it will be rejected immediately.

Let's talk more about Optimistic rollup's dispute resolution process. Due to the nature of dispute resolution, optimistic rollups have to give enough time to all network participants to submit their fraud proofs before finalizing a transaction on L1. This period is usually quite long (up to one or two weeks) because even in the worst case scenario, fraudelent transacitons can be disputed. That's why withdrawals from optimistic rollups can take quite long time.

*Potential scalability improvements by Rollups:* They should be able to scale Ethereum from processing around 15-45 transactions per second up to as many as 1,000-4,000 transactions per second.

***Question:*** L2 smart contracts on the Ethereum mainnet. How many are there and what are their roles?
- Smart contract processing deposits and withdrawals
- Smart contract verifying proofs that everything happen off-chain follows the rules.

Rollups move computations and state storage off-chain, but keep some data per transaction (e.g., compress the details of the transaciton) on-chain.

There is a rollup smart contract on-chain that maintains a state root: The Merkle root of the state of the rollup, which contains information such as account balances, contract code, etc. The actual state of the rollup is inside the rollup. Simply put:
- on-chain: just a Merkle root fo the state of the rollup
- off-chain: the state of the rollup.

The actual Merkle tree can be recomputed from on-chain data. The Sequencer publishes a **batch**, a collection of transactions in a *highly compressed form* together with the *previous state root* and the *new state root*.

***Question:*** How about *deposits* and *withdrawals*, which represent input and output that are outside of the rollup state?
- If a batch has inputs from outside, meaning deposits, the transaction submitting the batch needs to transfer the assets to the rollup contract.
- If a batch has outputs from outside, meaning withdrawals, after processing the batch the smart contract initiates the withdrawals.

If we recall, the batch published by the Sequencer includes a highly compressed transactions together with the previous state root and the new state root. Then the question comes in:

**Question:** How do we know if the new state root (i.e., post-state root) in the batch is correct?

If anyone just submit a batch with a post-state root with no consequences, then they could just transfer all the funds inside the rollup to themselves. Apparently that cannot happen. That's where the two very different families of solutions to the problem come into play, and they lead to two flavors of rollups: **Optimistic rollup** and **ZK rollups**.

### Optimistic Rollup
This type of rollup uses **Fraud Proofs**. What is fraud proof? As I mentioned earlier, the rollup contract keeps track of its history of state roots and the hash of each batch.

source: https://vitalik.ca/general/2021/01/05/rollup.html

If anoyone discovers a batch with incorrect post-state root, they can publish a proof to chain, indicating the batch is computed incorrectly. The smart contract verifies the proof and the challenge is successful, the rollup contract will revert the batch and all batches after it.

### ZK Rollup
This type of rollup uses **Validity Proofs**. What is validity proof? Every batch published on-chain includes a cryptographic proof called ZK-SNARK, which proves that the post-state root is the correct result of executing the batch. The advantage of validity proof is that no matter how large the computation, the proof can be quickly verified on-chain.

Vitalik made a nice table in his [post](https://vitalik.ca/general/2021/01/05/rollup.html) about rollups, comparing optimistic rollups with ZK rollups.

Compression tricks are critical to the scalability of rollups.

### Current Workflow of Arbitrum Rollup
Arbitrum One smart contracts on Ethereum L1: https://etherscan.io/accounts/label/arbitrum-one

Three types of transactions we can see on [ArbiScan](https://arbiscan.io/):
- Latest Blocks
- Latest Transactions
- Latest L1 --> L2 transactions. This is the most interesting set of transactions. Those are the transactions submitted from Ethereum to L2. For example, transfer ETH or other ERC20 tokens from Ethereum L1 to L2. These transactions will interact with [**Arbitrum Delayed Inbox**](https://etherscan.io/address/0x4dbd4fc535ac27206064b68ffcf827b0a60bab3f) smart contract on Ethereum L1. The delayed inbox is an L1 smart contract that accept messages to be delivered to the L2. It also provides a way for any user to submit a message in case the Sequencer is not available or misbehaving by censoring transactions.

There exist two important smart contracts that L2 nodes use to post the transaction data: the "delayed inbox" and "sequencer inbox". Anyone can send transactions to the delayed inbox, whereas only the sequencer can send transactions to the sequencer inbox. But at the end of the day, all transactions in the delayed inbox need to be included in the sequencer inbox and the sequencer is responsible for publishing the L2 transaction data onto Ethereum L1. The following graph describes this relationship nicely:

Source: [A Technical Introduction to Arbitrum’s Optimistic Rollup](https://medium.com/privacy-scaling-explorations/a-technical-introduction-to-arbitrums-optimistic-rollup-860955ea5fec)

Therefore, the sequencer inbox is the primary contract where every validator pulls in the latest L2 transaction data.

So, this is publishing data part. The second part of the workflow is
**Projects working on rollups:**

*Optimistics rollups:* Optimism and Arbitrum. One thing to note here is that Arbitrum has a different dispute resolution syste. Instead of rerunning the whole transaction on L1 to verify if the fraud proof is valid, they have come up with an interactive multi-round model which allows narrowing down the scope of the dispute and potentially executes only a few instructions on L1 to check if a suspicious transaction is valid.

Arbitrum will be initially running a sequencer that is responsible for ordering transactions, but they want to decentralize it in the long run. Optimism, in the other hand, prefers another approach where ordering of transactions, hence the MEV, can be auctioned off to other parties for a certain period of time.

*ZK rollups:* zkSync

Next, let me go through some of the [Arbitrum-specific terms](https://developer.offchainlabs.com/intro/glossary). I sometimes am confused with those terms as well.

- Arbitrum Chain: A layer 2 EVM environment running on Ethereum using Arbitrum technologies. Arbitrum chains come in two forms:
- rollup
- anytrust
- Arbitrum rollup: Arbitrum rollup is a trustless L2 protocol in which participation is permissionless and underlying layer Arbitrum One is used for data availability.

## Arbitrum Big Picture

At its core, an Arbitrum chain works as the figure below:
source: https://developer.offchainlabs.com/inside-arbitrum-nitro/

First, A user creates a transaction and this transaction will be put into the Arbitrum chain's inbox. The chain then reads the message one at a time, on a first-come, first-serve basis and processes each one. This procedure updates the state of the chain and produces some outputs.

### Sequencer and Transaction Sequencing
There is an intermediary between the users and chain's inbox, an agent called **Sequencer**. The sequencer's job is to put users transations into the inbox in an ordered fashion and commits to the ordering. Therefore, the sequencer keeps track of the inbox (??). Currently, the sequencer is a centralized entity operated by the Offchain Labs. The future goal is to decentralize this role by creating a committee-based sequencer.

The sequencer publishes its transaction ordering in two ways:
- Real-time feed, which is a "soft finality". This feed represents sequencer's promise to record transactions in particular order. This finality depends on the sequencer's promise, that's why it is called "soft finality".
- The sequencer also periodically publishes the sequence in batches on the Ethereum L1 chain. In general, every few minutes the sequencer concatenates a group of transactions in the feed , compresses them for efficientcy and posts the compression output on Ethereum. This compressed output posted on Ethereum is called "calldata". As you can guess, this is the final and official record of this particular transaction sequence. This is "hard finality".

As we can see from the sequencer role description, its main role is to order the incoming transactions and publish the data in real-time feed and in batches. The sequencer does not have the power to prevent the inclusion of any particular transaction.

The diagram in the Arbitrum whitepaper (link can be found in the *Resources* section at the beginning) summarizes how users' transactions are processed in Arbitrum Nitro.

source: https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf

### Deterministic Execution
Once the incoming transactions are sequenced in a particular order, they enter the execution phase. This is done by using the L2 chain's **State Transition Function (STF)**. STF takes as input current state and an incoming message (a single transaction) and outputs an updated state and a new Ethereum-compatible L2 block header. This part is represented by the right-hand-side of the graph above.

## Main Parties in Rollups
- *Users*, i.e., transaction creators
- *Sequencer*
- specially designated full node, control the order of transactions
- *Validators/Stakers*: of L2 block or RBlock?
- active validator: always staked
- defensive validator: only stake if someone is dishonest
- watchtower validator: never stakes
- *Operators*
- *Base Layer*
## How Main Players Interact?
Everthing starts with a user creating a transaction on an L2.

Arbitrum sequencer and Arbitrum validator must run an Ethereum full node, a full L2 node, to produce the L2 state.

Arbitrum validator is the verifier, who is responsible for watching for fraud.
## Fees and Gas (IMPORTANT!!)
In this section, I try to answer this big question:
> **Who pays what to whom?**

Users pay for their transactions' inclusion in the block to Arbitrum. Arbitrum collects those fees to cover:
- Operating cost
- Align incentives of?
- Ration scarce block resource when demand is high.
### NitroGas vs. L1Gas
The gas unit Arbitrum uses to track the cost of execution on a Nitro chain. In contrast, L1Gas is L1 gas on Ethereum. Each EVM instruction costs the same amount of has units in both L1 and L2.

Similar to Ethereum transaction, each Arbitrum Nitro transaction requires some amount of NitroGas. The price of NitroGas is equal to the current `basefee` which is determined algorithmatically. NitroGas price and NitroGas payments in L2 chain is denominated in ETH.
### Cost
- Cost of operating the chain. What are those costs?
### Fees
Transaction creators pay fees. These fees are assessed and collected by ArbOS at **L2**. They are denominated in **ETH**.

The creator of a Nitro transactions specifies two values:
1. gas limit, which is the maximum amount of NitroGas it will be allowed to consume. If the actual gas consumption of the transaction is higher than this user-specified limit, transaction will fail.
2. maximum `basefee`. This is user's willingness to pay (WTP) for the transaction. If the transaction creater's WTP is less than the current basefee determined algorithmatically by the protocol.

As a result, we can write the transaction fee as follows:
$$
\text{L2 Gas Fee} = \min\{\text{gas limit}, \text{actual gas consumed}\}\times basefee
$$
if `basefee` $<$ maximum `basefee` specified by the transaction creator; 0 otherwise.

How does the protocol algorithmatically determine `basefee`? An important parameter in the calculation is the *speed limit*.

The basefee adjustment is ultimately driven by supply-demand relationship. Nitro tracks the usage of NitroGas and compare it with the sustainable capacity. If the demand exceeds capacity, the basefee increases until the demand and capacity come back into balance (**What does this balance really mean in this context?**)

On the supply side, the sustainable capacity is reflected in the chain's `speed limit` parameter.
## Interaction Between L1 and L2
L1 and L2 chains run asynchronoously
## Data Availability
## The Current Rollups Economic Model