interop: add ETH Shared Lockbox design doc #84
Conversation
Co-authored-by: ng <[email protected]>
|
From a product perspective - the ETH shared lockbox design solves a lot of user pain, by maintaining the invariant that "any amount of ETH can always be withdrawn from L2 to L1 safely", which many protocols have built upon. I think the only concern at this point is the time and resources required to actually ship this securely. Is there some rough scoping of the amount of time this adds to the engineering timeline for interoperable ETH? Who would we need review/support from to feel confident in the security of this upgrade? It's certainly a major change and would want to make sure we get a diverse set of reviews/eyes on this + put together a very thorough Failure Mode Analysis |
|
Also a stream of work will be making sure that external tooling that relies on the OptimismPortal to calculate ETH stored in a chain is updated as well (e.g. update L2Beat, Defillama, etc.) |
|
|
||
| This would require a one-time L1 liquidity migration process for each chain. Newly deployed chains via `OPSM` should use the `SharedLockbox` from the beginning. | ||
|
|
||
| ### Joining the Cluster |
There was a problem hiding this comment.
I'm not 100% sure here, but I dont think it makes sense to define a separate "cluster" for the lockbox, when we already have a separate SystemConfig that lists out dependency sets. Would love to get all teams together during design review to align on a single onchain set of chains that are both: in bi-directional dependency set, AND in the shared lockbox.
There was a problem hiding this comment.
It makes sense. It definitely requires SharedLockbox to serve the entire Superchain cluster, no matter how the dependency graph ends up, so the contract only needs to know if the chain where the withdrawal is requested is part of it.
This is a very interesting consideration. Actually, when making ETH interoperable, a shift in the interpretation of liquidity distribution is needed. To show the actual TVL, |
|
|
||
| The core changes proposed are the following: | ||
|
|
||
| - Introduce `SharedLockbox` which accepts deposits and withdrawals of ETH and Gas Tokens as well. |
There was a problem hiding this comment.
Must this also custody gas tokens? Seems like it would create some accounting complexity. I think we could skip this feature for now since we aren't planning on adding any custom gas token chains during the first release of interop, we could add this feature in the future when there is a custom gas token chain that becomes popular
|
|
||
| - Introduce `SharedLockbox` which accepts deposits and withdrawals of ETH and Gas Tokens as well. | ||
| - Modify `OptimismPortal` to forward ETH deposits into `SharedLockbox` and allow extraction of ETH when a withdrawal is finalized. | ||
| - Maintain an on-chain list (through `SystemConfigInterop` or another contract if already defined) that registers the chains that are part of the cluster. This allows `SharedLockbox` to validate a withdrawal from a chain that is part of the cluster. |
There was a problem hiding this comment.
This control mechanism is really important. I would love to enumerate some possible designs. Right now there is a "dependency set manager" role in the SystemConfig. It was originally thought that this role would be governance/security council, but now maybe the default config should define it as this contract and then this contract is owned by gov/security council and it holds the aggregate dependency set and calls each individual chain's SystemConfig to manage the dependency set. Or we should rethink how the dependencies are managed from first principles, another thing that I realized recently is that the dependencies are not maintained within the SystemConfig on L1, they only exist at the moment on L2 in the L1Block contract.
|
|
||
| From the point of view of a chain deployed via `OPSM`, we suggest adopting `SharedLockbox` even when there is no interoperable set established for it. Since the security is guarded by the security council and governance, it should not represent a risk. | ||
|
|
||
| For existing chains, the `OptimismPortal` should incorporate a new gated function that hardcodes the sending of ETH to the `SharedLockbox` contract and that can only be called by a trusted entity, e.g., the Security Council. This function should also emit an event which the off-chain components can use to track how much ETH was initially moved from a chain to the `SharedLockbox`, which may be required in case the chain wishes to opt out of the cluster in the future. |
There was a problem hiding this comment.
I would recommend not adding a function and instead do an intermediate upgrade to a contract that simply sends all balance in its initialize and then upgrade to the implementation of the new OptimismPortal. This removes risk of having that function there forever
| ``` | ||
|
|
||
| ### Opt-out the cluster | ||
|
|
There was a problem hiding this comment.
Being able to opt out is nice but to be honest I think that this adds too much complexity. We could just say that it's one way, once you join there is no leaving. I could be convinced otherwise because freedom is important, but there isn't a good solution for L2 native assets or upgraded deposited tokens
|
|
||
| This method would require minimal changes to `L1Block` and adjustments to how `TransactionDeposited` is processed to validate new ETH counts. Additionally, it necessitates porting the initial balance as part of an upgrade transaction. | ||
|
|
||
| The problem with L2 reverts is that it breaks the ETH withdrawal guarantee invariant and still exposes the system to solvency issues. Based on previous feedback, this would affect existing applications and pre-deployed contracts such as the current `FeeVault` withdrawal contract logic. |
There was a problem hiding this comment.
This logic would be implemented in the L2ToL1MessagePasser in practice, it's the lowest level abstraction. I am confident in being able to get the "start balance" into L2, but I do agree that it would break applications that assume they can withdraw, but at least their ether wouldn't be stuck
| - Modify `OptimismPortal` to forward ETH deposits into `SharedLockbox` and allow extraction of ETH when a withdrawal is finalized. | ||
| - Maintain an on-chain list (through `SystemConfigInterop` or another contract if already defined) that registers the chains that are part of the cluster. This allows `SharedLockbox` to validate a withdrawal from a chain that is part of the cluster. | ||
|
|
||
| This would require a one-time L1 liquidity migration process for each chain. Newly deployed chains via `OPSM` should use the `SharedLockbox` from the beginning. |
There was a problem hiding this comment.
To be compliant with the name of the OPSM -> OPCM now?
| This would require a one-time L1 liquidity migration process for each chain. Newly deployed chains via `OPSM` should use the `SharedLockbox` from the beginning. | |
| This would require a one-time L1 liquidity migration process for each chain. Newly deployed chains via `OPCM` should use the `SharedLockbox` from the beginning. |
|
|
||
| ### Joining the Cluster | ||
|
|
||
| From the point of view of a chain deployed via `OPSM`, we suggest adopting `SharedLockbox` even when there is no interoperable set established for it. Since the security is guarded by the security council and governance, it should not represent a risk. |
There was a problem hiding this comment.
Same here to avoid confusion?
| From the point of view of a chain deployed via `OPSM`, we suggest adopting `SharedLockbox` even when there is no interoperable set established for it. Since the security is guarded by the security council and governance, it should not represent a risk. | |
| From the point of view of a chain deployed via `OPCM`, we suggest adopting `SharedLockbox` even when there is no interoperable set established for it. Since the security is guarded by the security council and governance, it should not represent a risk. |
|
|
||
| # Solution | ||
|
|
||
| We propose an L1 shared liquidity design, achieved by introducing a new `SharedLockbox` in L1 that serves as a singleton ETH contract for the entire interoperable set of chains. New ETH deposits will be forwarded to the lockbox, and the same applies to ETH withdrawals. This could also serve as the singleton contract for gas tokens in the case of CGT chains. |
There was a problem hiding this comment.
in L1 that serves as a singleton ETH contract
So every interop chains are about to forward ETH into theSharedLockbox so we should be capable to track the amount of total ETH on the Superchain by checking the balance of this contract?
Or there is still chains that will keep ETH in the previous OptimismPortal?
Co-authored-by: ng [email protected]
Description
The following design doc cover a previous discussed issue on ETH withdrawals introduced by interop. The Shared lockbox is presented as the most convenient solution to solve this problem. However, it is known that the design also is the interest for various aspects of the Superchain design, such as chain management, core interop, and others, which need to be carefully discussed.
Additional context
This doesn't address the case for L1 bridged tokens.