Developer experience around executing interop messages

[tremarkley]

With the current interop design, if an app developer wants to execute a message through the CrossL2Inbox they must provide a log identifier. This opens the question of how would we expect an app dev to get the log identifier for a message they want to execute? One potential solution is to build a relayer or indexer that listens for SentMessage events from the L2ToL2CrossDomainMessenger. This would push app developers to use L2ToL2CrossDomainMessenger for interop and also limits the scope of the amount of events that would need to be indexed. Also, devs that would like to use a different contract to send interop messages could use our implementation as a reference for building their own offchain infrastructure. Let me know what you all think cc @hamdiallam @jakim929 @nitaliano @skeletor-spaceman

[fainashalts]

I think it makes a lot of sense to present one canonical way for devs to approach interop message identification, giving them the tools to modify the approach as needed. Will be curious what others think! Thank you for starting the discussion. 🎉

[skeletor-spaceman]

@tremarkley I like this reasoning.

This would push app developers to use L2ToL2CrossDomainMessenger for interop and also limits the scope of the amount of events that would need to be indexed.

This is very useful and has a nice side-effect since L2ToL2CrossDomainMessenger will have a lot of nice UX&DX features, besides promoting best practices and a safe&solid interoperable-dapp development environment.

Also, advanced developers can easily build "on-top" of the L2ToL2CrossDomainMessenger if they need extra features, which we could even add as canonical if those gain adoption.

[nambrot]

Chiming in with some of the lessons we had learned on Hyperlane is that at least developers we have been chatting to really value not having to relay/execute their messages themselves. Operating off-chain infrastructure that submits transactions (since its their users who include the tx on the origin) is not something they are usually well suited for. Definitely reducing the operational burden via an out of the box relayer would be key.

Relatedly, since developers prefer to outsource this work to relayers, the question becomes how the relayers are compensated which we at Abacus Works sometimes call the secretly hardest thing about interop. Sharing some historical discussions that we had on this front hyperlane-xyz/hips#3 and hyperlane-xyz/hyperlane-monorepo#2456

We'll have hopefully more to share how a Hyperlane wrapping of OP Native Interop could be a nice option for developers to benefit from the lessons of Hyperlane and leverage existing tooling and infrastructure.

[fainashalts]

Thank you @nambrot this is really helpful! Do you have a sense of why devs don't want to do the relaying/execution? Is it the complexity of it? Is it the need for liquidity on the destination chain?

[nambrot]

It's both. We typically see that users of interop APIs being developers who primarily only operate smart contracts and UIs. Their need to run offchain infrastructure is very rare. Thus, operating things like a relayer is rather foreign to them and significant surface area. Crypto already asks a lot of its developers and infrastructure tooling is poor, so developers try to avoid it as much as they can. The liquidity requirements are not often top of mind for folks at start, only once they are in production they tend to realize that they are playing market maker :)