How Crucial are Forced Withdrawals and Escape Hatch Functions for Layer 2?

In the real world, almost every skyscraper has an indispensable element: an emergency exit. When unforeseen events like fires or earthquakes occur, these exits are lifesavers for people’s safety. Similarly, in the Ethereum Layer 2 ecosystem, which holds billions of dollars in assets, the “forced withdrawal” feature that allows users to securely pull assets back to Layer 1 has become an essential facility.

Vitalik also emphasized in his recent article “Different Types of Layer 2s” that the ability for users to smoothly withdraw assets from Layer 2 back to Layer 1 is a very important safety indicator.

However, the issue of “smooth withdrawals” seems to have been overlooked by most in the past, and many Layer 2 project teams haven’t implemented “forced withdrawal” or “escape hatch” functions. In the era when the Layer 2 ecosystem was not yet mature, ignoring “permissionless withdrawals” seemed to be a non-issue. But now, with Layer 2 handling over 12 billion dollars in assets, it has become a “too big to fail” skyscraper. The absence of a safety exit in such a towering building is unimaginable.

With the intention of raising awareness among readers about the safety risks of Layer 2, “Geek Web3” will use Loopring Protocol V3 and Arbitrum as examples in the following text to explain why “permissionless withdrawal functions” like forced withdraw and escape hatch are indispensable components of Layer 2.

(According to the L2BEAT dYdX browser, up to now, the dYdX forced trading/withdrawal function has been used a total of 152 times, with large withdrawals exceeding one million dollars amounting to 7 cases) Censorship resistance is a big issue: What if the Sequencer deliberately refuses your request?

Past popular science articles on Layer 2 often had one issue: they mostly emphasized “security” and superficial “usability” but overlooked “censorship resistance”. Even when discussing decentralized sequencer solutions, what many people noticed was whether MEV is decentralized, rather than improvements in censorship resistance.

In other words, most people tend to focus on whether the state transitions in Layer 2 are effective, whether the sequencers can steal coins, and whether fraud proofs/validity proof systems are employed. However, they ignore a risk that should not be overlooked: What if the Sequencer continuously refuses your transaction requests, or is simply malfunctioning for an extended period, or even shuts down?

It’s worth noting that during the Solana downtime, there were instances where people couldn’t add collateral in time due to asset liquidation risks, leading to millions of dollars in assets at risk. Such scenarios of denying user requests can lead to significant economic losses.

Even if only a few individuals might encounter such situations, if it happens to some ‘whales’ holding large amounts of funds, the entire market could suffer. For example, suppose someone with hundreds of millions of dollars in assets in a DeFi lending protocol on Ethereum faces liquidation within a week but is sanctioned by OFAC due to using Tornado. Most of their funds are on Optimism (OP), and the OP Sequencer, in compliance with OFAC, refuses their requests.

Let’s project this issue onto independent blockchains like Avalanche or Polygon, separate from Ethereum. If over two-thirds of the Validator consensus nodes on Avalanche decide to conduct transaction scrutiny against you, they can refuse to include your transactions in a block or deny recognition of a block containing your transactions. In this case, your funds are essentially buried in this chain and cannot be withdrawn:

Unless you can persuade some Validators so that less than two-thirds are involved in the scrutiny attack, or you can rally people to fork Avalanche through social consensus. Clearly, at this time, you still have ways to quickly withdraw your funds from Avalanche. However, we must consider that it takes time for over two-thirds of Validators to unite and initiate a transaction scrutiny against a specific address, providing the scrutinized user ample time to ‘escape.’

But the situation might be quite different on Layer 2. Sequencers on Layer 2 are generally run by the official team. If a Sequencer wants to launch a scrutiny attack against you, it can ‘freeze your money on Layer 2,’ effectively refusing your requests to transfer assets from L2 to L1. According to the operational mechanism of L2, if you can’t bypass the Sequencer to execute a withdrawal, it’s entirely possible for the Sequencer to freeze your assets on L2, preventing their transfer.

So, how can this issue be resolved? Simply put, how can we implement a ‘permissionless’ withdrawal function that allows users to safely pull their assets back to Layer 1 even when under scrutiny by a Sequencer or a Layer 2 project team? Some project teams have proposed the idea of decentralized Sequencers, but this is a superficial solution. If these limited numbers of Sequencers collude to scrutinize you, they can still ‘freeze’ your assets. Moreover, the issue of anti-Sybil attacks in Proof of Stake (PoS) nodes is also problematic (as seen in the Multichain incident).

The most effective solution is to set up a dedicated ‘exit’ on the Layer 1 blockchain, allowing users to withdraw their funds from Layer 2 through this L1 exit in cases where they do not receive a response from the Sequencer over an extended period.

In the context of Loopring Protocol’s version 3, it outlines two different scenarios for user-initiated forced withdrawals. The first scenario is as follows:

Users can directly initiate a forced withdrawal on Layer 1 using the forcedWithdraw function in the ExchangeV3 contract. They need to declare which is their Layer 2 account in the Loopring Protocol and which Token they wish to withdraw. Subsequently, the ExchangeV3 contract emits a blockchain event, signaling that someone has initiated a forced withdrawal request. Since all nodes in the Loopring Protocol, including the Sequencer, run the Geth client, they will be informed about the forced withdrawal and the corresponding blockchain event from the Ethereum block data.

It’s important to note that a forced withdrawal is not processed immediately, but is instead placed in the pendingForcedWithdrawals queue, awaiting processing. Upon noticing a forced withdrawal initiated on Layer 1, the Sequencer usually triggers the Process function in the ExchangeV3 contract within 15 days. This function executes the transfer of tokens on the Ethereum chain to the initiator of the withdrawal (from the Layer 2 project’s deposit address on the Ethereum chain to the withdrawer).

If the Sequencer fails to respond to a user’s forced withdrawal request within 15 days, the user can call the notifyForcedRequestTooOld function. This action prompts the ExchangeV3 contract to emit an event named WithdrawalModeActivated, notifying all nodes in 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 Sequencer, which means that the entire Loopring Protocol will stop operating at this time.This process will last at least 30 days.

