Original title: "Former Arbitrum Technical Ambassador Explains Arbitrum's Component Structure (Part 2)"

Original author: Luo Benben, former Arbitrum Technical Ambassador, Geek Web3 Contributor

Introduction:

This article is a 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 《Arbitrum's Component Structure Interpretation (Part 1)》, we introduced the functions of 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 anti-censorship transaction entry in the core components of Arbitrum.

Text: In the previous article, we mentioned that the sequencer inbox contract specifically receives the transaction data packet batch issued by the sequencer on Layer1. At the same time, we point out that the Sequencer Inbox is also called the fast box, and the opposite is the slow box Delayed Inbox (abbreviated as Inbox). Below, we will carefully interpret the components related to cross-chain message transmission, 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 may not be related to cross-chain assets, but can be message transmission without direct assets. So these two words only represent the 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, the cross-chain behavior we usually refer to is the cross-chain operation between two unrelated networks using a witness-mode cross-chain bridge. The security of this cross-chain operation depends on the operator of the cross-chain bridge. Historically, the theft of the cross-chain bridge based on the witness mode has occurred frequently.

The cross-chain operation between Rollup and the ETH mainnet is fundamentally different from the above cross-chain operation, because the state of Layer2 is determined by the data recorded on Layer1.As long as you use the official cross-chain bridge of Rollup, it is absolutely safe in terms of operation structure.

This also highlights the essence of Rollup. It is just like an independent chain from the user's perspective, but in fact the so-called "Layer2" is just a quick display window that Rollup opens to users, and its real chain structure is still recorded on Layer1.Therefore, we can consider L2 as half a chain, or "a chain created on Layer1".

Retryable Tickets

Note that cross-chain is asynchronous and non-atomic. It is impossible to know the result after a transaction is confirmed 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 may fail due to some soft problems, but as long as the correct means are used, such as Retryable Tickets, hard problems such as funds being stuck will not occur.

Retryable Tickets are the basic tools used when recharging through the Arbitrum official bridge, and are used for both ETH and ERC20 recharges. 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 redeem the bill for the user, without the need for subsequent manual operations.

3. Manual redemption on L2. In some edge cases, such as a sudden surge in gas prices on L2, the prepaid gas on the bill is not enough, and automatic redemption cannot be performed. In this case, the user needs to operate manually.

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

In addition, although the withdrawal process of the Arbitrum official bridge has a certain symmetrical similarity with the recharge process, 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 has no timer or automation, while automatic redemption can be achieved on L2, which is achieved by the sorter, so users on L1 need to manually interact with the Outbox contract to retrieve assets with Claim.

· There is no problem of bill expiration for withdrawals, as long as the challenge period has passed, it can be collected at any time.

ERC-20 Asset Cross-Chain Gateway

The cross-chain of ERC-20 assets is complicated. We can think about a few questions:

· How to deploy a token deployed on L1 on L2?

· Does its L2 corresponding contract need to be manually deployed in advance, or can the system automatically deploy asset contracts for tokens that have crossed over but have not yet deployed contracts?

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

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

· How to cross-chain tokens with special functions, such as Rebase tokens with adjustable quantities and self-growth interest-bearing tokens?

We do not intend to answer all these questions because they are too complicated. These questions are only used to illustrate the complexity of ERC20 cross-chain.

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

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

·Gateway components appear in pairs in L1 and L2.

·Gateway Router is responsible for maintaining the address mapping between Token L1<->Token L2, as well as the mapping between some token<->some gateway.

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

We take the relatively simple WETH cross-chain as an example to illustrate the necessity of custom gateway.

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

Similarly, WETH can be destroyed and ETH can be withdrawn. Obviously, the number of circulating WETH and locked ETH is always 1:1.

If we now cross-chain 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 locked ETH on L2.

·The Wrap function can be used, but if these newly generated WETH cross back to L1, they cannot be unwrapped into ETH on L1, because the WETH contracts on L1 and L2 are not "symmetric".

Obviously, this violates the design principle of WETH. So when WETH crosses the chain, whether it is recharge or withdrawal, it needs to be unwrapped into ETH first, then cross to the other side, and then Wrapped into WETH. This is the role of WETH Gateway.

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

Delayed Inbox

