add back tx/encode endpoint

[tac0turtle]

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 for proto encoding
• add new endpoint for amino encoding of txs feat: Add tx encode and decode endpoints for amino txs #13882

cc @ValarDragon

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ValarDragon]

Please, this would be a great time saver for so many integrations

[alexanderbez]

@AmauryM do you have any insight here?

[amaury1093]

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.

[tac0turtle]

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.

[amaury1093]

OK, sgtm, then adding an endpoint for proto tx JSON<->binary encodings sounds fine 👍 It should go in the tx service.

[robert-zaremba]

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....

[robert-zaremba]

Also, if we confirm the above, do we need it in 0.45?

[tac0turtle]

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(?)

[amaury1093]

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.

[BitHighlander]

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.

[amaury1093]

I don't unfortunately. it may be worth asking https://github.com/cosmos/cosmjs

[roccomuso]

any news about this?

[kevin486]

Sharing an example of how to convert from json to protobuff can be very helpful. Thank you!!

[tac0turtle]

@AmauryM what do you think about injecting an endpoint with grpcgatteway to handle all encoding?

[amaury1093]

SGTM!