However, in bankruptcy liquidation mode, users can still withdraw their assets on Layer1, but they need to submit a merkle proof to prove their asset status/status, which can be checked on the L2 status tree. (Prove that your asset balance in Layer 2 is consistent with the amount you declared when you initiated the withdrawal.）

The article describes the bankruptcy liquidation model of the Loopring Protocol, which is also known as the “Escape Hatch” mechanism on L2BEAT. This model is triggered under certain conditions, such as when the sequencer fails to respond to a user’s forced withdrawal request within a specified time, or if the Sequencer experiences a long-term malfunction or shutdown. In such cases, users can manually trigger a process that puts the Rollup contract into a frozen or halted state. Users can then construct a Merkle Proof to demonstrate their asset situation on Layer 2 and withdraw their portion of assets from the Layer 2 project’s deposit address on Layer 1.

In the StarkEx documentation, there is a specific diagram illustrating this process. If a Layer 2 user’s Forced Withdrawal request submitted on Layer 1 is not responded to by the sequencer within a 7-day window, the user can invoke the freeze Request function to initiate a freezing period for Layer 2. During this period, the Layer 2 sequencer cannot update the status of Layer 2 on Layer 1. The frozen state of Layer 2 lasts for one year before it can be unfrozen. Afterwards, users can submit a Merkle proof and withdraw their funds.

But to construct a Merkle Proof, one needs to first obtain the complete L2 state tree, which means acquiring data from an L2 full node. Additionally, a specific piece of code is required to generate the Merkle Proof, clearly presenting a certain level of technical barrier. To facilitate this for the majority of users, L2BEAT had previously stated that Layer 2 should set up a batch of open-access and open-source full nodes, to help users acquire the status of all accounts on L2 (including balance, number of transactions, etc.). This move also underscores the importance of forced withdrawal and escape hatch mechanisms.

Arbitrum’s ‘Forced Transaction Inclusion’ Feature

However, forced withdrawals/escape pods do not seem to be the only anti-censorship solution. For instance, Arbitrum employs a ‘forced transaction inclusion’ method, where users can first submit the transactions/withdrawals that need to be processed by the Sequencer to the delayed Inbox contract on Layer 1 (L1). If the Sequencer fails to process them within 24 hours, users can call the force Inclusion function on the L1 Sequencer Inbox contract, allowing the transaction to be directly included in Arbitrum’s transaction sequence (by throwing an on-chain event informing the Arbitrum nodes that several transactions recorded on the delayed Inbox need to be included in the L2 ledger).

The passage discusses the approaches of different blockchain protocols in handling transactions, particularly focusing on Arbitrum in comparison to Loopring and StarkEx. Here’s the translation:

“Compared to others, Arbitrum’s method is somewhat simpler, but it still has shortcomings. It merely emits an on-chain event to inform Arbitrum nodes that several transactions ignored by the sequencer need to be included in the L2 longest chain, unlike the Loopring protocol and StarkEx’s bankruptcy mode/escape pod, which allow users to directly withdraw their funds on L1. If the challenger nodes in Arbitrum collude to launch a censorship attack, it seems possible to freeze users’ funds on L2.

Therefore, Arbitrum’s force inclusion mechanism is not entirely permissionless. Although a single honest node can publish a fraud proof to point out a user’s ignored force inclusion request by the sequencer, this still introduces a degree of trust assumption, albeit a minor one.

More specifically, the ‘transactions needing forced inclusion’ must be acknowledged by at least one ARB challenger node. Currently, there are nine of these nodes, and they have the authority to decide which cross-chain messages between L2 and L1 to approve, and they are also the only ones who can issue fraud proofs. If these nine nodes conspire together, they could theoretically invalidate a user’s ‘forced transaction.’

Hence, the current force inclusion or withdrawal transactions in Arbitrum are not as permissionless as Loopring and StarkEx’s bankruptcy liquidation mode. However, L2BEAT still highly rates this approach from Arbitrum. In the future, Arbitrum will launch a permissionless fraud proof publication mechanism named BOLD, making it difficult, if not impossible, for challenger nodes to collude (which is already hard now).”

According to data from L2BEAT, currently, Layer 2 (L2) platforms with a Total Value Locked (TVL) exceeding 50 million USD, which do not offer measures to address either Sequencer Failure or Proposer Failure, include OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, and Metis. These L2 platforms could, in extreme cases, lead to users’ assets being frozen and unable to be withdrawn from the L2.

Therefore, it’s evident that the necessity for mechanisms like forced withdrawals or insolvency liquidation modes exists. Although currently, they primarily rely on the game theory between users and sorters (order-producers), and cannot be considered truly “withdrawable anytime” (Arbitrum has a 24-hour delay which could fail, Loopring has up to a 15-day delay, StarkEx has a maximum 7-day delay), having these mechanisms is evidently better than not having them at all. The issue of delay in forced withdrawals could potentially be resolved in the future with more sophisticated mechanism designs. The current designs take into consideration potential MEV (Maximal Extractable Value) exploitation through forceInclusion, necessitating the introduction of delays. For more details, official documentation from various L2 projects should be consulted.

With the increasing inclusion of decentralized Sequencers in many L2 roadmaps and continuous efforts by entities like the Ethereum Foundation, led by Vitalik Buterin, to educate people about Layer 2 security, features like anti-censorship transaction functions in forced withdrawals will likely gain more attention. This will bring the Ethereum Layer 2 ecosystem closer to a censorship-resistant, trust-minimized financial infrastructure. If Layer 2 achieves a trust-minimized way of moving funds in and out, it is expected that more market makers and liquidity providers will enter the L2 infrastructure, pushing forward a step towards the mass adoption of web3.

Disclaimer：

1. This article is reprinted from [Faust，极客Web3]. All copyrights belong to the original author [Faust，极客Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.