interop: interoperable ether transfers design doc #146

tremarkley · 2024-10-29T19:02:13Z

Description

This PR introduces a design for simplifying ETH transfers between two interoperable L2 chains by reducing the process from four transactions to two. The new approach leverages the SuperchainWETH contract, which now includes two new functions: sendETH and relayETH.

sendETH: Deposits ETH in the ETHLiquidity contract and sends a message to the destination chain, encoding the relay details.
relayETH: Withdraws the specified amount of ETH from ETHLiquidity on the destination chain and transfers it to the recipient.

This update streamlines L2-to-L2 ETH transfers, bypassing the need for separate wrapping and unwrapping steps. Notably, custom gas token chains are excluded from this simplification to maintain compatibility and reduce risk.

Additional context

Pros: Simplifies developer and user experience by enabling direct ETH transfers.
Cons: Adds a secondary entry point for transfers, increasing complexity slightly for developers handling asset transfers.

Any feedback on optimizing sendETH and relayETH for further efficiency or insights into handling custom gas token chains in the future is welcome.

tremarkley · 2024-10-29T19:02:28Z

interop: interoperable ether transfers design doc #146 👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

hamdiallam · 2024-10-29T19:23:47Z

protocol/interoperable-ether-transfers.md

+
+The `SendETH` function combines the first two transactions as follows:
+
+1. Burns `ETH` within the `ETHLiquidity` contract equivalent to the `ETH` sent.


Since we're not burning WETH, how about we add these functions to the ETHLiquidity contract?

I think it makes intent a bit clearer and keeps WETH completely separate as just an ERC20? No need to overload the ERC20 contract

it definitely simplifies things and creates better separation of concerns to leave SuperchainWETH as-is and move this into ETHLiquidity, so I'm onboard with that

Since ETHLiquidity holds so much ether, we have to be really careful with what functionality is added to it. It should be callable in the most minimal amount of ways. I originally designed it so that there could be only a single useful caller. We need to be very careful with any modifications to it

@tynes are you onboard with the suggested solution or do you think it is too risky of a change?

definitely see the concern on additions to ETHLiquidity. But want to note that even if this is in SuperchainWETH, a vulnerability there would also mean a vulnerability in ETHLiquidity since the relay mechanism pulls ETH from this contract

hamdiallam · 2024-10-29T21:38:18Z

protocol/interoperable-ether-transfers.md

+
+## Custom Gas Token Chains
+
+To simplify the solution, custom gas token chains will not be supported and must follow the original four-transaction flow, which includes wrapping and unwrapping `SuperchainWETH`.


Maybe note that this is no problem in the superchain since standard config requires ETH as the gas token.

And then in our viem extensions we can check this about the destination client prior to calling sendETH

yeah, that does bring up an issue with this, there is not a good way to check at the smart contract level whether the destination is a custom gas token chain or if it is in the dependency set.

There is no guarantee that standard config will always require ether for gas paying and the system was designed to be friendly to that changing

+1 on no guarantee. Just noting the state of the world today but still requires addressing this since the protocol is agnostic to the superchain

protocol/interoperable-ether-transfers.md

nicholaspai · 2024-10-31T22:20:33Z

protocol/interoperable-ether-transfers.md

+
+# Open Questions
+- **Long-term improvements**: Could this functionality eventually extend to custom gas token chains?
+- **Rollbacks**: How would rollbacks be handled in this implementation?


I assume rollbacks wouldn't be an issue as long as relayETH can only be called following the origin chain's finality period has passed?

by rollbacks here I am talking about ETH that is sent to a remote chain, but for some reason the relayETH message on the remote chain expires or is not able to be executed and we would like to "rollback" the ETH that was sent so the user can get their funds back

Reorgs are contingent between chains so there is no finality period. The concept of rollback is only relevant if you send to a chain where the call reverts on the remote chain and you cannot replay it or it always reverts. I think people also wanted to solve the problem of sending to a non existent chain using rollbacks, but I don't think that is possible. Now that we require the call on the remote chain to succeed, I think that the rollback design is going to be more difficult. We should think about rollbacks in a different way to solve that problem

I recommend we use the following design for rollbacks: ethereum-optimism/specs#460

I think there is confusion around what problem we are solving for, there should be no way that the cross chain token send should revert, so we don't need a rollback solution persay, we need to "prevent send to wrong chain" solution

nicholaspai · 2024-10-31T22:25:57Z

protocol/interoperable-ether-transfers.md

+
+### Advantages
+
+The advantage of this solution is that `SuperchainTokenBridge`would handle both `ETH` transfers and `SuperchainERC20` transfers, simplifying developer integrations.


SuperchainTokenBridgewould handle both ETH transfers and SuperchainERC20 transfers

And it would handle sending messages. Sending messages/erc20's/eth from a single contract is something developer's are used to, though its not at all a deal breaker

tynes · 2024-11-18T16:45:21Z

protocol/interoperable-ether-transfers.md

+
+# Summary
+
+New functionality is introduced to the `ETHLiquidity` contract that enables it to facilitate cross-chain `ETH` transfers to a specified recipient.


I don't love adding new functionality to the ETHLiquidity contract as it has a ton of virtual ether and makes reasoning about it more difficult. Its previous design only allowed one possible msg.sender. I definitely prefer to put the logic in the bridge contract to keep the liquidity contract more simple

+1 let's do this.
But have this be on the SuperWETH as originally planned :)

tynes · 2024-11-18T16:51:57Z

Generally much more in favor of putting the logic in the SuperchainTokenBridge given that its the cross chain bridging contract. Generally seems intuitive to put it there and mirrors our current design where the StandardBridge has ERC20 + ETH functionality

See #146 (comment)

skeletor-spaceman · 2024-11-19T08:44:21Z

protocol/interoperable-ether-transfers.md

+Add an internal `_burn` function that will be called by `ETHLiquidity#SendETH` and update the external `burn` function to call `_burn`:
+
+```solidity
+/// @notice Allows an address to lock ETH liquidity into this contract.
+function burn() external payable {
+    if (msg.sender != Predeploys.SUPERCHAIN_WETH) revert Unauthorized();
+    _burn(msg.sender, msg.value);
+}
+
+/// @notice Allows an address to lock ETH liquidity into this contract.
+/// @param _sender Address that sent the ETH to be locked.
+/// @param _amount The amount of liquidity to burn.
+function _burn(address _sender, uint256 _amount) internal {
+    if (IL1Block(Predeploys.L1_BLOCK_ATTRIBUTES).isCustomGasToken()) revert NotCustomGasToken();
+    emit LiquidityBurned(_sender, _amount);
+}
+```
+
+Add an internal `_mint` function that will be called by `ETHLiquidity#RelayETH` and update the external `mint` function to call `_mint`:
+
+```solidity
+/// @notice Allows an address to unlock ETH liquidity from this contract.
+/// @param _amount The amount of liquidity to unlock.
+function mint(uint256 _amount) external {
+    if (msg.sender != Predeploys.SUPERCHAIN_WETH) revert Unauthorized();
+    _mint(msg.sender, _amount);
+}
+
+/// @notice Allows an address to unlock ETH liquidity from this contract.
+/// @param _recipient Address to send the unlocked ETH to.
+/// @param _amount    The amount of ETH liquidity to unlock.
+function _mint(address _recipient, uint256 _amount) internal {
+    if (IL1Block(Predeploys.L1_BLOCK_ATTRIBUTES).isCustomGasToken()) revert NotCustomGasToken();
+    new SafeSend{ value: _amount }(payable(_recipient));
+    emit LiquidityMinted(_recipient, _amount);
+}
+```


is this outdated?
not sure how this fits with the current design.

this is up to date. this design is under the Alternatives Considered section and is meant to illustrate a design that was considered for adding this functionality to the ETHLiquidity contract

tynes · 2024-11-19T09:22:07Z

We agreed out of band that this functionality should live in the SuperchainWETH contract rather than the bridge or liquidity contracts

tynes · 2024-11-19T09:38:00Z

One consideration that should be thought through is sending ether to a remote chain that is custom gas token, the flow should not unwrap the weth on the other side

tremarkley changed the title ~~interop: interoperable ether transfers~~ interop: interoperable ether transfers design doc Oct 29, 2024

tremarkley force-pushed the harry/interoperable-ether-dd branch from f4d3111 to e180fb3 Compare October 29, 2024 19:04

tremarkley requested review from tynes, jakim929, hamdiallam and skeletor-spaceman October 29, 2024 19:08

hamdiallam reviewed Oct 29, 2024

View reviewed changes

tremarkley force-pushed the harry/interoperable-ether-dd branch from e180fb3 to a2f7001 Compare October 29, 2024 21:16

tremarkley requested a review from mds1 October 29, 2024 21:16

tremarkley force-pushed the harry/interoperable-ether-dd branch 2 times, most recently from 49a6f25 to 086cdb8 Compare October 29, 2024 21:21

hamdiallam reviewed Oct 29, 2024

View reviewed changes

tremarkley force-pushed the harry/interoperable-ether-dd branch from 086cdb8 to ab8d26c Compare October 29, 2024 21:56

skeletor-spaceman reviewed Oct 29, 2024

View reviewed changes

protocol/interoperable-ether-transfers.md Outdated Show resolved Hide resolved

tremarkley force-pushed the harry/interoperable-ether-dd branch 3 times, most recently from 872ed6e to 26827f0 Compare October 29, 2024 22:51

interop: interoperable ether transfers

b2c87e9

tremarkley force-pushed the harry/interoperable-ether-dd branch from 26827f0 to b2c87e9 Compare October 29, 2024 23:11

nicholaspai reviewed Oct 31, 2024

View reviewed changes

tynes reviewed Nov 18, 2024

View reviewed changes

tremarkley added 2 commits November 18, 2024 14:39

Merge branch 'main' into harry/interoperable-ether-dd

81c3097

update proposed solution to superchainweth

657dc6d

tremarkley requested review from skeletor-spaceman and tynes November 18, 2024 22:53

tremarkley added 2 commits November 18, 2024 14:59

add event signatures

d9c3efc

add natspec for events

6f892ac

tremarkley added 4 commits November 18, 2024 15:22

nit

04e3f9e

update relayETH

fb46063

update sendETH return value

9948477

make sendETH external

f77848f

tremarkley mentioned this pull request Nov 19, 2024

feat(SuperchainWETH): enable sending and relaying ETH via SuperchainWETH contract ethereum-optimism/optimism#12710

Open

cleanup

c93ba0a

skeletor-spaceman reviewed Nov 19, 2024

View reviewed changes

tynes mentioned this pull request Nov 19, 2024

L2 Messaging and Rollbacks ethereum-optimism/specs#460

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

interop: interoperable ether transfers design doc #146

interop: interoperable ether transfers design doc #146

tremarkley commented Oct 29, 2024 •

edited

Loading

tremarkley commented Oct 29, 2024 •

edited

Loading

hamdiallam Oct 29, 2024 •

edited

Loading

tremarkley Oct 29, 2024 •

edited

Loading

tynes Oct 30, 2024

tremarkley Oct 30, 2024

hamdiallam Nov 1, 2024

hamdiallam Oct 29, 2024

tremarkley Oct 29, 2024

tynes Oct 30, 2024

hamdiallam Nov 1, 2024

nicholaspai Oct 31, 2024

tremarkley Nov 1, 2024

tynes Nov 18, 2024

tynes Nov 19, 2024

nicholaspai Oct 31, 2024

tynes Nov 18, 2024

skeletor-spaceman Nov 18, 2024 •

edited

Loading

tynes commented Nov 18, 2024 •

edited

Loading

skeletor-spaceman Nov 19, 2024

tremarkley Nov 19, 2024

tynes commented Nov 19, 2024

tynes commented Nov 19, 2024


		The `SendETH` function combines the first two transactions as follows:

		1. Burns `ETH` within the `ETHLiquidity` contract equivalent to the `ETH` sent.


		## Custom Gas Token Chains

		To simplify the solution, custom gas token chains will not be supported and must follow the original four-transaction flow, which includes wrapping and unwrapping `SuperchainWETH`.


		### Advantages

		The advantage of this solution is that `SuperchainTokenBridge`would handle both `ETH` transfers and `SuperchainERC20` transfers, simplifying developer integrations.


		# Summary

		New functionality is introduced to the `ETHLiquidity` contract that enables it to facilitate cross-chain `ETH` transfers to a specified recipient.

interop: interoperable ether transfers design doc #146

Are you sure you want to change the base?

interop: interoperable ether transfers design doc #146

Conversation

tremarkley commented Oct 29, 2024 • edited Loading

Description

Additional context

tremarkley commented Oct 29, 2024 • edited Loading

hamdiallam Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

tremarkley Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skeletor-spaceman Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

tynes commented Nov 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tynes commented Nov 19, 2024

tynes commented Nov 19, 2024

tremarkley commented Oct 29, 2024 •

edited

Loading

tremarkley commented Oct 29, 2024 •

edited

Loading

hamdiallam Oct 29, 2024 •

edited

Loading

tremarkley Oct 29, 2024 •

edited

Loading

skeletor-spaceman Nov 18, 2024 •

edited

Loading

tynes commented Nov 18, 2024 •

edited

Loading