How does Arbitrum handle cross-chain messaging and censorship-resistant transactions? What is its cross-chain bridge model?
Written by: Luo Benben, former Arbitrum technical ambassador and geek web3 contributor
In the previous article* “Former Arbitrum Technical Ambassador Interprets Arbitrum’s Component Structure (Part 1)”**, we introduced the sequencer, Validator, Sequencer Inbox contract, Rollup Block, and non-interactive fraud proof in the core components of Arbitrum In today’s article, we will focus on the components related to cross-chain messaging and censorship-resistant transaction entrances among Arbitrum’s core components. *
In the previous article, we mentioned that the Sequencer Inbox contract specifically receives the transaction data package Batch published by the sequencer on Layer1. At the same time, we point out that Sequencer Inbox is also called a fast box, as opposed to a slow box Delayed Inbox (referred to as Inbox). Below, we will provide a detailed explanation of components related to cross-chain messaging such as Delayed Inbox.
![]()
Principles of cross-chain and bridging
Cross-chain transactions can be divided into L1 to L2 (recharge) and L2 to L1 (withdrawal). Note that the recharge 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. Operators, theft of cross-chain bridges based on the witness model has occurred frequently in history.
The cross-chain behavior between Rollup and the ETH main network is essentially different from the above-mentioned cross-chain, because the state of Layer2 is determined by the data recorded on Layer1,** as long as you are using the official Rollup The cross-chain bridge is absolutely safe in its operational structure. **
This also highlights the essence of Rollup. It only looks like an independent chain from the user’s perspective, but in fact the so-called “**Layer2” is just a quick display window opened by Rollup to users. Its real chain type The structure is still burned on Layer1. **So, we can think of L2 as half a chain, or “a chain created on Layer1”.
Retryable ticketsRetryables
It should be noted that cross-chains are asynchronous and non-atomic. It is impossible to know the result after confirming a transaction like on one chain, nor can it guarantee that something will happen on the other side at a certain point in time. . Therefore, cross-chain may fail due to some soft issues, but as long as the correct means are used, such as Retryable Ticket, hard issues such as fund jams will not occur.
**Retryable tickets are the basic tools used when depositing through the Arbitrum official bridge. ** Both ETH and ERC20 deposits will be used. Its life cycle is divided into three steps:
**1. Submit the ticket on L1. **Use the createRetryableTicket() method in the Delayed Inbox contract to create a recharge ticket and submit it.
**2. Automatic redemption on L2. **In most cases, the sorter can automatically help users pay bills without subsequent manual operations.
**3. Manual redemption on L2. **In some edge cases, such as a sudden surge in gas prices on L2 and insufficient gas prepaid on the ticket, automatic payment cannot be made. At this time, manual operation by the user is required.
Note that if automatic redemption fails, the note needs to be redeemed manually within 7 days, otherwise either the note will be deleted (funds will be permanently lost), or a fee will need to be paid to save the note to renew the lease.
In addition, although the withdrawal process of the Arbitrum official bridge has a certain symmetrical similarity with the recharge behavior, there is no concept of Retryables. On the one hand, it can be understood from the Rollup protocol itself, and on the other hand, we can understand it from some differences:
- **There is no automatic redemption during the withdrawal process, **because EVM does not have a timer or automation, and automatic redemption can be achieved on L2, which is implemented with the help of the sequencer, so users on L1 must manually interact with the Outbox contract to claim Retrieve assets.
- **There is no issue of ticket expiration when withdrawing cash. **As long as the challenge period has passed, you can receive it at any time.
ERC-20 Asset Cross-Chain Gateway
Cross-chain ERC-20 assets are complex. We can think about several questions:
- A token deployed on L1, how to deploy it 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 to cross-chain tokens natively issued on L2 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 expansion solutions use whitelist + manual list solutions to avoid various complex problems and boundary conditions.
**Arbitrum uses the Gateway system to solve most of the ERC20 cross-chain pain points. **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, ** and the mapping between some token<->some gateway.
- The Gateway itself can be divided into StandardERC20 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 destroyed and ETH taken out. Obviously, the number of circulating WETH and locked ETH is always 1:1. **
![]()
If we now cross-link WETH directly 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 the WETH contracts on L1 and L2 are not “symmetrical”**.
Obviously this violates the design principles of WETH. **Then when WETH is cross-chain, whether it is recharging or withdrawing, it needs to be unwraped 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 the ordinary Gateway and allows developers to customize cross-chain behavior related to token logic, which can meet most needs.
Delayed Inbox
Corresponding to the fast box, also known as SequencerInbox, is the slow box Inbox (full name Delayed Inbox)**. Why should there be a distinction between speed and slowness? Because the fast box is dedicated to receiving the L2 transaction batch issued by the sequencer, all transactions that have not been preprocessed by the sequencer in the L2 network should not appear in the fast box contract.
**The first function of the slow box is to handle the recharge behavior from L1 to L2. **The user recharges through the slow box, and the sequencer monitors it and then reflects it on L2. Finally, the recharge record will be included in the L2 transaction sequence by the sequencer and submitted to the fast box contract Sequencer Inbox.
In this example, it is not appropriate for users to submit recharge transactions directly to the express box, because transactions submitted to the express box Sequencer Inbox will interfere with the normal transaction sorting of Layer 2, and then affect the work of the sequencer.
The second function of the slow box is to resist censorship. Users directly submit transactions to the slow box contract, and the sorter will generally aggregate them into the fast box within 10 minutes. But if the sorter maliciously ignores your request, the slow box also has a force inclusion function:
If a transaction is submitted to the Delayed Inbox, and after 24 hours, the transaction in the slow box has not been included in the transaction sequence by the sequencer, ** the user can manually trigger the force inclusion function on Layer1, ** to ignore it by the sequencer The transaction requests are forcibly collected into the Sequencer Inbox, and will then be monitored by all Arbitrum One nodes, and will be forcibly included in the Layer 2 transaction sequence. **
![]()
As we just mentioned, the data in the fast box is the historical data entity of L2. Therefore, in the case of malicious censorship, the transaction instructions can be finally included in the L2 ledger through the slow box, which covers scenarios such as forced withdrawals and escaping Layer 2. **
It can be seen from this that for transactions in any direction and level, the sequencer will ultimately be unable to permanently review you.
Several core functions of slow box Inbox:
- depositETH(), the simplest function to deposit ETH.
- createRetryableTicket(), which can be used for ETH, ERC20 and message recharge. Compared with depositETH(), it has higher flexibility, for example, you can specify the L2 payment address after deposit, etc.
- forceInclusion(), which is the forced collection function, can be called by anyone. This function will verify whether a transaction submitted to the slow box contract has not been processed after 24 hours. If the conditions are met, the messages will be forcibly collected.
However, it should be noted that the force Inclusion function is actually located in the fast box contract. Just for the convenience of understanding, we will explain it together in the slow box.
Outbox Outbox
Outbox is only related to withdrawals and can be understood as a recording and management system for withdrawals:
- We know that withdrawals from the Arbitrum official bridge need to wait for about 7 days for the end of the challenge period and the Rollup Block to be finalized before the withdrawal can be implemented. 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 passes
- mapping(uint256 => bytes32) public spent, records the correspondence between the spend Index of the withdrawal request and the information, if mapping [spentIndex] != bytes32(0) then the request has been withdrawn. The principle is similar to the transaction counter Nonce to prevent replay attacks.
Below we will take ETH as an example to fully explain the deposit and withdrawal process. The only difference between ERC20 and Gateway is that it will not be described in detail.
ETH Deposit
-
The user calls the depositETH() function of the slow box.
-
This function will continue to call bridge.enqueueDelayedMessage(), record the message in the bridge contract, and send ETH to the bridge contract. **All ETH recharge funds are kept in the bridge contract, which is equivalent to a recharge address. **
-
The sequencer monitors the recharge messages in the slow box and reflects the recharge operation to the L2 database. Users can see the assets they have recharged on the L2 network.
-
The sequencer includes the recharge record into the transaction batch and submits it to the fast box contract on L1.
![]()
ETH Withdrawal
-
The user calls the withdrawEth() function of the ArbSys contract on L2 to destroy the corresponding amount of ETH on L2.
-
The sequencer sends the withdrawal request to the express box.
3 **Validator node creates a new Rollup Block based on the transaction sequence in the fast box, which will contain the above withdrawal transaction. **
-
After the Rollup Block passes the challenge period and is confirmed, the user can call the Outbox.ute Transaction() function on L1 to prove that the parameters are given by the ArbSys contract mentioned above.
-
After the Outbox contract is confirmed to be correct, the corresponding amount of ETH in the unlocked bridge will be sent to the user.
![]()
Quick withdrawal
**If you use 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 circumvent 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 point-to-point.
- **Witness cross-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 fast box contract of L1, he can transfer money directly 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 safety factor in this mode is not as high as the official Rollup bridge. **
Forced withdrawal
force Inclusion() The force inclusion function is used to resist the review of the sequencer. Any L2 local transaction, L1 to L2 transaction and L2 to L1 transaction can be implemented using this function. The malicious review 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.
**Recall that in the ETH withdrawal steps, only steps 1 and 2 involve sequencer review, so only these two steps need to be changed: **
![]()
- Call 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 waiting for the 24-hour forced inclusion waiting period, call force Inclusion() in the fast box 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 remaining steps are the same as normal withdrawals.
In addition, arbitrum-tutorials also has detailed tutorials on using the Arb SDK to guide users on how to perform L2 local transactions and L2 to L1 transactions through forceInclusion().
