feat: async callbacks

[0xDiscotech]

Callbacks PoC

This draft showcases a complete callback flow where a call originates on the origin chain, triggers execution on a destination chain, and then returns the result to the origin chain, where it is handled with custom logic.

The flow is as follows:

Possible Next Steps

• Having a dedicated library to abstract functionality and facilitate the interaction would be a valuable addition to the ecosystem.

Possible Future Improvements

• Flexible Callback Contexts: Introducing a more complex data structure to support features like expiration times or additional metadata.
• Robust Error Handling: Supporting logic to handle both successful and failed callbacks.

Additional Context

• Leverages the entrypoints feature

[ben-chain]

This is awesome! I did some hacking on something similar here a few weeks back. I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?

In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature. For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

[skeletor-spaceman]

I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?

yes! it's to keep the CDM as the "exitpoint" of the relayed messages, abstracting away the extra logic handled via the "wrapper" entrypoint contract

In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature. For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

this is exactly why we build the entrypoint primitive!
here is the draft idea (Design 2 is the way to go imho): https://gist.github.com/0xParticle/5119cfa271a6fba6ae8b7649e0bba5db