Skip to content

Adding returnedMessages primitive into L2ToL2CrossDomainMessenger#203

Merged
tynes merged 15 commits intoethereum-optimism:mainfrom
defi-wonderland:feat/sent-back
May 29, 2024
Merged

Adding returnedMessages primitive into L2ToL2CrossDomainMessenger#203
tynes merged 15 commits intoethereum-optimism:mainfrom
defi-wonderland:feat/sent-back

Conversation

@skeletor-spaceman
Copy link
Copy Markdown
Contributor

@skeletor-spaceman skeletor-spaceman commented May 22, 2024

Description

Adds a way for the L2ToL2CrossDomainMessenger to "send-back" failed messages.
These failed messages are stored on the origin domain's L2ToL2CrossDomainMessenger.
This enables smart contracts to handle "failed" messages.
e.g. a future L2toL2StandardBridge will be able to 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 returnedMessages mapping and accompanying functionality and required modifications.
We've also prepared an example of the technical PR

We believe this would be an important primitive for Interop and the canonical bridge.

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/L2-L2-Stuck-Messages-71a4cdb5a06c48fb94d0b98d89c46a03
previous PR: #184

Metadata

N/A

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

@tynes
Copy link
Copy Markdown
Contributor

tynes commented May 22, 2024

Just to be clear that the StandardBridge and the L2ToL2CrossDomainMessenger are in different bridge systems. The L1<>L2 bridging contracts are strictly different than the L2<>L2 bridging contracts, so a change to the L2ToL2CrossDomainMessenger wouldn't impact the L1<>L2 StandardBridge flow

Comment thread specs/interop/predeploys.md Outdated
@skeletor-spaceman
Copy link
Copy Markdown
Contributor Author

skeletor-spaceman commented May 22, 2024

Just to be clear that the StandardBridge and the L2ToL2CrossDomainMessenger are in different bridge systems.

oh nice catch, since we don't yet have a L2toL2StandardBridge, I mentioned it as an example, but I'll add a clarification as to not get things confused with the L1<>L2 flow.

Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
@skeletor-spaceman skeletor-spaceman self-assigned this May 23, 2024
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md Outdated
@tynes
Copy link
Copy Markdown
Contributor

tynes commented May 24, 2024

I am generally in favor of this approach and would be open to getting it merged, I think it can be a powerful primitive. It doesn't solve the problem of sending to a chain not in the dependency set but that might be impossible to solve (?)

Left a set of comments that are generally minor/aesthetic

Comment thread specs/interop/predeploys.md
Comment thread specs/interop/predeploys.md Outdated
Comment thread specs/interop/predeploys.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants