Adding RollbackInbox and upgrading Messenger & Bridge

[skeletor-spaceman]

Description

Adds a way for the CrossDomainMessenger to "send-back" failed messages.
These failed messages are stored on the origin domain in a RollbackInbox contract.
This enables smart contracts to handle "failed" messages.
e.g. the StandardBridge can safely recover stuck funds by validating that a message was indeed NOT successful on the other domain.

For this proposal, we've also prepared a detailed Notion document, found here, that goes through the rationale and need of the RollbackInbox and accompanying functionality on the CrossDomainMessenger & StandardBridge.

We also believe this would be an important primitive for Interop.

Would love to hear your thoughts and any feedback you might have on this proposal :)

Tests

N/A

Additional context

https://defi-wonderland.notion.site/RollbackInbox-V1-c5dc38b62cf64b51807427012c991bb3
L2ToL2CrossDomainMessenger alternative: #203

Metadata

N/A

This proposal was developed as an internal research project at @defi-wonderland lead by @0xng.

[tynes]

Do you see any other use cases besides unlocking stuck ERC20s? Trying to get a sense of what the major use cases built on this would be

[skeletor-spaceman]

that's a great question, yes.
we think this will be a great primitive for handling the not-so-happy path of cross-chain actions.
another example would be a cross-chain(x) swap, where the origin.amm would forward and save an identifier of the user xAction.
which, if the xMessage fails, will be used to continue and gracefully handle the reverted xAction, returning the funds or an LP position to the swapper.

[tynes]

We use to have this built directly into the standard bridge, see https://github.com/ethereum-optimism/optimism-legacy/blob/8205f678b7b4ac4625c2afe351b9c82ffaa2e795/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L163

[skeletor-spaceman]

this is great! this was our first approach to try to fix the problem.
but we thought that if we were to modify the core contracts, we would rather see a future-proof feature being added than a patch for a specific use-case.
while also keeping at a minimum the required modifications to the current codebase.

[tynes]

While $320,000 worth of ether is a good amount of money to be stuck, we should ask the question of whether or not this is the biggest fish to fry. Would love to hear some feedback from users that are asking for this feature right now.

I also wonder if there are simpler ways to solve the problem, like reintroducing the check we had in the legacy version of the contracts or changing the semantics around the minGasLimit. The maintainers of the EVM recommend against gas introspection and want to remove the ability to do that in the future, we learned the hard way through the complexity that was introduced by having gas introspection through minGasLimit. It was originally introduced to make withdrawal relay networks more safe, but it turned out that the withdrawal relay networks were never built in practice. I lean towards solutions that remove the minGasLimit (example: introduce new style of withdrawal message without minGasLimit, ignore minGasLimit on legacy withdrawals) as it reduces complexity while solving problems

[skeletor-spaceman]

@tynes I think this might not be a "big" fish to fry, but it's definitely an interesting one, as it aligns us on a solid standard for cross-chain messaging, which will become the bloodstream of the Superchain.
also, we'll work on a quick Spike/R&D task, that would complement this RFC, to check how could we remove the minGasLimit overhead, and what the side-effects might be.

[tynes]

@tynes I think this might not be a "big" fish to fry, but it's definitely an interesting one, as it aligns us on a solid standard for cross-chain messaging, which will become the bloodstream of the Superchain. also, we'll work on a quick Spike/R&D task, that would complement this RFC, to check how could we remove the minGasLimit overhead, and what the side-effects might be.

cc @clabby who has thought about this problem a bunch