In our previous discussion, we explored the core components of Arbitrum, including the Sequencer, Validator, Sequencer Inbox contract, Rollup Block, and non-interactive fraud proofs. Today, we delve deeper into the components related to cross-chain message passing and censorship-resistant transaction entry points.
How Cross-Chain and Bridging Work
Cross-chain transactions can be categorized into two directions: L1 to L2 (deposits) and L2 to L1 (withdrawals). It’s important to note that these terms don’t solely refer to asset transfers—they can also include message passing without direct asset involvement.
Unlike pure L2 transactions, cross-chain transactions involve exchanging information between two distinct systems (L1 and L2), making the process more complex. Traditional cross-chain bridges often rely on witness models, where security depends on the bridge operators. Unfortunately, such bridges have been frequently exploited in the past.
In contrast, cross-chain interactions between Rollups and Ethereum are fundamentally different. The state of a Layer2 is determined by data recorded on Layer1. When using the official Rollup bridge, the structure is inherently secure.
This highlights the essence of Rollups: while they appear as independent chains to users, Layer2 is essentially a fast display window, with the actual chain structure recorded on Layer1. Thus, we can think of L2 as a "half-chain" or a "chain created atop Layer1."
Retryable Tickets
Cross-chain transactions are asynchronous and non-atomic. They cannot guarantee immediate confirmation or outcomes on the other side. However, by using tools like Retryable Tickets, users can avoid hard failures such as stuck funds.
Retryable Tickets are fundamental tools for deposits via the Arbitrum official bridge, used for both ETH and ERC20 transfers. Their lifecycle consists of three steps:
- Submission on L1: Users create a deposit ticket by calling
createRetryableTicket()in the Delayed Inbox contract. - Automatic Redemption on L2: In most cases, the Sequencer automatically redeems the ticket without requiring manual intervention.
- Manual Redemption on L2: In edge cases (e.g., sudden gas price spikes), automatic redemption may fail. Users must manually redeem the ticket within 7 days to avoid permanent loss or pay a fee to extend the ticket’s validity.
Withdrawals via the official bridge, while symmetric in flow, do not involve Retryables. Key differences include:
- No Automatic Redemption: Since the EVM lacks timers or automation, users must manually interact with the Outbox contract to claim assets.
- No Expiration: Withdrawals can be claimed at any time after the challenge period ends.
ERC-20 Asset Bridging with Gateways
ERC-20 asset bridging introduces several complexities:
- How should an L1-deployed token be deployed on L2?
- Can the system auto-deploy token contracts for cross-chain transfers?
- Should L2 token addresses match their L1 counterparts?
- How can natively issued L2 tokens cross to L1?
- How do tokens with special features (e.g., rebase or interest-bearing tokens) bridge?
Many scaling solutions use whitelists and manual listings to avoid edge cases. Arbitrum employs a Gateway system to address most ERC-20 bridging pain points:
- Gateway components exist in pairs on L1 and L2.
- The Gateway Router maintains address mappings between L1 and L2 tokens and between tokens and their gateways.
- Gateways can be standardized (e.g., StandardERC20) or customized (e.g., Generic-custom, Custom) to handle diverse token functionalities.
Consider WETH bridging as an example. WETH is an ERC-20 equivalent of ETH. Bridging WETH directly would cause issues:
- Unwrapping WETH to ETH on L2 is impossible since no ETH is locked on L2.
- Wrapping functions work, but WETH bridged back to L1 cannot be unwrapped because L1 and L2 WETH contracts are not symmetric.
Thus, WETH must be unwrapped to ETH before bridging and rewrapped on the destination chain. This is the role of the WETH Gateway. Similarly, tokens with complex logic require custom Gateways to function correctly in cross-chain environments.
Delayed Inbox (Slow Box)
The Delayed Inbox (often called the slow box) complements the Sequencer Inbox (fast box). While the fast box receives transaction batches from the Sequencer, the slow box handles transactions not pre-processed by the Sequencer.
The Delayed Inbox serves two primary purposes:
- Processing L1-to-L2 Deposits: Users submit deposits via the slow box. The Sequencer monitors these submissions, reflects them on L2, and includes them in the transaction sequence submitted to the Sequencer Inbox.
Censorship Resistance: Transactions submitted to the Delayed Inbox are typically aggregated into the fast box within 10 minutes. If the Sequencer maliciously ignores a request, users can invoke force inclusion after 24 hours:
- Users manually trigger the
forceInclusion()function on Layer1. - The ignored transaction is forced into the Sequencer Inbox.
- Arbitrum One nodes then include it in the L2 transaction sequence.
- Users manually trigger the
This mechanism ensures that transactions, including forced withdrawals, eventually reach the L2 ledger, mitigating censorship risks.
Key functions of the Delayed Inbox:
depositETH(): Simplifies ETH deposits.createRetryableTicket(): Offers flexibility for ETH, ERC20, and message deposits (e.g., specifying L2 recipient addresses).forceInclusion(): Allows anyone to force the inclusion of delayed transactions after 24 hours.
Outbox
The Outbox manages withdrawals exclusively. It acts as a record-keeping system for withdrawal requests:
- After the ~7-day challenge period ends and the Rollup Block finalizes, users submit Merkle proofs to the Outbox contract on Layer1.
- The Outbox communicates with other contracts (e.g., to unlock assets) and finalizes withdrawals.
- To prevent replay attacks, the Outbox uses a mapping (
spent) to track processed withdrawal requests. Ifmapping[spentIndex] != bytes32(0), the request has already been executed.
ETH Deposit and Withdrawal Flow
ETH Deposit
- User submits a deposit transaction to the Delayed Inbox on L1.
- The Sequencer detects the deposit and includes it in the L2 transaction sequence.
- The deposit is reflected in the user’s L2 balance.
ETH Withdrawal
- User initiates a withdrawal on L2, triggering a withdrawal request.
- The request enters a challenge period (~7 days) for fraud proofs.
- After the challenge period, the user submits a Merkle proof to the Outbox on L1.
- The Outbox verifies the proof and releases the funds to the user.
Fast Withdrawals
Using the official Optimistic Rollup bridge requires waiting through the challenge period. Third-party bridges offer alternatives:
- Atomic Swaps: Enable peer-to-peer asset swaps with atomicity. However, liquidity can be scarce.
- Witness Bridges: Operators monitor L2 and facilitate instant withdrawals based on submitted data. These bridges are convenient but less secure than the official bridge.
👉 Explore secure bridging options
Force Withdrawal
The forceInclusion() function combats Sequencer censorship. It applies to L2 local transactions, L1-to-L2 transactions, and L2-to-L1 transactions. In cases of malicious censorship, users may opt to force withdrawals:
Steps for Force Withdrawal:
- Call
inbox.sendL2Message()on L1, inputting parameters forwithdrawEth()on L2. - Wait 24 hours for the force inclusion period.
- Call
forceInclusion()in the Sequencer Inbox to aggregate the message. - Complete the withdrawal via the Outbox, following standard steps.
Detailed tutorials using the Arbitrum SDK are available for force inclusion scenarios.
Frequently Asked Questions
What is the difference between the Sequencer Inbox and Delayed Inbox?
The Sequencer Inbox (fast box) receives pre-processed transaction batches from the Sequencer. The Delayed Inbox (slow box) handles direct user submissions, such as deposits, and provides censorship resistance via force inclusion.
How long does a withdrawal take via the official bridge?
Withdrawals require a ~7-day challenge period for fraud proofs. Afterward, users can claim funds on L1. Third-party bridges may offer faster withdrawals but with reduced security.
Can Retryable Tickets expire?
Yes. If automatic redemption fails, users must manually redeem tickets within 7 days to avoid permanent loss or pay a fee to extend validity.
What is the role of Gateways in ERC-20 bridging?
Gateways manage the complexities of ERC-20 bridging, including address mapping, auto-deployment, and handling custom token logic. They ensure secure and functional cross-chain transfers.
How does force inclusion work?
If the Sequencer ignores a transaction in the Delayed Inbox for 24 hours, users can force its inclusion into the Sequencer Inbox. This ensures transaction execution despite censorship.
Are third-party bridges safe for withdrawals?
Witness-based bridges offer convenience but rely on external operators. Official bridges provide higher security by leveraging Ethereum’s consensus. Users should weigh speed against security risks.