Former Arbitrum Tech Ambassador: Arbitrum's Component Structure (Part 2)

Main Text: In previous articles, we mentioned that the Sequencer Inbox contract is specifically designed to receive batches of transaction data published by the sequencer on Layer 1. At the same time, we pointed out that the Sequencer Inbox is also referred to as the “fast box,” with the counterpart being the Delayed Inbox (referred to as Inbox). Next, we will provide a detailed explanation of components related to cross-chain message transmission, such as the Delayed Inbox.

The principle of cross-chain and bridging

Cross-chain transactions can be divided into L1 to L2 (deposit) and L2 to L1 (withdrawal). Note that the deposit and withdrawal mentioned here are not necessarily related to cross-chain assets, but can be messaging that does not directly include assets. So these two words only represent two directions of cross-chain related behaviors.

Compared with pure L2 transactions, cross-chain transactions exchange information in two different systems, L1 and L2, so the process is more complicated.

In addition, what we usually call cross-chain behavior is cross-chain on two unrelated networks using a witness-mode cross-chain bridge. The security of this cross-chain depends on the cross-chain bridge. Historically, cross-chain bridges based on a witness mode have frequently experienced theft incidents.

In contrast, cross-chain behavior between Rollup and the Ethereum mainnet is fundamentally different from the aforementioned cross-chain operations. This is because the state of Layer 2 is determined by data recorded on Layer 1. As long as you use the official Rollup cross-chain bridge, its operational structure is absolutely secure.

This also highlights the essence of Rollup, which, from the user’s perspective, appears as an independent chain. However, in reality, the so-called “Layer 2” is just a fast display window opened by Rollup to users, and its true chain-like structure is still recorded on Layer 1. Therefore, we can consider L2 as half a chain, or as a “chain created on Layer 1.”

Retryables

It’s important to note that cross-chain operations are asynchronous and non-atomic. Unlike on a single chain where the outcome of a transaction is known once it’s confirmed, cross-chain transactions cannot guarantee that certain events will occur on the other side at a specific time. Therefore, cross-chain transactions may fail due to soft issues, but with the correct methods, such as Retryable Tickets, there won’t be any issues like funds getting stuck.

Retryable Tickets are basic tools used when depositing funds through the Arbitrum official bridge for both ETH and ERC20 tokens. Its lifecycle consists of three steps:

1. Submitting the ticket on L1: Create a deposit ticket using the createRetryableTicket() method in the Delayed Inbox contract and submit it.

2. Automatic redemption on L2: In most cases, the sequencer can automatically redeem the ticket for the user without further manual intervention.

3. Manual redemption on L2: In certain edge cases, such as a sudden increase in gas prices on L2 where the prepaid gas on the ticket is insufficient, automatic redemption may fail. In such cases, manual intervention by the user is required. Note that if automatic redemption fails, the ticket must be manually redeemed within 7 days; otherwise, the ticket may either be deleted (resulting in permanent loss of funds) or require payment of a fee to renew its lease.

Furthermore, in the withdrawal process of the Arbitrum official bridge, although there is some symmetrical similarity with the deposit behavior in terms of the process, there is no concept of Retryables. This can be understood both from the perspective of the Rollup protocol itself and by examining some differences:

• There is no automatic redemption during withdrawal because the EVM does not have timers or automation. While automatic redemption can be implemented on L2 with the assistance of the sequencer, users on L1 need to manually interact with the Outbox contract to claim their assets.

• There is also no issue of ticket expiration during withdrawal; as long as the challenge period has passed, assets can be claimed at any time.

ERC-20 Asset Cross-Chain Gateway

Cross-chain transactions involving ERC-20 assets are complex. We can consider several questions:

• How is a token deployed on L2 if it’s deployed on L1?
• Should its corresponding contract on L2 be deployed manually in advance, or can the system automatically deploy asset contracts for tokens that have been transferred but not yet deployed?
• What is the contract address of an ERC-20 asset on L2 corresponding to its address on L1? Should it match the address on L1?
• How are tokens issued natively on L2 cross-chained to L1?
• How do tokens with special functionalities, such as adjustable supply Rebase tokens or auto-staking tokens, cross-chain?

We don’t intend to answer all these questions as they are too complex to address comprehensively. These questions are simply meant to illustrate the complexity of ERC-20 cross-chain transactions.

Currently, many scaling solutions use whitelist + manual list solutions to avoid various complex problems and boundary conditions.

Arbitrum employs a Gateway system to address most pain points of ERC20 cross-chain transactions, featuring the following characteristics:

• The Gateway components appear in pairs on both L1 and L2.
• The Gateway Router is responsible for maintaining the address mappings between Token L1 <-> Token L2 and some token <-> some gateway.
• The Gateway itself can be divided into various types, such as StandardERC20 gateway, Generic-custom gateway, Custom gateway, etc., to address bridging issues for different types and functionalities of ERC20 tokens.

To illustrate the necessity of custom gateways, let’s consider a relatively simple example of cross-chain WETH transfer.

WETH is an ERC20 equivalent of ETH. Since Ether serves as the primary currency, many complex functionalities in dApps are impossible to achieve directly. Hence, an ERC20 equivalent like WETH is needed. By depositing some ETH into the WETH contract, they are locked within the contract, generating an equivalent amount of WETH.

Likewise, WETH can be burned to withdraw ETH. Clearly, the circulating amount of WETH and the locked amount of ETH will always maintain a 1:1 ratio.

If we now directly cross-chain WETH to L2, we will find some strange problems:

• It is impossible to Unwrap WETH into ETH on L2 because there is no corresponding ETH for locking on L2.
• The Wrap function can be used, but if these newly generated WETH are crossed back to L1, they cannot be unwrapped into ETH on L1 becauseWETH contracts on L1 and L2 are not “symmetric”。

Clearly, this violates the design principles of WETH. Therefore, when crossing WETH cross-chain, whether depositing or withdrawing, it’s necessary to unwrap it into ETH first, then cross it over, and wrap it back into WETH. This is where the WETH Gateway comes into play.

Similarly, for other tokens with more complex logics, they require more sophisticated and carefully designed Gateways to function properly in a cross-chain environment. Arbitrum’s custom Gateway inherits the cross-chain communication logic of a standard Gateway and allows developers to customize cross-chain behaviors related to token logics, satisfying most requirements.

Delayed Inbox

The counterpart of the SequencerInbox, also known as the fast box, is the Inbox (officially named Delayed Inbox). Why does it make a distinction between fast and delayed boxes? Because the fast box is specifically designed to receive batches of L2 transactions published by the sequencer, and any transactions not pre-processed by the sequencer within the L2 network should not appear in the fast box contract.

The first role of the slow box is to handle the deposit behavior from L1 to L2. Users initiate deposits through the slow box, which the sequencer then reflects on L2. Eventually, this deposit record will be included in the L2 transaction sequence by the sequencer and submitted to the fast box contract, the SequencerInbox.

In this scenario, it’s inappropriate for users to directly submit deposit transactions to the fast box because transactions submitted to the SequencerInbox would interfere with the normal transaction sequencing of Layer 2, thus affecting the sequencer’s operation.

The second role of the delayed box is censorship resistance. Transactions directly submitted to the delayed box contract are typically aggregated into the fast box within 10 minutes by the sequencer. However, if the sequencer maliciously ignores your request, the delayed box has a force inclusion feature:

If a transaction is submitted to the Delayed Inbox and remains unaggregated into the transaction sequence by the sequencer after 24 hours, users can manually trigger the force inclusion function on Layer 1. This action forces the transaction requests ignored by the sequencer to be aggregated into the fast box, the SequencerInbox, and subsequently be detected by all Arbitrum One nodes, thus being forcefully included in the Layer 2 transaction sequence.

As we mentioned earlier, the data in the fast box represents the historical data entity of L2. Therefore, in cases of malicious censorship, transactions can be ultimately included in the L2 ledger by using the delayed box, covering scenarios such as forced withdrawals from Layer 2.

From this, it can be seen that the sequencer ultimately cannot permanently censor transactions in any direction or layer.

Several core functions of the slow box Inbox are as follows:

• depositETH(): This function is the simplest method for depositing ETH.
• createRetryableTicket(): This function can be used for depositing ETH, ERC20 tokens, and messages. Compared to depositETH(), it offers greater flexibility, such as specifying the receiving address on L2 after the deposit.
• forceInclusion(): Also known as the force inclusion function, which can be called by anyone. This function verifies whether a transaction submitted to the slow box contract has not been processed after 24 hours. If the condition is met, the function forcefully aggregates the message.

However, it’s important to note that the forceInclusion() function actually resides in the fast box contract. For clarity, we discussed it here alongside the slow box functions.

