feat: passthrough L1->L3 adapter to send messages to L3 via an L2 forwarder

[bmzig]

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.

[mrice32]

Looks great -- just one comment

[mrice32]

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?

[bmzig]

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.

[mrice32]

I don't think this contract is specific to arbitrum, right? It's really just an adapter for any forwarder, no?

[bmzig]

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.

[pxrl]

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.

[nicholaspai]

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?

@pxrl

[bmzig]

Optimistically changing it to RerouterAdapter and updating the comments to emphasize that it can be used in other contexts 1e984cc

[nicholaspai]

Looks good from my end

[pxrl]

Very minor nit on naming: "Rerouter" is a mouthfull; "Router" is easier to communicate.