Open tynes opened 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:
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
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 ofOptimismPortal
contracts into the set of interoperable chains. The current scope of interop does not unify this liquidity on L1. Users are able to send theether
between various L2 chains and must check that there is liquidity in theOptimismPortal
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 theOptimismPortal
. 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 theOptimismPortal
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 themint
fields in all deposits and that increments the balance. When a user callsL2ToL1MessagePasser.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 invariantaddress(OptimismPortal).balance >= L2 view of balance
must hold.ether
to theOptimismPortal
without minting it on L2 by calling thedonateETH
function or by usingSELFDESTRUCT
to moveether
without EVM execution.ether
will not modify the balanceThe semantics here also need to account for custom gas token chains, which could be solved by coupling an
eth_call
toOptimismPortal.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 itsether
balance to a single contract. Any new deposit would forward theether
here and any withdrawal would removeether
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.