Former Arbitrum Technical Ambassador Explains Arbitrum's Component Structure (Part II)

Author: Benben Luo, former Arbitrum technical ambassador, geek web3 contributor

In the previous article, “Former Arbitrum Technical Ambassadors Explain the Component Structure of Arbitrum (Part I)”, we introduced the role of sequencers, validators, SequencerInbox contracts, Rollup Blocks, and non-interactive fraud proofs in the Arbitrum core components, and in today’s article, we will focus on the components of the Arbitrum core components related to cross-chain interaction messaging and censorship-resistant transaction entrances.

Body: In a previous article, we mentioned that the Sequencer Inbox contract specifically receives the batch of transaction packets published by the sequencer on Layer 1. At the same time, we point out that Sequencer Inbox is also known as Fast Box, as opposed to Slow Box Delayed Inbox (Inbox for short). **Below, we will take a closer look at components related to cross-chain interaction messaging, such as Delayed Inbox.

Principles of Cross-Chain Interaction and Bridge

Cross-Chain interaction transactions can be divided into L1 to L2 (deposit) and L2 to L1 (withdrawal). Note that the deposits and withdrawals mentioned here are not necessarily related to asset cross-chain interaction, and can be messages that do not directly attach assets. So these two words only mean two directions of cross-chain interaction related behavior.

Cross-Chain Interaction transaction is more complicated than pure L2 transactions, Cross-Chain Interaction transactions have information swapped in two different systems, L1 and L2.

In addition, what we usually call cross-chain interaction behavior is cross-chain interaction on two unrelated networks with a Cross-Chain Interaction bridge in witness mode, and the security of this Cross-chain Interaction depends on the operator of the Cross-Chain Interaction Bridge, and the theft of Cross-Chain Interaction bridges based on the witness model has occurred frequently in history.

The Cross-Chain Interaction behavior between the Rollup and the ETHMainnet is fundamentally different from the above Cross-Chain Interaction, because the state of Layer 2 is determined by the data recorded on Layer 1, as long as you use the official Rollup Cross-Chain Interaction bridge, it is absolutely safe in terms of operation structure. **

This also highlights the essence of Rollup, it is just from the user’s point of view, like an independent chain, but in fact, the so-called ** “Layer2” is just a quick display window of Rollup open to users, and its real chain structure is still burned on Layer 1. Therefore, we can think of L2 as half a chain, or “a chain created on Layer 1”.

Retryable ticket Retryables

It should be noted that cross-chain interaction is asynchronous and non-atomic, it is impossible to know the result after completing a transaction confirmation like on a chain, and there is no guarantee that something will happen on the other side at a certain point in time. Therefore, Cross-Chain Interaction may fail due to some soft problems, but as long as the right means are used, such as Retryable Ticket, hard problems such as stuck funds will not occur.

**Retryable tickets are the basic tools used when depositing through the official Arbitrum bridge, **ETH and ERC20 deposits are 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 deposit ticket and submit it.

**2. Automatic redemption on L2. **In most cases, the sequencer can automatically redeem the bill for the user, without the need for subsequent manual operation.

**3. L2. **In some marginal cases, such as a sudden spike in gas prices on L2 and insufficient gas prepaid on the note, it will not be automatically redeemed. In this case, it needs to be done manually by the user.

Note that if the automatic redemption fails, you will need to manually redeem the note within 7 days, otherwise either the bill will be deleted (the funds will be permanently lost), or you will need to pay a fee to renew the lease for the preservation of the bill.

In addition, although there is a certain symmetrical similarity between the withdrawal process of the Arbitrum official bridge and the deposit behavior, there is no concept of Retryables, which can be understood from the Rollup protocol itself on the one hand, and some differences on the other hand:

There is no automatic redemption in the withdrawal process, because there is no timer or automation in the EVM, and automatic redemption can be realized on L2, which is achieved with the help of the sequencer, so users on L1 need to manually interact with the Outbox contract to retrieve assets with Claim. There is no problem of overdue bills for withdrawals, as long as the challenge period has passed, it can be claimed at any time.

ERC-20 asset cross-chain interaction gateway

• Cross-chain interaction of ERC-20 assets is complex. There are a few questions we can ponder:
• Token deployed on L1, how is it deployed on L2?
• Does its L2 counterpart need to be manually deployed in advance, or can the system automatically deploy asset contracts for Tokens that cross over but have not yet deployed the contract?
• What is the contract Address of ERC-20 assets on L1 corresponding to L2? Should it be consistent with L1?
• How to Cross-Chain Interaction to L1 for Tokens natively issued on L2?
• Tokens with special functions, such as adjustable number of Rebase Tokens, self-growing interest-bearing Tokens, how to Cross-Chain Interaction?

We’re not going to answer all of these questions, because it’s too complicated to expand. These questions are only used to illustrate the complexity of ERC20 cross-chain interaction.

At present, many scaling solutions use allowlist + manual inventory solutions to avoid various complex problems and boundary situations.

Arbitrum uses the Gateway system to solve most of the pain points of ERC20 cross-chain interaction, with the following features:

• Gateway components appear in pairs at L1 and L2. The Gateway Router is responsible for maintaining Address mappings between Token L1<->Token L2, as well as between some tokens <-> some gateways.
• Gateways can be divided into StandardERC20 gateways, Generic-custom gateways, Custom gateways, etc., to solve different types and functional ERC20 bridging problems.

Let’s take the relatively simple WETH Cross-Chain Interaction as an example to illustrate the necessity of a custom gateway.

WETH is an ERC20 equivalent of ETH. As Ether is the main coin, many complex functions in dApps are not possible, so an ERC20 equivalent is required. 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, it is also possible to burn WETH and take out ETH. **Obviously, the amount of WETH in circulation and the amount of ETH Lock-up Position will always be 1:1. **

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

• It is not possible to unwrap WETH into ETH on L2 because there is no lock-up position corresponding to ETH on L2.
• The Wrap function can be used, but these newly generated WETH cannot be decapsulated as ETH on L1 if they cross back to 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 interaction, whether it is a deposit or a withdrawal, it needs to be unwrapped into ETH first, and then crossed to the opposite side, and then wrapped into WETH. This is where the WETH Gateway comes in.

Other Tokens with more complex logic do the same, requiring more complex and well-designed gateways to work properly in a cross-chain interaction environment. Arbitrum’s custom gateway inherits the cross-chain interaction logic of ordinary gateways and allows developers to customize the cross-chain interaction behavior related to the token logic, which can meet most needs.

Delayed Inbox

The counterpart to the SequencerInbox is the Delayed Inbox (Delayed Inbox). Because the fast box is dedicated to receiving the batch of L2 transactions published 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 top-up behavior from L1 to L2. **The user makes a deposit through the Slow Box, and the sequencer listens to it and then reflects it on L2, and finally the deposit record will be included in the L2 transaction sequence by the sequencer and submitted to the Sequencer Inbox.

In this example, it is not appropriate for the user to submit the deposit transaction directly to the Sequencer Inbox, because the transaction submitted to the Sequencer Inbox will interfere with the normal transaction ordering of Layer 2, and then affect the work of the sequencer.

The second function of the slow box is to resist censorship. **Transactions submitted directly by users to the Slowbox contract will be collected by the sequencer within 10 minutes. But if the sequencer maliciously ignores your request, the slowbox also has a forced inclusion function:

If the transaction is submitted to the Delayed Inbox, after 24 hours, the transaction in the Slowbox has not been included in the transaction sequence by the sequencer, The user can manually trigger the force inclusion function on Layer 1, and the transaction requests ignored by the sequencer are forcibly grouped into the Fastbox Sequencer Inbox, and then they will be monitored by all Arbitrum One Nodes and will be forcibly included in the Layer 2 transaction sequence.

As we mentioned earlier, the data in the fastbox is the historical data entity of L2. Therefore, in the case of malicious censorship, ** can finally include transaction instructions in the L2 ledger through the slow box, which covers scenarios such as forced withdrawals to escape from Layer 2. **

It can be seen from this that for any direction and level of transactions, the sequencer will not be able to permanently review you in the end.

Several core functions of Slowbox Inbox:

