-
Notifications
You must be signed in to change notification settings - Fork 174
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
[v16] SDK v47 upgrade #646
Conversation
I'm probably a strong no with veto on this. Going to sleep on it |
Just so you know, I'm unable to review this PR because it's my own PR, I'm going to do a quick check over everything, and I want to thank you for your work on it |
@Reecepbcups nice catch. Will have a q for you in tg, on my editor I am getting an "ambiguous import error" I've also pinned the versions for the buf libraries. |
Use upstream test features + Enable IBCFee for all transfer channels
have you tried also with Authz? |
@dimiandre Yes, it fails since the underlying message itself fails. The Authz check only had to happen with our impl. since we had to check all subMessages to throw out (Because the subMsg/msg create itself was not being checked by the SDK) Further proof just to double check though
|
protoVer=0.11.6 to 13 |
bump cometbft-db to v0.8.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LFG! 🚀
Thanks for the wonderful walk through on the call today!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LFG! 🚀
Thanks for the wonderful walk through on the call today!
Closes #644
Style notes:
This PR moves all external modules into Juno. To understand why this is being done, allow me to share the sdk-v47 upgrade issue for interchain security:
So, the trouble is that we can't depend on Gaia updating to 47 in a timely manner. Likewise on the new token-factory repository, there wasn't an sdk branch. I think that it is much cleaner to have the needed code in Juno, instead of waiting on upstreams that may be unreliable or slow to upgrade.
Since juno does not use a forked sdk, chain teams wishing to use Juno's very nice (thanks @Reecepbcups) token factory work, can just use a version of juno that matches their desired cosmos-sdk version.
Then, we get into ibc-hooks. Same story. Osmosis ibc-hooks work is great, but does not support sdk 47 or ibc 7. We need that. In nursery, I am handling that by adding ibc-hooks to nursery.
There needs to be a place where this work is integrated and kept up to date. For strategic reasons, I am suggesting that Juno would be a great place for that to happen.
An alternative that I can see is to do this in github.com/notional-labs/nursery, but then, it does not give juno control, if the whole notional team is hit by a bus, juno has to do this regardless.
Juno should not be dependent on others ship schedules, even notional's and especially gaia's.
Description
Subtasks