ethereum-optimism / specs

OP Stack Specifications
https://specs.optimism.io
Creative Commons Zero v1.0 Universal
100 stars 89 forks source link

On Solving the Interop Withdrawal Liquidity Problem #362

Open tynes opened 2 months ago

tynes commented 2 months ago

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

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.

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.

mds1 commented 2 months ago

One more option for the design space is letting portals take ETH from each other on-demand. The way this would work is:

Considerations:

tynes commented 2 months ago

The solution that @mds1 proposes is interesting because it optimizes for each chain's OptimismPortal to not need to transfer its ether to another contract. While this makes the upgrade more simple, the implementation is more complicated. I would lean towards a less complex on chain solution and have the one time ether migration during the upgrade