OPRR Flash Depth Activities

Search Extension

How important are the forced withdrawal and escape cabin functions to Layer2?

极客 Web3

2023-11-08 19:00

Read this article in 17 Minutes

AI summary

View the summary

Original Title: "How important are forced withdrawals and escape hatch functions for Layer2?"

Source: Faust, Geek Web3

In the real world, almost every tall building has an indispensable element: a safety exit. When unexpected events such as fires and earthquakes occur, safety exits are the life-saving straw that guarantees people's safety. In the Ethereum Layer2 custody platform system that carries billions of dollars in assets, the "force withdrawal" function that allows users to safely withdraw assets to Layer1 has become an essential facility.

In a recent article titled "Different types of layer 2s," Vitalik also emphasized that the ability for users to smoothly withdraw assets from Layer 2 to Layer 1 is a very important security indicator.

However, the issue of "smooth withdrawals" did not seem to receive much attention in the past, and even many Layer2 projects did not launch "forced withdrawals" or "escape hatch" functions. In the era when the L2 ecosystem was not yet mature, ignoring "permissionless withdrawals" seemed to be no problem. But now that Layer2 has already carried more than 12 billion US dollars in assets, it has become a "too big to fail" building. If such a skyscraper does not have a safe exit, the consequences are simply unimaginable.

With the aim of raising awareness of Layer2 security risks among readers, "Geek Web3" will use Loopring Protocol V3 and Arbitrum as examples in the following text to explain why "permissionless withdrawal functions" such as forced withdraw and escape hatch are indispensable components of Layer2.

(According to L2BEAT dYdX browser display, the forced trading/withdrawal function of dYdX has been used a total of 152 times, with as many as 7 large withdrawals exceeding $1 million.)

Resistance to censorship is a big issue: What if Sequencer intentionally denies your request?

In the past, most of the popular science articles about Layer2 often had a problem, which is that most of the time they emphasized "security" and superficial "usability", but ignored "censorship resistance". Even when discussing decentralized sorter solutions, many people pay attention to whether MEV is decentralized, rather than improving censorship resistance.

In other words, most people tend to focus on whether the state transition of Layer2 is effective, whether the sorter can steal coins, and whether the fraud proof/validity proof system has been put into use, but they overlook a risk that should not be ignored: what if the Sequencer keeps rejecting your transaction requests, or even malfunctions or shuts down for a long time? What should you do in this situation?

To know that during the Solana downtime, some people were unable to replenish their assets in time due to liquidation, resulting in millions of dollars of assets at risk. Once such scenarios of rejecting user requests occur, the resulting economic losses cannot be underestimated.

Even if only a few people may encounter such situations, if it falls into the hands of whales with a large amount of funds, the entire market may suffer (assuming someone's assets worth hundreds of millions of dollars in Defi lending protocols on Ethereum may be liquidated within a week, but he is sanctioned by OFAC because he used Tornado. Most of this person's funds are on OP, and the OP sorter cooperates with OFAC to reject its request).

Let's project this issue onto independent public chains such as Avalanche or Polygon for analysis. If more than 2/3 of the validator consensus nodes on Avalanche decide to conduct transaction review on you, they can refuse to include your initiated Txn in the block or not recognize the block containing your Txn. At this point, your money is basically stuck in this chain and cannot be withdrawn:

Unless you can win over some Validators to ensure that there are less than 2/3 Validators participating in the review attack, or you can mobilize people to fork Avalanche through social consensus. Obviously, at this time, you still have a way to quickly withdraw funds from Avalanche. We must also consider that it takes time for more than 2/3 of Validators to unite and initiate transaction reviews on a particular address, which will give the scrutinized users ample time to "escape".

However, on Layer2, the situation may be very different. The Sequencer on Layer2 is generally run by the official itself. If the Sequencer wants to launch a review attack on you, it can "freeze your money on Layer2", which is to completely reject the transaction request you initiated to transfer assets from L2 to L1. Obviously, according to the operation mechanism of L2, if you cannot bypass the sequencer to execute the withdrawal operation, it is entirely possible for the Sequencer to freeze the assets on L2 and cannot transfer them away.

So how to solve this problem? In fact, it is about how to achieve "withdrawal without permission" function, allowing users to safely withdraw assets to Layer1 without being reviewed by Sequencer or Layer2 project parties. Some project parties have proposed a decentralized Sequencer solution, but this is only a temporary solution. If these limited number of sorters unite to review you, they can still "freeze" your assets. Moreover, the anti-witch problem of POS nodes is also a tricky issue (see Multichain incident for reference).

