Author: Faust, Geek Web3
In the real world, almost every tall building has an indispensable ingredient: a safety exit. When emergencies such as fires and earthquakes fall, safety exits are a lifesaver to ensure the safety of people’s lives. In the Ethereum Layer 2 custody platform system, which carries tens of billions of dollars in assets, the “forced withdrawal” function, which allows users to safely withdraw assets to Layer 1, has become an indispensable and necessary facility.
In his recent article “Different types of layer 2s”, Vitalik also emphasized that the ability of users to smoothly withdraw assets from Layer 2 to Layer 1 is a very important security indicator.
However, the issue of “smooth withdrawal” does not seem to have received much attention from most people in the past, and even many Layer 2 projects have not launched the “forced withdrawal” or “escape pod” function. In the era when the L2 ecosystem is not in full swing, ignoring “permissionless withdrawals” does not seem to be a problem. But now that Layer 2 has more than $12 billion in assets, it has become a “too big to fail” building. If such a skyscraper does not have a safety exit, the consequences are simply unimaginable.
With the purpose of making readers pay attention to the security risks of Layer 2, “Geek Web3” will take Loopring Protocol V3 and Arbitrum as examples below to explain why “permissionless withdrawal functions” such as forced draw and escape hatch are an indispensable part of Layer 2.
(According to the L2BEAT dYdX browser, the dYdX forced transaction/withdrawal function has been used 152 times so far, and there have been 7 large withdrawals of more than $1 million.)
Censorship Resistance is the Big Problem: What to Do If Sequencer Deliberately Rejects Your Request****
In the past, popular science articles about Layer 2 often had a problem, that is, most of the time they focused on “security” and “usability” on the surface, but ignored “censorship resistance”. Even when talking about decentralized sequencer solutions, many people pay attention to whether MEV is decentralized, not censorship resistance.
In other words, most people tend to focus on whether the Layer 2 state transitions are valid, whether the sequencer can steal coins, and whether the fraud/validity proof-of-validity system is in use, but they ignore a risk that should not be overlooked: what if Sequencer keeps rejecting your transaction requests, or simply fails for a long time, or even goes down? **
You know, during the Solana outage, there were people who were unable to cover their positions in time because their assets were facing liquidation, putting millions of dollars of assets at risk. **Once such a rejection of the user’s request occurs, the economic loss caused is not negligible.
Even if only a few people could be in this situation, if it fell on some whale with a lot of money, the whole market could suffer (let’s say someone has hundreds of millions of dollars in assets on a Defi lending protocol on Ethereum that could be liquidated in a week, but he is on OFAC’s sanctions list for using Tornado). Most of this person’s funds are on the OP, and the OP sequencer works with OFAC to reject its request)
We might as well project this problem onto public chains such as avalanche or polygon, which are independent of Ethereum. If more than 2/3 of the validator consensus nodes on Avalanche decide to censor your transactions, they can refuse to include your Txn in a block, or not recognize the block that contains your Txn. At this time, your money is basically buried in this chain and can’t get out:**
Unless you can co-opt some validators so that less than 2/3 of the validators are involved in the censorship attack, or you can call on some people to fork Avalanche through social consensus. Obviously, at this point, you still have a way to quickly withdraw funds from Avalanche, and we have to consider that more than 2/3 of the Validators join forces to initiate a transaction review of a certain address, which itself takes a while to achieve, which will leave enough time for the censored users to “escape”.
But on Layer 2, the situation can be very different. Layer 2 Sequencer is generally run by the official itself, and if Sequencer wants to launch a censorship attack on you, it can “freeze your money in Layer 2”, that is, completely reject your transaction request to cross assets from L2 to L1. Obviously, according to the operation mechanism of L2, if you can’t bypass the sequencer to perform a withdrawal operation, it is entirely possible that Sequencer will freeze the assets in L2 and cannot be transferred.
So how to solve this kind of problem? In fact, to put it bluntly, how to implement the “permissionless” withdrawal function, so that users can withdraw their assets to Layer 1 without any harm when they are reviewed by Sequencer or Layer 2 project parties? There are some projects that have proposed decentralized Sequencer, but this is not a palliative solution, and if a very limited number of sequencers join forces to review you, you can still “freeze” your assets, and anti-witch of POS nodes is also a tricky problem (see Multichain events).
The most effective way to do this is to set up an “exit” directly on the L1 chain, allowing users to withdraw funds from L2 through a dedicated exit on L1 if they don’t get a response from Sequencer for a long time. **
Loopring Protocol V3 Forced Withdrawal and Bankruptcy Liquidation Model
Here we take the V3 version of the Loopring protocol as an example, which lists two different scenarios for user-initiated forced withdrawals, the first case is:
Users can initiate a forced withdrawal directly on Layer 1 through the forcedWithdraw function in the ExchangeV3 contract, and declare which L2 account they have in the Loopring protocol and what kind of token they want to withdraw. After that, the ExchangeV3 contract throws an on-chain event to indicate that someone has initiated a forced withdrawal request. Since all nodes of the Loopring protocol (including Sequencer) are running Geth clients, it is known from the Ethereum block that someone initiated a forced withdrawal and triggered the corresponding on-chain event.
It is important to note that forced withdrawals are not processed immediately, but are placed in the pendingForcedWithdrawals queue and are pending. **Sequencer noticed that after someone initiates a forced withdrawal at Layer 1, the Process function in the ExchangeV3 contract is triggered within 15 days to transfer the token to the withdrawal initiator on the Ethereum chain (from the L2 project party’s deposit address on the Ethereum chain to transfer money to the withdrawaler).
If Sequencer does not respond to the user’s forced withdrawal request within 15 days, the user can call the notifyForcedRequestTooOld function to have the ExchangeV3 contract throw an event called WithdrawalModeActivated to notify the full node of the Loopring protocol that the bankruptcy liquidation mode is activated. **
**If the liquidation mode is activated, Loopring V3 will stop receiving new L2 blocks submitted by Sequencer, which means that the entire Loopring protocol will stop working. This process lasts at least 30 days.
However, in the bankruptcy liquidation mode, users can still withdraw their assets on Layer 1, but they need to submit merkle proof to prove their asset status/status, which can be checked on the L2 state tree. (Prove that your asset balance in Layer 2 is consistent with the amount you declared when you initiated the withdrawal)
This bankruptcy liquidation model of the Loopring Protocol is also known as the Escape Hatch mechanism on L2BEAT. This mode is triggered on a prerequisite for the sequencer not responding to the user’s forced withdrawal request within the specified time, or if the sequencer has a long-term failure or downtime. At this time, the user can manually trigger the Rollup contract into freeze mode/stop running. Then, users can construct merkle proofs to prove their assets on Layer 2, and withdraw their own assets from the L2 project party’s deposit address in L1. **
In StarkEx’s documentation, a dedicated schematic diagram of this process is also drawn. If the L2 user does not receive a sequencer response at the end of the 7-day window when the L2 user submits a forced withdrawal request on L1, the L2 user can call the freeze request function to cause the L2 to enter the freeze period. In this case, the L2 sequencer will not be able to update the state of L2 on L1, and it will take 1 year after the L2 state is frozen to be unfrozen. After that, users can submit a Merkle Proof and withdraw money.
However, in order to construct Merkle Proof, you need to know the complete L2 state tree first, that is, you need to find an L2 full node to ask for data, and at the same time, you need a piece of code to generate merkle Proof, which obviously requires a certain technical threshold. For the convenience of the majority of users, L2BEAT has previously stated that Layer 2 should set up a number of full nodes with open permissions and open source code to help users know the status of all accounts on L2 (including balance, number of transactions, etc.). This move also illustrates the importance of mandatory withdrawals and escape pod mechanisms.
Arbitrum’s “Forced Include Transactions” feature
But forced withdrawals/escape pods don’t seem to be the only censorship-resistant solution. For example, Arbitrum uses the method of “forcing the inclusion of transactions”, the user can first submit the Txn/withdraw that needs to be processed by Sequencer in the delayed Inbox contract on L1, and if the Sequencer has not processed it for more than 24 hours, the user can call the force Inclusion function of the Sequencer Inbox contract on L1. Let Txn be included directly into Arbitrum’s transaction sequence** (throw an on-chain event to inform Arbitrum full nodes that Txn with a few delayed inbox records need to be included in the L2 ledger).
In contrast, Arbitrum’s approach is simpler, but it’s still a bit lacking: it only throws an on-chain event telling the Arbitrum node that there are a few transactions that the sequencer ignores that need to be included in the L2 longest chain, rather than allowing users to withdraw money directly on L1 as Loopring Protocol and StarkEx’s bankruptcy mode/escape pod do. If Arbitrum’s challenger nodes band together to launch a censorship attack, it seems that it would still be possible to freeze users’ money at L2. **
So Arbitrum’s force Inclusion isn’t permissionless enough, and while it would be nice to say that the sequencer ignored a user’s forceInclusion request as long as there was an honest node willing to post a fraud proof, this still introduces a certain degree of trust assumption, albeit to a lesser extent.
More precisely, “transactions that need to be compulsorily included” are to be recognized by at least one ARB challenger node, which currently has 9 nodes that have the right to decide which L2-L1 cross-chain messages to allow, and now only they can issue fraud proofs. **As long as these 9 nodes collude together, theoretically the user’s “forced transaction” can still be invalidated. **
Therefore, the current mandatory inclusion of transactions/withdrawals in Arbitrum is not like the bankruptcy liquidation model of Loopring and StarkEx that does not require L2 node permission. However, L2BEAT still gave Arbitrum a high rating for this solution. Because in the future, Arbitrum will launch a Permissionless fraud proof release mechanism called BOLD, and it will be difficult or impossible for challenger nodes to collude at that time (it is actually difficult to collude now).
According to L2BEAT, the current TVL is over $50 million, and there is no response to any of the Sequencer Failures or Proposer Failures: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. These L2s can cause user assets to be frozen in L2 in extreme cases. **
So obviously, the forced withdrawal or bankruptcy liquidation model has its necessity, although at the moment it only relies on the user-sequencer as a counterparty game to function, ** is not really “ready to withdraw” ** (Arbitrum has a 24-hour delay and can fail, Loopring has a maximum delay of 15 days, StarkEx has a maximum delay of 7 days), but it is clear that “something is better than nothing”. Moreover, the problem of delays in forced withdrawals is believed to be properly solved in the future with more sophisticated mechanism design** (at present, it is mainly due to the fact that some MEV scientists may use forceInclusion to initiate front-running transactions, so it is necessary to introduce delays.) For more details, please refer to the official documents of the major L2 project parties).
With the inclusion of decentralized Sequencer in more and more L2 roadmaps, and the Ethereum Foundation led by Vitalik continues to educate people about Layer 2 security, censorship-resistant transaction features such as forced withdrawals are bound to be paid more and more attention, which will make the Ethereum Layer2 system closer to a censorship-resistant, trustless financial infrastructure system. If Layer 2 implements trustless access to funds, it is believed that more market makers and liquidity providers will enter the L2 infrastructure, and the mass adoption of the entire web3 will be pushed one step further.
