L-01 Custom Gas Tokens Can Get Stuck In HubPool

[bmzig]

The ZkStack_CustomGasToken_Adapter contract is used to send messages from L1 to ZK Stack-based chains with a custom gas token. The public functions within this contract are expected to be called via delegatecall, which will execute this contract's logic within the context of the originating contract. Particularly, the HubPool will delegatecall the relayTokens function. This relayTokens function is used to bridge tokens to a ZK Stack chain. This function calls _pullCustomGas to define txBaseCost on line 186 to compute the amount of gas tokens needed and, more importantly, pulls the needed gas token amount from the funder.

However, in the case when bridging using the CCTP bridge, the custom gas token is not needed, and thus the pulled tokens will end up stuck in the HubPool.

This issue can be generalized to other computations as well. For instance, the sharedBridge should only be defined when l1Token is different than usdcToken in ZkStack_CustomGasToken_Adapter, and txBaseCost should not be computed when using the CCTP bridge in ZkStack_Adapter.

Consider only pulling custom gas tokens within the relayTokens function when they are needed. More generally, consider avoiding unnecessary computation to define variables that will be used later to reduce gas costs.

The proposed solution is to first check if we are bridging USDC and CCTP is enabled and short-circuit the relayTokens call if this is the case, and otherwise fall back to our "happy path" of pulling the custom gas token and interfacing with the bridge hub.

[bmzig]

Note ZkStackMessageRelayed is not emitted in this case.

[bmzig]

This is also under the assumption that #976 is merged in, too, so not including ZkStackMessageRelayed is fine since it won't exist.