Hyperlane Developer Experience Demo

[nambrot]

Description

This PR outlines a demo of what the developer experience could be when using Hyperlane as a wrapper over OP's Native Interop. Figured a PR with a README and config is the most appropriate but happy to do it in a different way. Here is a video recording of the demo https://www.loom.com/share/05ec7dbbd3ff406d8819fefb1af741b4?sid=330f2f86-1487-4cc9-8819-9c4fa5e7b6f1

[hamdiallam]

thanks for the PR! @nambrot

we're going to flesh out in a bit what the best pattern should look like for 3rdparty integrations. I'm thinking of having experimental flags that can enable features. For example

$ supersim fork --chains op,base --with-hyperlane

I'm thinking would be great if the integration could take care of deployment (likely only important for non-forking) and also pull in the pinned 3rdparty binaries needed to make the integration just work.

wdyt? Will source some more thoughts and come up with a better plan as we wrap up the interop integrations

[fainashalts]

We've been spelling it "DevX", can this be changed? I can't rename the Discord channel, I know that's DevEx but its an outlier. 😄

[fainashalts]

@nambrot this is so great! Thank you for trying out Supersim and putting this together. ❤️ I agree with @hamdiallam it would be really cool to have a --with-hyperlane feature flag or something like that. I see you use npm so it could be challenging. I don't think its a requirement, would just be nice to make the flow of including Hyperlane a little cleaner for devs. And perhaps it could wait until we have a standardized approach for plugins.

I like your suggested Future Improvements! In particular, I think integrating native interop into the ISM that is used would be really neat! Is your team already working on that and can Supersim be useful in your testing? If there are features or other products that would help you accomplish this we'd love to see if we can help.

I also think it would be nice to automate everything that can be automated (like deployment of Hyperlane contracts on the desired chains). Would love to see that added.

[nambrot]

Thanks @hamdiallam @fainashalts for the feedback! Definitely interested in figuring out how make this work out of the box on supersim, though tbh i didn't find the additional CLI commands to be that cumbersome either, and given the different stack it might be all around easier with this integration scope. Really comes down to how you think people would like to leverage this + how you have been thinking about other integrations.

Regarding the ISM work, I think the best path forward would be to

1. wait for the native interop funtionality to land in supersim (IIUC that's not in yet?)
2. implement the ISM
3. integrate the ISM to be automatically deployed for supersim users?

wdyt?

[hamdiallam]

@nambrot

i'm coming around to the relayer being run as a separate process rather than pulling it into one command that could make things tricky to configure and convolute supersim.

However I think a good integration here for something like --with-hyperlane is to run the deployment scripts for the hyperlane contracts in vanilla mode. When forking the registry, this integration can also deploy on the fork network or if the entrypoint addresses are fixed, can replace the deployed bytecode with anvil_setCode to contracts in progress that leverage interop.

For (1), the changes have landed and the e2e tests for them are in. Going to push in a couple last changes by early next week after a review we did this week

[fainashalts]

@hamdiallam if in Vanilla mode, my main concern is we lose forking, which I think would be really useful. What do you think?

[fainashalts]

@nambrot yes I think your plan makes sense, and I think we could keep it a separate process. Then y'all could add instructions for using Supersim with Hyperlane in your docs, and we could add instructions for Hyperlane on our side (I'm envisioning a little "app store" of integrations with Interop launch partners with instructions & links for each). Does that align with what you're imagining?

[hamdiallam]

@hamdiallam if in Vanilla mode, my main concern is we lose forking, which I think would be really useful. What do you think?

Support for forking is definitely apart of this! I think I poorly worded it. I was mainly trying to say that with the in development interop hyperlane contracts, there's different methods to use to get the existing forked contracts updated with the dev ones locally

[nambrot]

Sounds good to me, let me know once 1) lands and we can try it out on our side. Definitely agree that vanilla + fork support is ideal. Definitely let us know what else we can do!

[fainashalts]

Hi @nambrot you should be able to use Supersim for native interop already! Let me know if you want to chat about it!

[nambrot]

@hamdiallam @fainashalts I update the guide to include our prototype of the SuperchainHook and SuperchainISM. Here is a quick loom about it as well https://www.loom.com/share/e3e4937d1e294ddfb570da1ea2166d68?sid=5aae8464-68f1-4c19-b8be-5bec00f9eeca. You can find the diff that we needed to support on our tooling side here https://github.com/hyperlane-xyz/hyperlane-monorepo/compare/nambrot/superchain-ism, as you can see its pretty minimal.

[hamdiallam]

nice! we don't need to overengineer this right now but it would be great if we had more dynamic scripts such that if supersim is run in fork mode, this integration could seamlessly work when the spun up chains an differ.

I can help make that change though when some time is free. Probably will also scope these added dirs to ./integrations

[nambrot]

Moved the files to an integrations subfolder

[hamdiallam]

Sweet!

Last comment: can the config folder also be in /integrations. Doesn't have to be within hyperlane but ./integrations/configs

[nambrot]

Moved!

[hamdiallam]

ty!! @nambrot