feat: Add SignDocJSON for proto JSON signing

[aaronc]

ref: #9320

After our call today, it feels like this is may be the simplest way forward for now.

Canonical proto signing would be done using this spec: https://github.com/regen-network/canonical-proto3/blob/master/README.md#json

@jleni @gagbo the JSON would look like this:

{
  "account_number": {number},
  "chain_id": {string},
  "auth_info":{
    "fee": {
      "amount": [{"amount": {number}, "denom": {string}}, ...],
      "gas_limit": {number}
    },
    "signer_infos":[{
      "sequence":{number}
     }]
  },
 "body":{
    "memo": {string},
    "messages": [{arbitrary}]
  }
}

Also proto messages will use @type instead of type.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[gagbo]

Hello, I'll try to be short :)

• at least from hardware device signing perspective it should be fine, since it's basically the same thing as AMINO JSON (signing human readable bytes that a small app can parse)

• It seems it will add work on the wallet side regarding serialization (which is expected).

  • Before, we knew we could take any json payload, sort it lexicographically, and sign it without any external knowledge.
  • Now, wallets need to know the proto files that the network expects in order to produce a correct serialization (especially for the inner messages) as far as I understand

I didn't follow the proto development here a lot, is there a place where we can find the proto files currently used by the chain ? Or even an endpoint that serves proto files, so that as a wallet, I can double check my formats during "proto format negotiation" before broadcasting ? I guess those questions are more for cosmos/gaia than this, no idea how getting the correct proto should happen basically, so that wallets can fetch and/or ensure a source of truth for serialization (and avoiding sign verification error on broadcast)

[webmaster128]

Nice.

I think it would be very helpful to see an example JSON dump of this, including one or two messages as well as the hash.

The only annoyance I see with this is that we are back to depending on protobuf field names, enforcing code generators to preserve the original casing even in camelCase dominated ecosystems like JavaScript or Swift. This can only be prevented if there are strict casing rules, like all proto message fields must use snake_case. Then we could let the code generator do its preferred transformation making the linters happy, and auto-convert to snake_case in a signing library when creating a SignDocTextual. Maybe https://github.com/regen-network/canonical-proto3/blob/master/README.md#do-not-use-lowercamelcase-names could be adjusted to enforce snake_case instead of disallowing lowerCamelCase.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fedekunze]

@aaronc is this targeted for v0.43?

[aaronc]

@aaronc is this targeted for v0.43?

No unfortunately not. For 0.44 yes.

[aaronc]

@AmauryM @ruhatch could you review this PR at your convenience please?

[amaury1093]

SignDoc proto def looks good.

I only have questions about naming:

• what did "DIRECT" mean in SIGN_MODE_DIRECT?
• since this is JSON, why are we still calling it "Textual"?

[amaury1093]

@aaronc Are you still pushing commits to this PR? Or would you prefer @ruhatch / me to take over?

[aaronc]

@aaronc Are you still pushing commits to this PR? Or would you prefer @ruhatch / me to take over?

It would be great if one of you could take over. Thank you 🙏

[amaury1093]

As discussed during our standup, @ruhatch will push commits to this PR to address the few remaining review comments.

[orijbot]

Visit https://dashboard.github.orijtech.com?pr=8476&repo=cosmos%2Fcosmos-sdk to see benchmark details.

[amaury1093]

lgtm

Would like a new one!