Former Arbitrum Tech Ambassador Explains Arbitrum's Component Architecture (Part 2)
TechFlow Selected TechFlow Selected
Former Arbitrum Tech Ambassador Explains Arbitrum's Component Architecture (Part 2)
How does Arbitrum handle cross-chain message passing and censorship-resistant transactions?
Navigating Web3 tides with focused insightsAuthor: Luo Benben, Former Arbitrum Technical Ambassador, Web3 Enthusiast Contributor
In the previous article, "Former Arbitrum Technical Ambassador Explains Arbitrum's Component Architecture (Part 1)", we introduced key components of Arbitrum including the Sequencer, Validators, Sequencer Inbox contract, Rollup Blocks, and Non-Interactive Fraud Proofs. In today’s article, we will focus on components related to cross-chain message passing and censorship-resistant transaction entry points within Arbitrum’s core architecture.
Previously, we mentioned that the Sequencer Inbox contract is responsible for receiving transaction data batches (Batches) posted by the Sequencer on Layer 1. Additionally, we noted that the Sequencer Inbox is also known as the "fast inbox," while its counterpart is the Delayed Inbox (commonly referred to as the "slow inbox"). Below, we will provide a detailed explanation of the Delayed Inbox and other components related to cross-chain messaging.
Principles of Cross-Chain and Bridging
Cross-chain transactions can be categorized into two types: L1 to L2 (deposit) and L2 to L1 (withdrawal). Note that these terms—deposit and withdrawal—do not necessarily involve asset transfers; they may simply refer to message passing without attached assets. Thus, these terms merely indicate the two directions of cross-chain actions.
Compared to purely L2 transactions, cross-chain transactions involve information exchange between two distinct systems—L1 and L2—and are therefore more complex.
Moreover, typical cross-chain operations occur between two unrelated networks using custodial ("witness-based") bridges, whose security depends entirely on the bridge operator. Historically, witness-based bridges have frequently been compromised.
However, cross-chain interactions between a Rollup and the Ethereum mainnet differ fundamentally because the state of Layer 2 is determined by data recorded on Layer 1. As long as you use the official Rollup bridge, its operational structure is absolutely secure.
This highlights the essence of Rollups: from the user's perspective, it appears like an independent chain, but in reality, the so-called "Layer 2" is merely a fast interface exposed by the Rollup—the true chain structure remains inscribed on Layer 1. Therefore, we might consider L2 as half a chain, or “a chain created atop Layer 1.”
Retryable Tickets
It should be noted that cross-chain operations are asynchronous and non-atomic. Unlike on a single chain, where results are immediately confirmed after execution, cross-chain transactions cannot guarantee that certain events will happen at specific times on the other side. As such, cross-chain transactions may fail due to soft issues. However, with proper mechanisms like Retryable Tickets, hard failures such as fund lockups can be avoided.
Retryable Tickets are fundamental tools used when depositing via the official Arbitrum bridge, applicable for both ETH and ERC20 deposits. Their lifecycle consists of three steps:
1. Submitting the ticket on L1. Use the createRetryableTicket() method in the Delayed Inbox contract to create and submit a deposit ticket.
2. Automatic redemption on L2. In most cases, the Sequencer automatically redeems the ticket on behalf of the user, requiring no further manual action.
3. Manual redemption on L2. In edge cases—such as sudden spikes in L2 gas prices causing insufficient prepaid gas—the ticket cannot be redeemed automatically and requires user intervention.
Note: If automatic redemption fails, the user must manually redeem the ticket within 7 days; otherwise, the ticket will either be deleted (resulting in permanent loss of funds) or require payment for renewal to keep it active.
Additionally, although the withdrawal process via the Arbitrum official bridge shares some symmetry with deposits, there is no concept of Retryables in withdrawals. This can be understood both from the Rollup protocol design and through several distinctions:
-
There is no automatic redemption during withdrawals, since the EVM lacks timers or automation. Automatic redemption on L2 is possible only because the Sequencer facilitates it. Hence, users must manually interact with the Outbox contract on L1 to claim their assets.
-
Withdrawals do not suffer from ticket expiration; once the challenge period ends, assets can be claimed at any time.
ERC-20 Asset Gateway
Cross-chain handling of ERC-20 assets is complex. Consider the following questions:
-
How should a token deployed on L1 be deployed on L2?
-
Does its corresponding L2 contract need to be manually pre-deployed, or can the system automatically deploy asset contracts for tokens crossing over that haven't yet been deployed?
-
What is the contract address of an L1 ERC-20 asset on L2? Should it match the L1 address?
-
How can native L2-issued tokens be bridged back to L1?
-
How to handle tokens with special features, such as rebase tokens with adjustable supply or self-compounding interest-bearing tokens?
We won’t answer all these questions here, as doing so would be overly complex. These are merely meant to illustrate the intricacies involved in ERC-20 cross-chain bridging.
Currently, many scaling solutions adopt whitelists and manual curation to avoid various complexities and edge cases.
Arbitrum uses a Gateway system that resolves most pain points associated with ERC-20 bridging, featuring the following characteristics:
-
Gateway components appear in pairs on L1 and L2.
-
The Gateway Router maintains mappings between Token L1 <-> Token L2 addresses, as well as mappings between specific tokens and their respective gateways.
-
Gateways are categorized into StandardERC20 gateway, Generic-custom gateway, Custom gateway, etc., each designed to handle different types and functionalities of ERC20 tokens.
Let’s take WETH bridging as a simple example to demonstrate the necessity of custom gateways.
WETH is an ERC20 equivalent of ETH. Since Ether, as the native coin, cannot support complex functions in many dApps, an ERC20 wrapper is needed. Depositing ETH into the WETH contract locks it and mints an equal amount of WETH.
Likewise, WETH can be burned to withdraw ETH. Clearly, the circulating supply of WETH always matches 1:1 with the locked ETH balance.
If WETH were directly bridged to L2, strange issues would arise:
-
Unwrapping WETH into ETH on L2 would be impossible, as there is no corresponding ETH locked on L2.
-
Wrapping functionality could still work, but newly minted WETH sent back to L1 couldn't be unwrapped into ETH, because the WETH contracts on L1 and L2 are not symmetric.
This clearly violates the design principle of WETH. Hence, whenever WETH crosses chains—whether depositing or withdrawing—it must first be unwrapped into ETH, transferred across, then re-wrapped into WETH on the destination chain. This is precisely what the WETH Gateway accomplishes.
Similarly, tokens with more complex logic require equally sophisticated and carefully designed Gateways to function correctly in cross-chain environments. Arbitrum’s custom Gateways inherit standard cross-chain communication logic while allowing developers to define custom behaviors tied to token-specific logic, satisfying most use cases.
Delayed Inbox (Slow Inbox)
The counterpart to the fast inbox (SequencerInbox) is the slow inbox (Inbox), formally known as the Delayed Inbox. Why distinguish between fast and slow? Because the fast inbox exclusively receives L2 transaction batches published by the Sequencer. Any transaction未经preprocessing by the Sequencer within the L2 network should not appear in the fast inbox contract.
The first role of the Delayed Inbox is to handle L1-to-L2 deposits. When users deposit via the Delayed Inbox, the Sequencer listens for these messages and reflects them on L2. Eventually, this deposit record is included by the Sequencer in an L2 transaction batch and submitted to the fast inbox (Sequencer Inbox) contract on L1.
In this case, directly submitting deposit transactions to the fast inbox would be inappropriate, as it would interfere with normal L2 transaction ordering and disrupt Sequencer operations.
The second role of the Delayed Inbox is censorship resistance. Transactions submitted directly to the Delayed Inbox are typically aggregated into the fast inbox by the Sequencer within 10 minutes. However, if the Sequencer maliciously ignores your request, the Delayed Inbox provides a force inclusion mechanism:
If a transaction submitted to the Delayed Inbox remains unprocessed by the Sequencer for 24 hours, users can manually trigger the force inclusion function on Layer 1 to forcibly include the ignored transaction into the Sequencer Inbox. Afterward, all Arbitrum One nodes will detect it and it will be mandatorily included in the Layer 2 transaction sequence.
As previously mentioned, the data in the fast inbox constitutes the actual historical ledger of L2. Therefore, under censorship attempts, the Delayed Inbox ensures that transaction instructions are eventually included in the L2 ledger—including critical scenarios such as forced withdrawals to exit Layer 2.
Thus, it becomes evident that the Sequencer cannot permanently censor transactions in any direction or layer.
Key functions of the Delayed Inbox:
-
depositETH(): The simplest function for depositing ETH.
-
createRetryableTicket(): Can be used for depositing ETH, ERC20 tokens, or general messages. Offers greater flexibility than depositETH(), such as specifying the recipient address on L2 post-deposit.
-
forceInclusion(): Also known as the forced inclusion feature, callable by anyone. This function verifies whether a transaction submitted to the Delayed Inbox has remained unprocessed for over 24 hours. If so, it forces the message inclusion.
Note, however, that the forceInclusion function actually resides in the fast inbox contract; we discuss it here alongside the Delayed Inbox for clarity.
Outbox
The Outbox is solely related to withdrawals and can be understood as a record and management system for withdrawal actions:
-
We know that withdrawals via the official Arbitrum bridge require waiting approximately 7 days for the challenge period to end and for the Rollup Block to finalize before the withdrawal can proceed. After the challenge period, users submit the corresponding Merkle Proof to the Outbox contract on Layer 1, which then communicates with other contracts (e.g., unlocking assets held in escrow) to complete the withdrawal.
-
The Outbox contract records which L2-to-L1 cross-chain messages have already been processed, preventing repeated execution of completed withdrawal requests. It uses
-
mapping(uint256 => bytes32) public spent, to map spent indices to message identifiers. If mapping[spentIndex] != bytes32(0), the request has already been withdrawn. This works similarly to a nonce counter preventing replay attacks.
Next, we will walk through the full deposit and withdrawal processes using ETH as an example. ERC20 follows the same flow except through Gateways, which we will not repeat.
ETH Deposit
1. User calls the depositETH() function on the Delayed Inbox.
2. This function internally calls bridge.enqueueDelayedMessage(), recording the message in the bridge contract and sending the ETH to the bridge contract. All deposited ETH funds are held within the bridge contract, acting as a deposit address.
3. The Sequencer detects the deposit message in the Delayed Inbox and reflects the deposit in the L2 database, making the assets visible to the user on L2.
4. The Sequencer includes this deposit record in a transaction batch and submits it to the Sequencer Inbox contract on L1.
ETH Withdrawal
1. User calls the withdrawEth() function on the ArbSys contract on L2, burning the specified amount of ETH.
2. The Sequencer sends this withdrawal request to the Sequencer Inbox.
3. Validator nodes generate a new Rollup Block based on the transaction sequence in the Sequencer Inbox, which includes the aforementioned withdrawal transaction.
4. Once the Rollup Block passes the challenge period and is finalized, the user can call Outbox.executeTransaction() on L1, providing parameters derived from the ArbSys contract.
5. Upon verification, the Outbox contract unlocks the corresponding ETH from the bridge and sends it to the user.
Fast Withdrawals
Using the official Optimistic Rollup bridge results in a waiting period due to the challenge window. Third-party private bridges can bypass this issue:
-
Atomic swap locking. This method involves swapping assets between parties on their respective chains atomically—if one party reveals the preimage, both receive their assets. However, liquidity is scarce and requires peer-to-peer coordination.
-
Custodial bridges (Witness Bridges). Most third-party bridges fall into this category. Users submit withdrawal requests directing funds to the bridge operator or liquidity pool. Once the witness observes the transaction submitted to the Sequencer Inbox on L1, they immediately transfer funds on L1 to the user. Essentially, this uses an alternative consensus system to monitor Layer 2 and act upon data committed to Layer 1. However, security in this model is lower compared to the official Rollup bridge.
Forced Withdrawals
The forceInclusion() function combats Sequencer censorship and can be used for any type of transaction—local L2, L1-to-L2, or L2-to-L1. Malicious censorship severely impacts user experience, and in most cases, users opt to withdraw from L2. Below, we illustrate how forceInclusion works using forced withdrawal as an example.
Recall that in the ETH withdrawal steps, only steps 1 and 2 involve potential Sequencer censorship. Therefore, only these steps need modification:
-
Call inbox.sendL2Message() on the Delayed Inbox contract on L1, inputting the same parameters required for calling withdrawEth() on L2. This message is shared with the bridge contract on L1.
-
After the 24-hour forced inclusion waiting period, call forceInclusion() on the Sequencer Inbox to forcibly include the message. The Sequencer Inbox contract checks whether the corresponding message exists in the bridge.
Ultimately, the user can withdraw via the Outbox; remaining steps follow the normal withdrawal process.
Additionally, arbitrum-tutorials provides detailed guides using the Arb SDK to help users perform local L2 transactions and L2-to-L1 transactions via forceInclusion().
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
