Description
openedon Apr 20, 2020
Problem Definition
When I first ran a testnet for Regen Network, my team and I were able to customize the Lunie wallet and Big Dipper block explorer to support our testnet by just modifying a few parameters in configuration files. In spite of the UX challenges of the amino encoding, this was a fairly good experience.
The current protobuf tx design would make this much harder. Every app will define its own Transaction
, Message
, and SignDoc
types and client applications will need to run code generation for every new chain they intend to support and write custom code to:
- marshal module
Msg
s into the appMessage
- sign transactions using the app-specific
SignDoc
- marshal interface types into app-specific
Msg
s likeMsgSubmitProposal
After having spent just a bit of time actually dogfooding our work, I find these tradeoffs unacceptable.
Proposal
I propose we leverage google.protobuf.Any
to solve these issues. This can be done in a way that improves client developer UX without increasing encoding payload size, by separating signing messages from encoding messages.
google.protobuf.Any
provides essentially the same UX as amino JSON for these use cases:
// amino json
{"type": "cosmos-sdk/Account", "value": { "address": "cosmos...", ... }}
// google.protobuf.Any
{"@type": "/cosmos_sdk.x.account.v1.Account", "value": { "address": "cosmos...", ... }}
One of the biggest concerns around using Any
initially was that it increases stored message size by encoding the long URL. If, however, we just use Any
for signing and a simplified client UX and still use oneof
s for encoding, we don't have to accept a poor compromise between developer UX and performance.
A more detailed proposal will be submitted in the form of a PR.
For Admin Use
- Not duplicate issue
- Appropriate labels applied
- Appropriate contributors tagged
- Contributor assigned/self-assigned