cosmos-sdk
cosmos-sdk copied to clipboard
add back tx/encode endpoint
Summary
tx/encode endpoint was removed without a migration path given to many users. This has caused lots of trouble. It would be good to add an endpoint to grpc for tx/encode. This will help a lot with client interactions.
Proposal
Add tx/encode to grpc services.
cc @ValarDragon
For Admin Use
- [x] Not duplicate issue
- [x] Appropriate labels applied
- [ ] Appropriate contributors tagged
- [ ] Contributor assigned/self-assigned
Please, this would be a great time saver for so many integrations
@amaurym do you have any insight here?
The old /tx/encode endpoint took as input a StdTx as JSON, and outputs new proto Tx's proto-binary bytes (as base64). Unfortunately we cannot do that anymore. The StdTx does not have a readable sequence, so we can't populate this field in the proto tx.
We could add a new endpoint for proto tx JSON -> proto tx Binary conversion, but then what's the point of doing that over network when 4 lines of code suffice to do it locally.
4 lines of code in go or js, python, etc as well?
for my use case I don't want to have any codecs on my client, I want to get the format of the message from grpc and be able to broadcast it. To do this currently my understanding is I need codecs of the proto messages.
OK, sgtm, then adding an endpoint for proto tx JSON<->binary encodings sounds fine 👍 It should go in the tx service.
Are we sure there are no hidden traps? Can we safely encode every message with standard JSON (not a proto-json) without missing anything? Before we were using Amino....
Also, if we confirm the above, do we need it in 0.45?
Are we sure there are no hidden traps? Can we safely encode every message with standard JSON (not a proto-json) without missing anything? Before we were using Amino....
I believe the json received in grpc reflection is Proto-json? @fdymylja could you confirm?
Also, if we confirm the above, do we need it in 0.45?
I would love this for 0.45 but also its not breaking so we could backport it(?)
Are we sure there are no hidden traps? Can we safely encode every message with standard JSON (not a proto-json) without missing anything? Before we were using Amino....
Yeah, as Marko said, that endpoint would handle proto json only. No std json, no amino json.
We could add a new endpoint for proto tx JSON -> proto tx Binary conversion, but then what's the point of doing that over network when 4 lines of code suffice to do it locally.
@amaurym do you have a js/ts example of doing this locally? I maintain https://github.com/shapeshift/hdwallet a library for broad Hardware wallet support (trezor/ledger/keepkey) and i'm unable to broadcast our signed payloads. (example) with the latest node version.
any advice for how to address this offline, in client, would be helpful, thanks.
I don't unfortunately. it may be worth asking https://github.com/cosmos/cosmjs
any news about this?
Sharing an example of how to convert from json to protobuff can be very helpful. Thank you!!
@amaurym what do you think about injecting an endpoint with grpcgatteway to handle all encoding?
SGTM!