Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wasm08 client IBC support #1468

Closed
wants to merge 4 commits into from
Closed

Add wasm08 client IBC support #1468

wants to merge 4 commits into from

Conversation

Reecepbcups
Copy link

@Reecepbcups Reecepbcups commented Jun 28, 2023

In draft until this goes to IBC-go official version (to remove replace statement)

We need to Juno's v47 testnet soon (mesh security as well), so needed to get this ready now

Copy link
Contributor

@alpe alpe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your PR!
I have quickly skimmed through the changes and I am not sure how this relates to ics-008. I would ask to open an issue with details to discuss your feature request. It is usually a nicer way to collaborate than criticize/ defend code. I consider spikes also very helpful in supporting a conversation but expectations should be clear that a spike is for discussion only and not going to be merged.
I would also like to understand how this relates to mesh-security and the planned Juno testnet.

In this PR I can see that you are using the capability module from ibc-go. That makes sense and is required for the sdk 50 upgrade anyway. I had included this into #1448 already but as it is blocked other projects currently, I would be happy to have this replaced earlier.

So why not to a PR to use the official ibc-go v7.2.0 release instead? It would make sense to me to replace all sdk capability imports. No need to rename the import aliases capabilitykeeper/ capabilitytypes. A mixed setup should be avoided. WDYT?

go.mod Outdated
// Uses this fork of the wasm08 client so PFM works
// Now uses github.com/cosmos/ibc-go/modules/capability/types
// go get github.com/crodriguezvega/ibc-go/v7@24d07389e19357ff836f59a60b2a5d3897baaa08
replace github.com/cosmos/ibc-go/v7 => github.com/crodriguezvega/ibc-go/v7 v7.0.0-20230626145354-24d07389e193
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wasm-client branch is built off 7.0.0 still right now as it has been in development for a bit. Once their review is done 7.2 will get merged in and bumped to v7.3+. This is a requirement to get the wasm-client logic in for Juno for now for testnet

https://github.com/strangelove-ventures/ibc-go/tree/feat/wasm-clients-main

@Reecepbcups
Copy link
Author

Thank you for your PR! I have quickly skimmed through the changes and I am not sure how this relates to ics-008.

This PR just pulls in the actual spec (We are using the wasm-client working branch on Juno. Without these changes, wasmd will not even compile) - CosmosContracts/juno#680

I would ask to open an issue with details to discuss your feature request. It is usually a nicer way to collaborate than criticize/ defend code. I consider spikes also very helpful in supporting a conversation but expectations should be clear that a spike is for discussion only and not going to be merged. I would also like to understand how this relates to mesh-security and the planned Juno testnet.

I do agree, I just made it a draft here so others could see the work was already done. I am more than happy to close if we want to wait until it is in ibc-go main.

Juno's testnet will be upgrading to v47 with the wasm-client which required modifications to: Packet Forward Middleware, ASYNC-ICQ, and this wasmd modules to be compatible. This is a requirement for Composable to connect us with Kusama and Polkadot, as well as needed for mesh security per Ethan's comments.

I don't think it is the best idea for us to add the mesh-security-sdk in this testnet (Juno's Uni-6), best for us to make that its own testnet most likely since it is early stages. I am more than happy to take lead on that. That testnet would also have this wasm-client support too.

So why not to a PR to use the official ibc-go v7.2.0 release instead?

The wasm-client branch is built off 7.0.0 still right now as it has been in development for a bit. Once their review is done 7.2 will get merged in and bumped

It would make sense to me to replace all sdk capability imports. No need to rename the import aliases capabilitykeeper/ capabilitytypes. A mixed setup should be avoided. WDYT?

Ahh yes this is a good point. I was thinking backwards compatibility with non migrated scoped keepers, but that would never be the case since you HAVE to migrate because of the new forced types. Thanks for this insight!

@alpe
Copy link
Contributor

alpe commented Jun 30, 2023

Thank you @Reecepbcups for the additional comments!

I am more than happy to close if we want to wait until it is in ibc-go main.

It is unclear to me when or even if this code will go into IBC-go main. I do not want to risk our main branch to depend on this custom fork. We did long living feature branches in the past for early SDK upgrades or some special features. This comes with quite some extra work to maintain and requires some good motivation and preparation. Usually an issue is started to discuss this with community members.

Once their review is done 7.2 will get merged in and bumped

Not sure about this either. But I can see your problems with the capability module when you update your Juno go.mod to the ibc-go fork. It is quite a mess currently. When we upgrade wasmd to ibc-go 7.2 capability, this should be resolved again. It is not in 7.2 🙈

... as well as needed for mesh security per Ethan's comments.

Can you point me to the comments? We discussed ADR-8 support but nothing about wasm-08 in context of MS

To move this forward, I would add the spike label now and keep the branch for some time. Just to manage expectations: our capacity is very limited, please do not expect reviews on a spike.

@alpe alpe added the spike Demo to showcase an idea. label Jun 30, 2023
@alpe
Copy link
Contributor

alpe commented Jul 6, 2023

fyi: I have asked and the capability module will be shipped with the SDK 50 upgrade in IBC-Go. Well get an early alpha or RC tag to start integration.

@Reecepbcups
Copy link
Author

Reecepbcups commented Jul 6, 2023

@alpe

It is unclear to me when or even if this code will go into IBC-go main. I do not want to risk our main branch to depend on this custom fork.

Based off my discussions with Strangelove, they are actively working to get it into IBC go main. Right now it looks like it is targeted for IBC v7.3.X, these commits get it to latest so it works. I will start an issue once we get it up on Juno's testnet here in the next week or 2 (pending reviews from Core-1 right now)

as well as needed for mesh security per Ethan's comments

Disregard this comment now sorry. I talked with the Core team and we are going to put the mesh security SDK into its own testnet since this v47 upgrade + wasm client is already quite large. I let them know I will happily manage and spin this up when it comes time

our capacity is very limited, please do not expect reviews on a spike

Understood, I am just using it here as a placeholder since it is required for our upgrade. I do not expect any reviews as this is bleeding edge implementations

@alpe
Copy link
Contributor

alpe commented Oct 18, 2023

We will be working with the IBC-go team on wasm-08 client support in the future.
The code has been moved from stranglove to the ibc-go repo already, afaik

@alpe alpe closed this Oct 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spike Demo to showcase an idea.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants