In the previous article, “Arbitrum’s Component Structure Interpreted by the Former Arbitrum Technical Ambassador (Part 1),” we introduced the roles of the key components in Arbitrum, including the sequencer, validator, sequencer inbox contract, rollup block, and the role of non-interactive fraud proofs. In today’s article, we will focus on explaining the components related to cross-chain message passing and the entry for anti-censorship transactions in the core components of Arbitrum.

Main Text: In previous articles, we mentioned that the Sequencer Inbox contract is specifically designed to receive transaction data batches 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,” and in contrast, there is the “slow box” or Delayed Inbox (referred to as Inbox). Below, we will provide a detailed interpretation of components related to cross-chain message passing, including the Delayed Inbox.

The principle of cross-chain and bridging

Cross-chain transactions can be divided into transactions from L1 to L2 (deposit) and transactions from L2 to L1 (withdrawal). It’s important to note that the terms “deposit” and “withdrawal” here may not necessarily involve the cross-chain transfer of assets; they can refer to message passing without directly transferring assets. Therefore, these terms merely represent the two directions of cross-chain-related actions.

In comparison to pure L2 transactions, cross-chain transactions involve the exchange of information between two different systems, L1 and L2, making the process more complex.

Additionally, when we talk about cross-chain actions, it usually refers to crossing between two entirely unrelated networks using a cross-chain bridge in a federated model. The security of such cross-chain operations depends on the operator of the cross-chain bridge, and historically, incidents of theft have been frequent in witness-based cross-chain bridges.

On the other hand, cross-chain actions between Rollup and the ETH mainnet are fundamentally different from the aforementioned cross-chain processes. This is because the state of Layer2 is determined by data recorded on Layer1. As long as you use the official Rollup cross-chain bridge, it is structurally secure in its operations.

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

Retryables

Please note that cross-chain transactions are asynchronous and non-atomic. Unlike transactions on a single chain, completing a transaction and confirming the result after one transaction on one chain is not possible in cross-chain transactions. There is also no guarantee that something specific will happen on the other side at a certain point in time. Therefore, cross-chain transactions may fail due to some soft issues, but with the use of proper techniques, such as retryable tickets, hard issues like funds being stuck won’t occur.

Retryable tickets are fundamental tools used in the Arbitrum official bridge during deposits, applicable to both ETH and ERC20 deposits. The lifecycle consists of three steps:

1. Submitting the ticket on L1: Use the ‘createRetryableTicket()’ method in the Delayed Inbox contract to create a deposit ticket and submit it.
2. Automatic redemption on L2: In most cases, the sequencer can automatically redeem the ticket for the user without requiring additional manual actions.
3. Manual redemption on L2: In certain extreme cases, such as a sudden surge in gas prices on L2, if the prepaid gas on the ticket is insufficient, automatic redemption cannot occur. In this scenario, manual intervention by the user is necessary. It’s important to note that if automatic redemption fails, the user needs to manually redeem the ticket within 7 days; otherwise, the ticket will either be deleted (resulting in permanent loss of funds) or the user needs to pay a certain fee to renew the ticket’s storage.

Furthermore, regarding the withdrawal process on the Arbitrum official bridge, although there is a certain symmetrical similarity in the process compared to deposits, there is no concept of retryable tickets. This can be understood from the perspective of the Rollup protocol itself, and some differences can be highlighted:

• There is no automatic redemption during the withdrawal process because the EVM does not have timers or automation. On L2, automatic redemption can be implemented, and it is facilitated by the sequencer. Therefore, users on L1 need to manually interact with the Outbox contract to claim back their assets.
• There is no issue of ticket expiration during withdrawals. As long as the challenge period has passed, users can claim their assets at any time.

Cross-Chain Gateway for ERC-20 Assets

Cross-chaining of ERC-20 assets is complex. We can think about several questions:

• how to deploy a token deployed on L1 on L2?
• Does its L2 corresponding contract need to be deployed manually in advance, or can the system automatically deploy asset contracts for tokens that have crossed over but have not yet deployed a contract?
• For ERC-20 assets on L1, what is the corresponding contract address on L2? Should it be consistent with L1?
• How can tokens issued natively on L2 be cross-chained to L1?
• How can tokens with special functions, such as rebase tokens with adjustable quantities and self-growing interest-bearing tokens, be cross-chained?

We are not going to answer all of these questions because they are too complex to unfold. These questions are only used to illustrate the complexity of ERC20 cross-chain.

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

Arbitrum uses the Gateway system to solve most of the sticking problems of ERC20 cross-chain. It has the following features:

• Gateway components appear in pairs at L1 and L2.
• Gateway Router is responsible for maintaining the address mapping between Token L1<->Token L2. Besides, the mapping between some token<->some gateway.
• The Gateway itself can be divided into Standard ERC20 gateway, Generic-custom gateway, Custom gateway, etc., to solve different types and functions of ERC20 bridging problems.

Let’s take the relatively simple WETH cross-chain as an example to illustrate the necessity of customizing the gateway.

WETH is an ERC20 equivalent of ETH. As the main currency, Ether cannot implement complex functions in many dApps, so an ERC20 equivalent is needed. Transfer some ETH into the WETH contract, they will be locked in the contract, and the same amount of WETH will be generated.

In the same way, WETH can also be burned and ETH can be withdrawn. Obviously, the ratio of circulating WETH and locked ETH is always 1:1.

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 decapsulated into ETH on L1 because WETH contracts on L1 and L2 are not “symmetric”.

Obviously this violates the design principles of WETH. Hence, when WETH is cross-chained, whether it is deposit or withdrawal, it needs to be unwrapped into ETH first, then crossed to the other side, and then wrapped into WETH. This is the role of WETH Gateway.

The same goes for other tokens with more complex logic, which require a more complex and carefully designed Gateway to work properly in a cross-chain environment. Arbitrum’s custom Gateway inherits the cross-chain communication logic of ordinary Gateway and allows developers to customize cross-chain behavior related to token logic, which can meet most needs.

Delayed Inbox

The counterpart to the fast inbox, known as Sequencer Inbox, is the slow inbox (fully named Delayed Inbox). Why differentiate between fast and slow? This is because the fast inbox is dedicated to receiving batches of L2 transactions published by the sequencer, and any transactions not preprocessed by the sequencer within the L2 network should not appear in the fast inbox contract.

The first function of the slow inbox is to handle the process of depositing from L1 to L2. Users initiate deposits through the slow inbox, and once the sequencer observes this, it reflects on L2. Eventually, this deposit record is included in the L2 transaction sequence by the sequencer and submitted to the fast inbox contract (Sequencer Inbox).

In this scenario, it’s inappropriate for users to directly submit deposit transactions to the fast inbox (Sequencer Inbox) because transactions submitted to the fast inbox may disrupt the normal transaction ordering in Layer2, thereby affecting the sequencer’s operation.

The second function of the slow inbox is censorship-resistant. Transactions directly submitted to the slow inbox contract are generally aggregated into the fast inbox within 10 minutes by the sequencer. However, if the sequencer maliciously ignores your request, the slow inbox has a forced inclusion feature:

If a transaction is submitted to the Delayed Inbox and, after 24 hours, it remains unincorporated into the transaction sequence by the sequencer, users can manually trigger the force inclusion function on Layer1. This action compels transactions ignored by the sequencer to be forcibly aggregated into the fast inbox (Sequencer Inbox). Subsequently, they will be detected by all Arbitrum One nodes and forcefully included in the Layer2 transaction sequence.

We just mentioned that the data in the fast inbox represents the historical data entity of L2. Therefore, in cases of malicious censorship, using the slow inbox allows transaction instructions to eventually be included in the L2 ledger, covering scenarios such as forced withdrawals to escape Layer2.

From this, it can be seen that for any direction and level of transactions, the sequencer ultimately cannot permanently censor you.

Several core functions of the slow inbox (Inbox):

• depositETH(): The simplest function for depositing ETH.
• createRetryableTicket(): Used for depositing ETH, ERC20, and messages. It offers greater flexibility compared to depositETH(), allowing specifications such as the receiving address in L2 after the deposit.
• forceInclusion(): This function, the forced inclusion feature, can be called by anyone. The function verifies whether a transaction submitted to the slow inbox contract has not been processed after 24 hours. If the conditions are met, it forcefully includes the message.

However, it’s important to note that the force inclusion function is actually located in the fast inbox contract. For ease of understanding, we explained it together with the slow inbox.

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 will record which cross-chain messages from L2 to L1 have been processed to prevent someone from repeatedly submitting executed withdrawal requests. It records the correspondence between the spend Index and the information of the withdrawal request by using ‘mapping(uint256 => bytes32) public spent’. If mapping[spentIndex] != bytes32(0), the request has been withdrawn. The principle is similar to the transaction counter Nonce for preventing replay attacks.

Below we will take ETH as an example to fully explain the deposit and withdrawal process. The only difference between ERC20 and ETH is that former uses Gateway. We will not explain it in detail.

ETH Deposit

1. The user calls the depositETH() function of the slow box.

2. This function will continue to call ‘bridge.enqueueDelayedMessage()’, record the message in the bridge contract, and send ETH to the bridge contract. All ETH deposit funds are kept in the bridge contract, which is equivalent to a deposit address.

3. The sequencer monitors the deposit messages in the slow box and reflects the deposit operation to the L2 database. Users can see the assets they have deposited on the L2 network.

4. The sequencer includes the deposit record into the transaction batch and submits it to the fast box contract on L1.

ETH withdrawal

1. The user calls the withdrawEth() function of the ArbSys contract on L2, and the corresponding number of ET is burned on L2.

2. The sequencer sends the withdrawal request to the express 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 goes through the challenge period which is also 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.

Quick cash withdrawal

When using the Optimistic Rollup official bridge to withdraw cash, there will be a problem of waiting for the challenge period. We can use a private third-party cross-chain bridge to remove this problem:

• Atomic lock exchange. This method only exchanges assets between the two parties within their respective chains, and is atomic. As long as one party provides Preimage, both parties will definitely get the assets they deserve. But the problem is that liquidity is relatively scarce and you need to find counterparties with a peer-to-peer method.F
• Witnesses cross the chain bridge. General types of cross-chain bridges are witness bridges. Users submit their own withdrawal requests, and the withdrawal destination points to the operator of the third-party bridge or the liquidity pool. After the witness discovers that the cross-chain transaction has been submitted to the L1 fast box contract, he can directly transfer money to the user on the L1 side. This approach essentially uses another consensus system to monitor Layer 2 and operate based on the data it has submitted to Layer 1.The problem is that the security level in this mode is not as high as that of the official Rollup bridge. \

Forced withdrawal

The force Inclusion() function is used to resist the censorship of the sequencer. Any L2 local transaction, L1 to L2 transaction and L2 to L1 transaction can be implemented using this function. The malicious censorship of the sequencer seriously affects the transaction experience. In most cases, we will choose to withdraw money and leave L2. Therefore, the following uses forced withdrawal as an example to introduce the usage of forceInclusion.

Looking back at the ETH withdrawal steps, only steps 1 and 2 involve sequencer censorship, so only these two steps need to be changed:

• When calling ‘inbox.sendL2Message()’ in the slow box contract on L1, the input parameters are the parameters that need to be input when calling withdrawEth() on L2. This message will be shared to the bridge contract on L1.
• After a 24-hour forced inclusion waiting period, force Inclusion() in the fast box is called to perform forced inclusion. The fast box contract will check whether there is a corresponding message in the bridge.

End users can withdraw money in Outbox, and the rest of the steps are the same as normal withdrawals.

In addition, there are also detailed tutorials on using the Arb SDK in arbitrum-tutorials to guide users on how to perform L2 local transactions and L2 to L1 transactions through forceInclusion() function.

Disclaimer：

1. This article is reprinted from [极客 Web3]. All copyrights belong to the original author [极客 Web3]. 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.