Outbox

Outbox is only related to withdrawals and can be understood as a recording and management system for withdrawal behaviors:

• We know that withdrawals on the Arbitrum official bridge need to wait for about 7 days for the challenge period to end, and the withdrawal can only be implemented after the Rollup Block is finalized. After the challenge period ends, the user submits the corresponding Merkle Proof to the Outbox contract on Layer1, which then communicates with contracts for other functions (such as unlocking assets locked in other contracts), and finally completes the withdrawal.
• The OutBox contract records which L2 to L1 cross-chain messages have been processed to prevent someone from repeatedly submitting executed withdrawal requests. It achieves this through a mapping called spent, which associates withdrawal requests’ spent indices with their corresponding information. If mapping[spentIndex] != bytes32(0), it indicates that the request has already been withdrawn. The principle is similar to that of a transaction counter nonce, used to prevent replay attacks.

Below, we will explain the process of depositing and withdrawing using ETH as an example. The process for ERC20 tokens is similar, with the addition of a Gateway, but we will not elaborate on that here.

ETH Deposit

1. The user calls the depositETH() function of the Delayed Inbox.
2. This function then calls bridge.enqueueDelayedMessage(), which records the message in the bridge contract and sends the ETH to the bridge contract. All deposited ETH funds are held in the bridge contract, acting as a deposit address.
3. The sequencer monitors the deposit message in the Delayed Inbox and reflects the deposit operation in the L2 database. Users can see their deposited assets on the L2 network.
4. The sequencer includes the deposit record in a batch of transactions and submits it to the Fast Inbox contract on L1.

ETH withdrawal

1. The user calls the withdrawEth() function of the ArbSys contract on L2 and burns the corresponding amount of ETH on L2.

2. The sequencer sends the withdrawal request to the fast box.

3. The Validator node creates a new Rollup Block based on the transaction sequence in the fast box, which will contain the above withdrawal transactions.

4. After the Rollup Block passes the challenge period and is confirmed, the user can call the Outbox.execute Transaction() function on L1 to prove that the parameters are given by the ArbSys contract mentioned above.

5. After the Outbox contract is confirmed to be correct, the corresponding amount of ETH in the bridge will be unlocked and sent to the user.

Fast Withdrawals

Using the optimistic Rollup official bridge involves waiting for a challenge period. To bypass this issue, we can utilize a private third-party cross-chain bridge:

• Atomic Swap Exchange: In this approach, assets are exchanged between parties within their respective chains, and it’s atomic, meaning if one party provides the preimage, both parties can obtain the corresponding assets. However, liquidity is relatively scarce, requiring peer-to-peer search for counterparties.
• Witness-based Cross-Chain Bridge: Most types of cross-chain bridges fall into this category. Users submit their withdrawal requests, specifying the destination as the operator or liquidity pool of the third-party bridge. Once the witness discovers that the cross-chain transaction has been submitted to the Fast Inbox contract on L1, they can directly transfer funds to the user on L1. Essentially, this method uses another consensus system to monitor Layer 2 and perform operations based on the data submitted to Layer 1. However, the security level in this mode is lower compared to the Rollup official bridge.

Force withdrawal

The forceInclusion() function is used to counteract sequencer censorship. It can be applied to any L2 local transactions, L1 to L2 transactions, and L2 to L1 transactions. Since the sequencer’s malicious censorship significantly affects the transaction experience, we often choose to withdraw from L2. Below is an example of using forceInclusion() for force withdrawals:

In the context of ETH withdrawals, only steps 1 and 2 involve sequencer censorship. Therefore, we only need to modify these two steps:

• Call inbox.sendL2Message() in the Delayed Inbox contract on L1, with the parameters required when calling withdrawEth() on L2. This message is shared with the bridge contract on L1.
• After waiting for the 24-hour force inclusion waiting period, call forceInclusion() in the Fast Inbox contract to force inclusion. The Fast Inbox contract will check if there is a corresponding message in the bridge.

Finally, users can withdraw from the Outbox, and the remaining steps are the same as in a normal withdrawal process.

Additionally, there are detailed tutorials in the arbitrum-tutorials repository guiding users on how to perform L2 local transactions and L2 to L1 transactions using forceInclusion() through the Arb SDK.

Disclaimer：

1. This article is reprinted from [Geek Web3], All copyrights belong to the original author [Luo Benben, former Arbitrum technical ambassador, geek web3 contributor]]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.