The most effective way is to directly set up an "exit" on the L1 chain, allowing users to withdraw funds from L2 through the dedicated exit on L1 when they do not receive a response from the Sequencer for a long time.

Loopring Protocol V3's Forced Withdrawal and Bankruptcy Liquidation Mode

Here we take Loopring Protocol V3 as an example. It divides the forced withdrawal initiated by users into two different situations. The first situation is:

Users can directly initiate a forced withdrawal on Layer1 through the forcedWithdraw function in the ExchangeV3 contract, declaring which L2 account they have in the Loopring protocol and which token they want to withdraw. Afterwards, the ExchangeV3 contract will throw an on-chain event indicating that someone has initiated a forced withdrawal request. Since all nodes in the Loopring protocol (including the Sequencer) run Geth clients, they will learn from the Ethereum blockchain that someone has initiated a forced withdrawal and triggered the corresponding on-chain event.

It should be noted that forced withdrawals will not be processed immediately, but will be placed in the pendingForcedWithdrawals queue and remain in a pending state. When the Sequencer detects that someone has initiated a forced withdrawal on Layer1, the Process function in the ExchangeV3 contract is usually triggered within 15 days to transfer the tokens to the withdrawal initiator on the Ethereum chain (from the deposit address of the L2 project party on the Ethereum chain, transferring money to the withdrawer).

If the Sequencer does not respond to the user's forced withdrawal request within 15 days, the user can call the notifyForcedRequestTooOld function to trigger the WithdrawalModeActivated event in the ExchangeV3 contract, notifying the full nodes of the Loopring protocol that the bankruptcy liquidation mode has been activated.

If the bankruptcy liquidation mode is activated, Loopring Protocol V3 will stop receiving new L2 blocks submitted by the Sequencer, which means that the entire Loopring Protocol will stop operating. This process will last for at least 30 days.

However, under bankruptcy liquidation mode, users can still withdraw their assets on Layer1, but they need to submit merkle proof to prove their asset status, which can be checked on the state tree of L2. (Prove that their asset balance on Layer2 is consistent with the amount declared when initiating the withdrawal)

The bankruptcy liquidation model of the Loopring protocol, also known as the Escape Hatch mechanism on L2BEAT. There is a prerequisite for triggering this model, which is that the sorter does not respond to the user's forced withdrawal request within the specified time, or the Sequencer has a long-term failure or shutdown. At this time, users can manually trigger the Rollup contract to enter the freeze mode/stop operation. Then, users can construct a merkle Proof to prove their asset situation on Layer2, and withdraw their own part of the assets from the deposit address of the L2 project on L1.

In the documentation of StarkEx, a dedicated diagram is also drawn for this process. If a L2 user's Forced Withdrawal request submitted on L1 does not receive a sequencer response at the end of the 7-day window, the user can call the freeze Request function to put L2 into a frozen state. At this point, the L2 sequencer will be unable to update the state of L2 on L1, and L2 will remain frozen for 1 year before it can be unfrozen. After that, the user can submit a merkle proof and withdraw.

However, to construct a Merkle Proof, it is necessary to first obtain the complete L2 state tree, which requires requesting data from an L2 full node, and also requires a piece of code to generate the Merkle Proof. Obviously, this requires a certain level of technical expertise. In order to facilitate users, L2BEAT previously stated that Layer2 should set up a batch of permissioned and open-source full nodes to help users obtain the state of all accounts on L2 (including balances, transaction counts, etc.). This move also highlights the importance of forced withdrawals and escape hatch mechanisms.

Arbitrum's "Force Inclusion Transactions" Feature

However, forced withdrawal/escape pods do not seem to be the only anti-censorship solution. For example, Arbitrum uses a "forced transaction inclusion" approach, where users can submit Txn/withdrawals that need to be processed by the Sequencer to the delayed Inbox contract on L1. If the Sequencer does not process the transaction within 24 hours, the user can call the force inclusion function on the Sequencer Inbox contract on L1, which will directly include the Txn in Arbitrum's transaction sequence (throwing an on-chain event to inform Arbitrum full nodes that the Txn recorded on several delayed Inboxes needs to be included in the L2 ledger).