The corresponding to the fast box, also known as SequencerInbox, is the Slow Box Inbox (full name Delayed Inbox). Why is there a distinction between fast and slow? Because the fast box is specifically used to receive the L2 transaction batch released by the sequencer, all transactions that have not been pre-processed 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 listens to it and reflects it on L2. Finally, the recharge record will be included in the transaction sequence of L2 by the sequencer and submitted to the fast box contract Sequencer Inbox.

In this example, it is inappropriate for users to submit recharge transactions directly to the fast box, because transactions submitted to the fast box Sequencer Inbox will interfere with the normal transaction sorting of Layer2, and then affect the work of the sequencer.

The second function of the slow box is anti-censorship. The transactions submitted directly by users to the slow box contract will generally be collected by the sequencer in the fast box within 10 minutes. But if the sequencer maliciously ignores your request, the slow box also has a force inclusion function:

If the transaction is submitted to the Delayed Inbox, after 24 hours, the transaction in the slow box is still not included in the transaction sequence by the sequencer, the user can manually trigger the force inclusion function on Layer1 to force the transaction request ignored by the sequencer to be included in the fast box Sequencer Inbox, which will then be monitored by all Arbitrum One nodes and will be forced to be included in the Layer2 transaction sequence.

We just mentioned that the data in the fast box is the historical data entity of L2. So in the case of malicious censorship, the slow box can finally include the transaction instructions in the L2 ledger, which covers the scenarios of forced withdrawal and escape from Layer2.

From this, it can be seen that for transactions in any direction and level, the sorter will not be able to permanently censor you in the end.  

Several core functions of the slow box Inbox:

·depositETH(), the simplest function for recharging ETH.

·createRetryableTicket(), which can be used for recharging ETH, ERC20 and messages. Compared with depositETH(), it has higher flexibility, such as specifying the L2 receiving address after recharging.

·forceInclusion(), that is, the forced collection function, can be called by anyone. This function will check whether a transaction submitted to the slowbox contract has not been processed after 24 hours. If the condition is met, the message will be forced to be collected.

However, it should be noted that the force inclusion function is actually located in the fastbox contract. Just for the sake of ease of understanding, we put it here in the slowbox to explain.

Outbox

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

· We know that the withdrawal of the Arbitrum official bridge needs to wait for the challenge period of about 7 days to end. After the Rollup Block is finalized, the withdrawal 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 other functional contracts (such as unlocking assets locked in other contracts) to finally complete the withdrawal.

· The OutBox contract will record which L2 to L1 cross-chain messages have been processed to prevent someone from repeatedly submitting withdrawal requests that have been executed. It records the correspondence between the spent Index and information of the withdrawal request through mapping(uint256 => bytes32) public spent. If mapping[spentIndex] != bytes32(0), the request has 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 only difference between ERC20 and ERC20 is that it uses the Gateway, so we will not go into details.

ETH Deposit

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

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 sorter listens to the deposit message in the slow box and reflects the deposit operation in the L2 database. Users can see their deposited assets on the L2 network.

4. The sorter includes the recharge record into the transaction batch batch and submits it to the quickbox contract on L1.

ETH withdrawal

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

2. The sorter sends the withdrawal request to the quickbox.

3. The Validator node creates a new Rollup Block based on the transaction sequence in the quickbox, which will include the above withdrawal transaction.

4. After the Rollup Block has passed the challenge period and has been confirmed, the user can call the Outbox.execute Transaction() function on L1, proving that the parameters are given by the ArbSys contract mentioned above.

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

Quick Withdrawal

Withdrawing using the optimistic Rollup official bridge will cause the 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 in their respective chains, and it is atomic. As long as one party provides the Preimage, both parties will definitely get the assets they deserve. But the problem is that liquidity is scarce, and it is necessary to find the counterparty 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 or liquidity pool of the third-party bridge. After the witness finds that the cross-chain transaction has been submitted to the L1 quick box contract, it can directly transfer funds to the user on the L1 side. This method essentially uses another consensus system to monitor Layer2 and operate based on the data submitted to Layer1. The problem is that the security factor in this mode is not as high as the Rollup official bridge.

Forced 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 use this function. The malicious review of the sequencer seriously affects the transaction experience. In most cases, we will choose to withdraw and leave L2. Therefore, the following uses forced withdrawal as an example to introduce the usage of forceInclusion.

Recalling 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 required when calling withdrawEth() on L2. The message will be shared with the bridge contract on L1.

·After waiting for 24 hours for the mandatory collection waiting period, call force Inclusion() in the quick box for mandatory collection. The quick box contract will check whether there is a corresponding message in the bridge.

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

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

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia