feat: passthrough L1->L3 adapter to send messages to L3 via an L2 forwarder #607
Conversation
Signed-off-by: bennett <bennett@umaproject.org>
bmzig
changed the title
Signed-off-by: bennett <bennett@umaproject.org>
| * spoke pool address is stored by the L2 forwarder and the L2 forwarder address is stored in this contract. | ||
| * @param message Data to send to target. | ||
| */ | ||
| function relayMessage(address, bytes memory message) external payable override { |
There was a problem hiding this comment.
OOC, why did you decide to do this via delegatecall rather than inheritance? To avoid having to have a different contract for an L2 with custom gas vs non custom gas?
There was a problem hiding this comment.
I have a delegatecall so this can work with any L2 by piggybacking off of the adapter logic. Naming is admittedly poor here, but the idea was for this (L3) adapter to send messages and tokens to L2 using the exact same logic as the corresponding L2 adapter (e.g. an Arbitrum_*_Adapter, Optimism_Adapter, ZkSync_Adapter, etc) and overwrite the target (since the hub pool will specify the target as the L3 spoke pool due to setCrossChainContracts, which doesn't exist on L2). If I did inheritance, then we would need to make an adapter which inherits from the L2 adapters based on the architecture of the L2 -- something like Arbitrum_L3_Adapter is Arbitrum_CustomGasToken_Adapter or Arbitrum_L3_Adapter is Optimism_Adapter, whereas when we delegatecall, we can keep the code exactly the same and just change constructor arguments.
| */ | ||
|
|
||
| // solhint-disable-next-line contract-name-camelcase | ||
| contract Arbitrum_L3_Adapter is AdapterInterface { |
There was a problem hiding this comment.
I don't think this contract is specific to arbitrum, right? It's really just an adapter for any forwarder, no?
There was a problem hiding this comment.
This is likely due to my poor naming, but I did this to emphasize that the L3 is Arbitrum-like. There is no assumption about the structure of the L2.
There was a problem hiding this comment.
The naming is still a sticking point for me. I think it makes sense to spend some more time thinking about this. This contract actually functions more like a (re-)router I guess, but maybe that's just my networking bias.
There was a problem hiding this comment.
I agree this naming is not useful right now. Because it has "L3" in it its non-intuitive that its actually meant to be deployed on L1. Let's also remove the Arbitrum mention from the name because its clearly not specific to Arbitrum. Please change all the comments also to make it clear this can be used generically.
I think a rerouter in the name could work, and clearly to be consistent with other L1 contracts it should end with Adapter. What about RerouterAdapter?
There was a problem hiding this comment.
Optimistically changing it to RerouterAdapter and updating the comments to emphasize that it can be used in other contexts 1e984cc
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
nicholaspai
changed the title
nicholaspai
changed the title
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
| * @param message Data to send to target. | ||
| */ | ||
| function relayMessage(address target, bytes memory message) external payable override { | ||
| bytes memory updatedMessage = abi.encodeCall(AdapterInterface.relayMessage, (target, message)); |
There was a problem hiding this comment.
Can you add some comments explaining how this double relayMessage encoding works? Think its a bit confusing and assumes knowledge of the l2Target's interface
There was a problem hiding this comment.
I added this d87d09c. It definitely assumes knowledge of the l2Target's interface.
The L3 adapter to send messages to Arbitrum-like L3 spoke pools should piggyback off of our existing adapters to first relay tokens/messages to an intermediate contract on L2. These L2 forwarders should then have logic to continue the token bridging or to execute stuck messages.