Former Arbitrum technical ambassador explains Arbitrum’s component structure (Part 2)

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

Introduction: This article is the technical interpretation of Arbitrum One by Luo Benben, former technical ambassador of Arbitrum and former co-founder of smart contract automation audit company Goplus Security.

In the previous article"Former Arbitrum Technical Ambassador Interprets Arbitrum's Component Structure (Part 1)", we introduced the sequencer, Validator, and Sequencer in Arbitrum's core components  ;The role of Inbox contract, Rollup Block, and non-interactive fraud proof. In today's article, we will focus on the components related to cross-chain messaging and censorship-resistant transaction entrances among Arbitrum core components.

Text: In the previous article, we mentioned that the Sequencer Inbox contract specifically receives the transaction data package Batch released 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 carry out information in two different systems, L1 and L2. interchange, so the process is more complicated.

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

The cross-chain behavior between Rollup and the ETH main network is essentially different from the above-mentioned cross-chain, because the status of Layer2 is Determined by the data recorded on Layer1, as long as you are using Rollup’s official cross-chain bridge, its operational structure is absolutely safe.

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 structure is still burned on Layer1. So, we can think of L2 as half a chain, or "a chain created on Layer1."

Retryables

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 the other side will be in a certain place. Something happens at a point in time. Therefore, cross-chain may fail due to some soft problems, but as long as the correct means are used, such as Retryable Ticket (Retryable Ticket), hard problems such as fund jams will not occur.

Retryable tickets are the basic tools used when recharging through the Arbitrum official bridge, ETH and ERC20 The recharge 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 payment on L2. In most cases, the sorter can automatically help users redeem their bills without subsequent manual operations.

3. Manual payment on L2. In some edge cases, such as a sudden surge in gas prices on L2 and insufficient gas prepaid on the bill, automatic payment cannot be made. At this time, manual operation by the user is required.

Note that if the automatic redemption fails, the note needs to be redeemed manually within 7 days, otherwise the note will be deleted (the funds will be permanently lost) , or you need to pay a fee to keep 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, it does not have the same process as Retryables. The concept can be understood from the Rollup protocol itself on the one hand, 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, automatic redemption can be achieved on L2. It is the sequencer that helps. Implemented, so users on L1 need to manually interact with the Outbox contract to claim the assets.

• There is no issue of ticket expiration when withdrawing cash. As long as the challenge period has passed, you can claim 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 it across Are tokens that come over but have not deployed contracts automatically deployed to asset contracts?

• What is the corresponding contract address of the ERC-20 asset on L1 on L2? ? Should it be consistent with L1?

• How to cross-chain tokens issued natively on L2 to L1?

• Tokens with special functions, such as rebase tokens with adjustable quantities , self-growing interest-bearing tokens, how to cross-chain?

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

Many expansion solutions currently 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:< /p>

• Gateway components appear in pairs at L1 and L2 .

• Gateway Router is responsible for maintaining Token L1<->Token L2 Address mapping between ,and mapping between some token<->some gateway.

• Gateway itself can be divided into StandardERC20 gateway, Generic-custom gateway, Custom gateway, etc. etc., to solve the bridging problems of different types and functions of ERC20.

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.

Similarly, 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 locking corresponding on L2 of ETH.

• Wrap function can be used, but if these newly generated WETH span back to L1 , and cannot be decapsulated into ETH on L1 because the WETH contracts on L1 and L2 are not "symmetric".

Obviously this violates Understand the design principles of WETH. 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.

Other tokens with more complex logic need 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

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 L2 transaction batches released 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. Users recharge 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 inappropriate for the user to submit the recharge transaction directly to the fast box, because it is submitted to the fast box Sequencer Inbox The transaction 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 the 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, Transaction requests ignored by the sequencer are forced to be collected in the Sequencer Inbox. They 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,through the slow box, transaction instructions can be finally included in the L2 ledger, which covers scenarios such as forced withdrawals and other scenarios of escaping Layer 2.

It can be seen that for transactions in any direction and level, the sequencer cannot be permanent in the end. Censor 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 depositing, etc.

• forceInclusion(), that is, the forced aggregation function, anyone can adjust Use. 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 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 the end of the challenge period of about 7 days. After the Rollup Block is finalized, withdrawals The behavior 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 records the correspondence between the spend Index of the withdrawal request and the information through

  mapping(uint256 => bytes32) public spent , 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

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 ETH is sent to the bridge contract. All ETH recharge funds are kept in the bridge contract, which is equivalent to a recharge address.

3. The sequencer monitors the recharge message in the slow box and reflects the recharge operation to L2 In the database, users can see the assets they have deposited in the L2 network.

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

ETH withdrawal

1. Users are in L2 Call the withdrawEth() function of the ArbSys contract to destroy 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. This will include the above withdrawal transactions.

4. After the Rollup Block has passed the challenge period and been confirmed, users can log in to L1 The Outbox.execute Transaction() function is called on, proving that the parameters are given by the ArbSys contract mentioned earlier.

5. 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

Use the Optimistic Rollup official bridge to withdraw money 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.

• 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 factor in this mode is not as high as the official Rollup bridge.

Force withdrawal

force Inclusion() force inclusion function is used to resist the review of the sequencer, any L2 local transactions, L1 to L2 transactions and L2 to L1 transactions can all 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.

Reviewing the ETH withdrawal steps, only steps 1 and 2 involve sequencer review, so they only need to be changed These two steps:

• Call inbox.sendL2Message() in the slow box contract on L1, The input parameters are the parameters that need to be entered when calling withdrawEth() on L2. This message will be shared to the bridge contract on L1.

• After waiting for the 24-hour waiting period for forced inclusion, 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 To withdraw funds in Outbox, 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 use forceInclusion() to perform L2 local transactions and L2 to L1 transaction.