Arbitrum's Component Structure Explained (Part 2)

Introduction

This article provides a technical deep-dive into Arbitrum One by a former Arbitrum technical ambassador and co-founder of Goplus Security. Following Part 1's exploration of core components like Sequencers, Validators, and Rollup Blocks, we now focus on cross-chain messaging and anti-censorship mechanisms.

Cross-Chain Messaging Fundamentals

Layer Bridges vs. Traditional Bridges

• Traditional Bridges: Rely on third-party validators, making them vulnerable to hacks (e.g., frequent cross-chain bridge exploits).
• Rollup Bridges: Inherently secure as L2 state roots are recorded on Ethereum. Transactions via official Rollup bridges are trustless.

Key Insight: L2 is essentially a "half-chain" — its true ledger exists on Ethereum, with L2 acting as a high-speed interface.

Cross-Chain Transaction Types

1. Deposits (L1→L2): Fund/message transfers to L2.
2. Withdrawals (L2→L1): Require a 7-day challenge period for finality.

Core Components

1. Retryable Tickets

For deposit reliability, Arbitrum uses Retryable Tickets:

• Lifecycle:

  1. Submit via createRetryableTicket() in Delayed Inbox.
  2. Auto-redemption by Sequencer (usually within minutes).
  3. Manual redemption if auto-fails (must complete within 7 days).

⚠️ Critical: Unredeemed tickets expire, leading to permanent fund loss.

2. Delayed Inbox (Slow Box)

Purposes:

• Processes L1→L2 deposits (e.g., ETH/ERC-20 transfers).
• Anti-censorship via force inclusion: Bypass sequencer censorship after 24-hour delay using forceInclusion().

👉 How force inclusion works

3. Gateways (ERC-20 Bridges)

Arbitrum's Gateway system solves complex ERC-20 cross-chain challenges:

• Standard vs. Custom Gateways: Handle token-specific logic (e.g., WETH unwrapping before bridging).
• Address Mapping: Gateway Router maintains L1↔L2 token address links.

Example: WETH requires a custom gateway to unwrap ETH before bridging.

4. Outbox

Manages L2→L1 withdrawals post-challenge period:

• Users submit Merkle proofs to Outbox.executeTransaction().
• Prevents replay attacks via spent mapping (similar to nonces).

Transaction Flows

ETH Deposit

1. Call depositETH() in Delayed Inbox.
2. ETH locks in Bridge contract.
3. Sequencer detects & reflects balance on L2.
4. Sequencer batches tx to Sequencer Inbox.

ETH Withdrawal

1. Burn ETH via withdrawEth() on L2.
2. Sequencer submits to Sequencer Inbox.
3. After 7 days, claim via Outbox + Merkle proof.

Advanced Scenarios

Fast Withdrawals

Third-party bridges offer instant withdrawals but introduce trust:

• Atomic Swaps: P2P liquidity-limited.
• Witness Bridges: Faster but less secure than official bridges.

Force Inclusion for Censorship Resistance

1. Submit withdrawal via inbox.sendL2Message().
2. Wait 24 hours + call forceInclusion().
3. Proceed with normal Outbox claim.

Tutorials available via Arbitrum SDK (guide link).

FAQs

Q: Why does Arbitrum need both fast and slow inboxes?

A: Sequencer Inbox (fast) handles pre-processed L2 txs; Delayed Inbox (slow) manages deposits/censorship-resistant txs.

Q: Are Retryable Tickets needed for withdrawals?

A: No. Withdrawals use Merkle proofs via Outbox without expiration.

Q: How does force inclusion combat censorship?

A: After 24h delay, users can forcibly include txs in Sequencer Inbox, ensuring eventual L2 processing.

For further reading, explore Arbitrum's developer documentation.