On Solving the Interop Withdrawal Liquidity Problem

[tynes]

Overview

As interop is currently specified, there is a problem with withdrawal liquidity. What does this mean in practice?

Users can deposit ether between an arbitrary number of OptimismPortal contracts into the set of interoperable chains. The current scope of interop does not unify this liquidity on L1. Users are able to send the ether between various L2 chains and must check that there is liquidity in the OptimismPortal that corresponds to their L2 before withdrawing to L1. A race condition exists in which the user initiates their withdrawal and then is frontran by another withdrawal that removes the liquidity from the OptimismPortal. The cannot get their funds back to L2 and must wait for more deposits until their withdrawal can be processed.

If we want to guarantee solvency of withdrawals, there are 2 known approaches:

• L2 reverts on no liquidity
• L1 unified liquidity

L2 Reverts

This solution involves tracking the balance of the OptimismPortal in L2 and incrementing and decrementing the value as there are deposits and withdrawals. A one time upgrade transaction is included in a hardfork that uses the balance of the OptimismPortal as an input to generate an upgrade transaction that sets the value in an L2 storage slot. The L1 attributes transaction then includes a sum of the mint fields in all deposits and that increments the balance. When a user calls L2ToL1MessagePasser.initiateWithdrawal, it decrements the balance and reverts on underflow. This prevents withdrawals on L2 by a revert if there is insufficient liquidity.

This balance accumulator on L2 is not an accurate counter for the amount of ether on the L2. It is just meant to observe the liquidity for withdrawals. The invariant address(OptimismPortal).balance >= L2 view of balance must hold.

• It is possible to transfer ether to the OptimismPortal without minting it on L2 by calling the donateETH function or by using SELFDESTRUCT to move ether without EVM execution.
• L2 to L2 cross chain messaging of ether will not modify the balance

The semantics here also need to account for custom gas token chains, which could be solved by coupling an eth_call to OptimismPortal.balance rather than reading its balance from the state directly, but that would require L1 EVM execution to be in the fault proof.

L1 Unified Liquidity

The most minimal version of a L1 unified bridge is one where there is a shared lockbox. This involves each OptimismPortal migrating its ether balance to a single contract. Any new deposit would forward the ether here and any withdrawal would remove ether from here. This creates a shared liquidity pool for the set of interoperable chains.

There are open questions around the specific design of the shared lockbox. It cannot be permissionless to join unless the contracts were deployed by OP Stack Manager or older systems have had history integrity checks, then we know for a fact that the L2 system doesn't have a backdoor in its contracts.

Known Issues

These solutions do not solve for ERC20 tokens.