Arbitrum vs Optimism Rollup

Big picture first (same for both)

Both Optimism and Arbitrum are:

Optimistic rollups
Assume transactions are correct by default
Post:
- Compressed transaction data to Ethereum (for data availability)
- State roots to Ethereum
Allow fraud proofs during a challenge window (~7 days)

So security model = Ethereum L1

Now the real differences are in:

Execution model
Fraud proof design
How user operations are processed internally

How user operations (transactions) enter the system

Common flow (both)

User sends a transaction
It goes to a Sequencer
Sequencer:
- Orders transactions
- Executes them
- Produces a new L2 state
Sequencer submits:
- Transaction data → Ethereum calldata
- State root → Ethereum contract

Now differences begin.

2️⃣ Optimism: EVM-equivalent, simple execution

🧠 Core idea

“Make L2 behave exactly like Ethereum, just cheaper.”

How Optimism handles user operations

Execution model

Uses OP Stack
Runs a near-identical EVM
Transactions are executed sequentially
Same gas rules, same opcodes, same behavior

UOP lifecycle


User TX
 → Optimism Sequencer
   → EVM execution
     → New L2 state root
       → Post calldata + state root to Ethereum

Fraud proof design (Optimism)

Single-round fraud proofs
If someone claims fraud:
- Re-execute the entire disputed transaction
- Compare results on L1

Consequences

✅ Very simple mental model
✅ Easy for developers (EVM equivalence)
❌ Fraud proofs are heavy
❌ Less scalable fraud verification

Think of Optimism like:

“Replay the whole transaction on Ethereum to prove cheating.”

3️⃣ Arbitrum: Interactive execution, multi-round fraud proofs

🧠 Core idea

“Minimize L1 work by narrowing disputes step-by-step.”

How Arbitrum handles user operations

Execution model

Uses AVM (Arbitrum Virtual Machine)
EVM-compatible, but internally different
Execution is broken into many small steps

UOP lifecycle


User TX
 → Arbitrum Sequencer
   → AVM execution (step-based)
     → Assertion (state transition claim)
       → Post calldata + assertion to Ethereum

Fraud proof design (Arbitrum)

Multi-round interactive fraud proofs
Dispute is narrowed like binary search:


Whole execution
 → half
   → half
     → half
       → single instruction

Only the exact faulty instruction is re-executed on Ethereum.

Consequences

✅ Much cheaper fraud proofs
✅ Better scalability
❌ More complex protocol
❌ Harder to reason about internally

Think of Arbitrum like:

“Zoom into the exact CPU instruction where cheating happened.”

4️⃣ Key difference in handling UOPs (side-by-side)

Aspect	Optimism	Arbitrum
Execution	Full EVM	AVM (EVM-compatible)
TX execution	Monolithic	Step-based
Fraud proof	Single-round	Multi-round interactive
L1 cost during dispute	High	Very low
Complexity	Simple	Complex
Dev experience	Extremely Ethereum-like	Slight abstraction

5️⃣ Sequencer behavior (important detail)

Both:

Currently use centralized sequencers
Give:
- Fast confirmations
- Soft finality

Difference:

Optimism → simpler batch posting
Arbitrum → assertion-based posting

Both are moving toward:

Decentralized sequencers
Fault-proof upgrades

6️⃣ Final mental model (remember this)

Optimism

“Ethereum, but cheaper — trust first, verify later by re-running.”

Arbitrum

“Ethereum logic, but disputes are handled like debugging a program.”

One-line takeaway (exam-level answer)

Optimism handles user operations by executing full EVM transactions and resolving fraud by re-executing entire transactions on L1, while Arbitrum breaks execution into small steps and uses interactive fraud proofs to isolate and verify only the exact faulty instruction, making disputes cheaper and more scalable.

I’ll explain:

What an “assertion” really is
How Arbitrum posts assertions
How fraud proofs work step-by-step
Why this makes fraud proofs dramatically cheaper

1️⃣ First, ask yourself this (important)

If Ethereum is expensive, what is the most expensive thing we can do on L1?

💡 Answer: Re-executing lots of computation.

So the design goal is:

Do as little computation as possible on L1 during disputes

That single goal explains assertion-based posting.

2️⃣ What is an “assertion” (conceptually)?

Think like a CPU engineer.

Instead of saying:

“I ran this whole program correctly”

Arbitrum says:

“Starting from state S₀, after executing N steps, the machine reached state S₁.”

That statement is an assertion.

Formally, an assertion includes:

Start state root
End state root
Number of execution steps
Inbox position (which L1 messages were consumed)

⚠️ Ethereum does NOT execute those steps immediately.
It just records the claim.

3️⃣ How user operations become assertions

Step-by-step flow


User sends TX
 ↓
Sequencer executes TXs in AVM
 ↓
AVM produces many instruction steps
 ↓
Sequencer bundles them into:
   Assertion:
     (state_before → state_after)
 ↓
Assertion is posted to Ethereum

Ethereum only sees:

“Here is the new state root”
“Trust me, I executed these steps correctly”

This is optimistic by default.

4️⃣ What happens if someone challenges?

Now the magic starts.

Challenger says:

“I don’t believe this assertion.”

Ethereum now forces interactive verification.

5️⃣ Interactive fraud proof (binary search idea)

Imagine the assertion claims:

“I executed 1,000,000 steps correctly”

Ethereum does NOT re-run 1M steps.

Instead:

Round 1


Was the error in:
[ steps 1 – 500,000 ] OR [ 500,001 – 1,000,000 ] ?

Sequencer picks one half
Challenger picks the other if they disagree

Round 2


Now narrow to 250,000 steps

Repeat…


1,000,000
→ 500,000
→ 250,000
→ 125,000
→ ...
→ 1 single instruction

This takes:


log₂(1,000,000) ≈ 20 rounds

6️⃣ Final step: L1 executes ONE instruction

At the end:

Ethereum executes exactly one AVM instruction
That instruction is tiny
Gas cost is minimal

Ethereum checks:


Input state → instruction → output state

If:

Output ≠ claimed output → sequencer is slashed
Output matches → challenger loses stake

7️⃣ Why this is massively cheaper than Optimism

Optimism fraud proof

Re-executes entire transaction
Can be:
- Thousands of EVM opcodes
- Complex contract logic
High L1 gas cost

Arbitrum fraud proof

Executes 1 instruction
Plus:
- A few hash comparisons
Extremely low L1 gas cost

8️⃣ Key insight (this is the core idea)

Arbitrum moves verification from “transaction-level” to “instruction-level.”

That’s it.
That’s the entire advantage.

9️⃣ Analogy (very important for intuition)

Optimism = Court replaying the whole crime

“Let’s replay everything from start to end.”

Arbitrum = Debugger with breakpoints

“Show me the exact line of code that’s wrong.”

🔑 Final summary (commit this to memory)

Assertion = a claim about a state transition after N execution steps
Ethereum stores claims, not executions
Fraud proofs:
- Use interactive binary search
- Narrow dispute to one instruction
Only one instruction is executed on Ethereum
This makes fraud proofs:
- Cheaper
- More scalable
- More complex to design