-
Notifications
You must be signed in to change notification settings - Fork 74
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
WIP: StdTx: Better JSON support #391
Conversation
The use case for TOML schema definitions was supporting runtime schema registration via configuration files for KMS-backed transaction signing in such a way that the KMS can build and sign transactions for arbitrary Tendermint applications with configuration changes alone, rather than adding application-specific code changes for every transaction format under the sun: (As it were, I think this particular problem of dynamically handling transactions produced by arbitrary applications may be unique to the KMS in the entire Cosmos ecosystem) We tried going down the latter route in our fork of All of that said, the TOML is just the
Admittedly I implemented only what was needed to generate the transaction messages for Terra oracles (we have this crate deployed in production generating them). It's doubtless incomplete in many areas. That said, this crate is working in production today producing compliant JSON encodings (for signing) which are validating on Terra columbus-3. I'm guessing you're not using the right APIs if it's not working?
This crate is a stopgap to do KMS-backed transaction signing with the current Amino-based StdTx format. I'd love to phase it out eventually when the proto3 changes all land, and would be happy to figure out a way to merge it in its current form into
Avoiding the hardcoded prefix is why The https://github.com/iqlusioninc/crates/blob/develop/stdtx/src/msg/value.rs#L61
If the The rest of the changes sound like you're tracking upstream Tendermint v0.33 changes? (not sure myself) All I know is it's working today in its current form in production with Terra Perhaps what'd make sense is to leave this crate as is, upstream the code into |
Wow thank you for the very detailed and informative explanation! I am targeting a quite bleeding edge version of the SDK (ibc-alpha branch), so probably the incompatibilities are all due to that. I will close this PR and leave this crate as is, and start copying what we need into ibc-rs for now - thanks! As for the schema-based use case, that's actually very cool, and conceivably relevant to a full-time relayer node, so at some point it might be interesting to try and expand the scope of msg schemas in can support! |
I've been working on prototype of IBC txs in informalsystems/hermes#52.
Tried to use this lib where I could, but had a few issues. It's possible I misunderstood how to use it, so please let me know if I'm doing something super wrong, but here's what I found:
To unblock my current work, I made a few changes here. I'm not sure exactly what the plans are with this crate, or if these changes make sense for it, but regardless I think Informal would be happy to maintain it, or something like it, in the ibc-rs.
The changes I made were:
Address
so it can be used in Msg types and properly bech32 encoded and decoded in JSON (I see the to_json_value methods but didn't quite figure out how to use them); one caveat here is thecosmos
prefix is hardcoded, will take more work to generalize that (maybe it should be a field in the Address?)With these changes, and the StdTx I defined in informalsystems/hermes#52, I was able to create an unsinged StdTx JSON for an ibc message, sign it using gaiacli, unmarshal the signed JSON back into Rust, and then encode it as not-fully-correct Amino (that part's still a WIP).