• depositETH(), the simplest function for depositing ETH.
• createRetryableTicket(), which can be used to deposit ETH and ERC20 as well as messages. Compared with depositETH(), it has higher flexibility, such as the ability to specify the receiving address of L2 after deposit.
• forceInclusion(), which is the forced aggregation function, can be called by anyone. This function verifies whether a transaction submitted to the Slowbox contract has not been processed after 24 hours. If the conditions are met, the message will be forcibly aggregated.

However, it should be noted that the force Inclusion function is actually located in the Slowbox contract, just to make it easier to understand, we will put it here in the Slowbox and explain it together.

Outbox

Outbox is only related to withdrawals, which can be understood as a record and management system for withdrawal behavior:**

• We know that withdrawals from the Arbitrum official bridge need to wait for the end of the challenge period of about 7 days before the withdrawal can be implemented after the Rollup Block is finalized. At the end of the challenge period, the user submits the corresponding Merkle Proof to the Outbox contract on Layer 1, which communicates with other functional contracts (such as unlocking assets locked in other contracts) and finally completes the withdrawal.
• The OutBox contract will record which L2 to L1 cross-chain interaction messages have been processed to prevent someone from repeatedly submitting executed withdrawal requests. It uses mapping(uint256 => bytes32) public spen to record the spent Index of the withdrawal request and the correspondence between the information, if mapping[spentIndex] != bytes32(0), the request has already been withdrawn. The principle is similar to the transaction counter nonce that prevents replay attacks.

Below we will take ETH as an example to fully explain the deposit and withdrawal process. The difference between ERC20 and ERC20 is that it just goes through the Gateway, so I won’t repeat it.

ETH deposit

1. The user calls the depositETH() function of the Slowbox.

2. The 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 listens to the deposit message in the slow box and reflects the deposit operation to the L2 database, so that users can see the assets they have deposited in the L2 network.

4. The sequencer will include the deposit record into the batch and submit it to the Express contract on L1.

ETH withdrawals

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

2. The sequencer sends the withdrawal request to Quickbox.

**3.The Validator Node creates a new Rollup Block based on the transaction sequence in the Fastbox, which will contain the above withdrawal transactions. **

4. After the Rollup Block has passed 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 aforementioned ArbSys contract.

5. After the Outbox contract confirms that it is correct, the corresponding amount of ETH in the unlocked bridge is sent to the user.

Fast payouts

Withdrawals using the Optimistic Rollup official bridge will result in a waiting period for the challenge period. We can circumvent this problem with private third-party Cross-Chain Interaction bridges:

• Atomic lock swapping. This method only allows the two parties to swap assets within their respective chains, and it is atomic, as long as one party provides a Preimage, both parties will definitely get the assets they deserve. But the problem is that liquidity is relatively scarce, and it is necessary to find counterparties peer-to-peer.
• Witness Cross-Chain Interaction Bridge. **The general type of cross-chain interaction bridge is a witness bridge. Users submit their own withdrawal requests to the operator of the third-party bridge or liquidity pool. After the witness discovers that the cross-chain interaction 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 on the data it has committed to Layer 1. **The problem is that the safety factor in this mode is not as high as the official Rollup bridge. **

Forced payouts

force Inclusion() is used to counter sequencer censorship and can be used for any L2 local, L1-to-L2, and L2-to-L1 transactions. The malicious censorship of the sequencer has seriously affected the trading experience, and in most cases we will choose to withdraw and leave L2, so the following is an example of forced withdrawal to introduce the use of forceInclusion.

Recall that in the ETH withdrawal step, only steps 1 and 2 involve sequencer review, so only these two steps need to be changed:

• Call inbox.sendL2Message() in the slowbox contract on L1, and the input parameter is the parameter that needs to be entered when calling withdrawEth() on L2. The message is shared with the bridge contract on L1.
• After waiting for the 24-hour forced aggregation waiting period, call the force Inclusion() in the fast box to force the collection, and the fast box contract will check whether there is a corresponding message in the bridge.

The end user can withdraw in the Outbox, and the rest of the steps are the same as normal withdrawals.

In addition, arbitrum-tutorials also have detailed tutorials on how to use the Arb SDK to guide users on how to use forceInclusion() to conduct L2 local transactions and L2 to L1 transactions.