# Regen Cosmos SDK Architecture Review - April 23, 2020

**Date:** April 23, 2020
**Attendees:** Ira & Phil (Provenance.io), Aaron C, Alessio, Sahith, Anil, Gregory, Jack Zampolin

## Agenda Items
- [ ] `oneOf` vs `Any` client-side protobuf tx UX
- Related issue: [#6030](https://github.com/cosmos/cosmos-sdk/issues/6030)
- Updated ADR 020 pull request: [#6031](https://github.com/cosmos/cosmos-sdk/pull/6031)
- 3 Proposals discussed are in this [comment](https://github.com/cosmos/cosmos-sdk/issues/6030#issuecomment-617834848)
- [ ] ..

## Notes
- Aaron: Have folks been able to read the #6030 / #6031 issue?
- Allessio, Anil, Sahith don't have much context, Aaron will give overview of the problem..
- Current context is that we have a `oneOf` at the SDK app level
- There's a history going back to ishmael trying to make Amino compatible with protobuf3
- He suggested we use protobuf's `Any` as a way to support the `oneOf` that amino has
- Multi-chain wallets & block explorers will have "most things work", but the stuff that is the same will work the same
- Few alternatives:
- Ethan proposed: making a schema registry so all types in the `oneOf` are globally defined somewhere
- separate the storage & signing layer, so that signing happens via `Any`, and encoding happens via `oneOf`
- 3rd alternative: move both encoding & signing layer to `Any`
- Alessio: Some background.. I like this approach (#1 by Ethan, with a global registry of field numbers). I remember meeting ethan in 2018 or something and this conversation from earlier, with Ethan's approach back then. But i should take some time to read up on the comments and digest.
- Jack: Been hard for me to follow hte details of this.. feels like it's been a 9 month long discussion. I want to make sure we hold the voice of client developers, and focus on client-side UX
- I worry we're going to miss a huge opportunity if we don't take this time to make things better for our javascript friends
- Ira: Couple of things going on here. Part of the reason this proposal is difficult is that its trying to cover several things at once. If we were to explore hte global registry piece for a little bit, my initial concern is that the `oneOf` concept tries to rollup everything from the entire hierarchy into one set of files. Switching to `Any` actually allows for that registry to have a hierarchy.
- Signature aspect is also a point of concern. In the current model the signatures require you to take the canonical message, and convert it into some alternative format (so the user can have better insight to what's in there), but the signature associated with it is not associated with the byte-for-byte message itself
- Alternative would be to have a signature of teh bytes itself, then the signature verification is much easlier
- Aaron: A big concern being raised here is that the ecoding is different from the signing format?
- Say you have a REST api that's changing over multiple versions, you may use a schema to allow for different API versions to be used by different clients
- We could decouple hte 2, and allow for blockchains to decide over time what their encoding format is
- Phil: I'm actually in favor of what you're saying. Leaving the option of (2) or (3) dependent on what clients
- Aaron: The challenge with proposal #3 is that you're giogn to have to increase gas costs and storage costs across the board.
- Jack- what is your perspective here?
- Jack: We've historically favored performance over UX, and the entire protobuf migration helps us on state size, so i hope that #3 would be a possibility, as we have an opportunity to focus on UX here
- Alessio: To some extent, we've often relied on the underlying layer (Tendermint) to be responsible for performance issues
- Bez: I understand we are discussing using `Any` for state encoding? Can I ask why?
- A lot of this is information overload, the PR is very noisy...
- Aaron: I was proposing (2), but then Ira and Simon were proposing that signing encoding should be the same as state encoding
- Ira: I have more of an aspirational architecture desire, where it feels that if you have a single way of doing it, then there's less technical friction going on
- I wouldn't strongly advocate giong from (2) to (3). I don't have a strong preference, just thought it would be simplification
- Bez: I think Jay had really strong opposition to Any.
- Aaron: That's the biggest reason I can think of why we didnt use `Any` in the past. Jay was opposed to bloating the size of the message w/ the type URL.
- Bez: Hypothetically, what's the level of effort to convert the current state encoding to `Any`.
- Aaron: I think it's pretty small
- Cory: Are there cons for `Any` from a client UX perspective?
- Aaron: if you're coming from a programming language where you want everything to be represented in Sum types, then you know what all the possible instantiations are for your message type.
- When putting yourself in the perspective of a JS developer, the overhead of downloading all proto files is higher than you simply handling an error from the server if you use the wrong type.
- Aaron: you could have a schema registry with teh `Any` approach, you just wouldn't need that master file

Preferences: (on 1 vs 2 vs 3 as illistrated [here](https://github.com/cosmos/cosmos-sdk/issues/6030#issuecomment-617834848))
- Ira (3 first, 2 is acceptable)
- Phil (3 would be nice, 2 would be a good tradeoff)
- Bez (Seems like option 2 is the path of least resistance, based on what we have implemented & documented already)
- Jack (Preference is for 3, more pain now for better client UX later)
- Aaron (curious about option 3, would want to run benchmarks)
- Cory (3, for having one way of doing things across tx & state)
- Anil (1, with centralized registry)
- Sahith (3, would be good to have)
- Alessio (inclined to go for 2)

## Final thoughts
- Jack: As a group we need to think about what's best for the ecosystem as a whole
- Cory: Seems like rough consensus is that we start with (2), and move to (3) potentially later after some benchmarking
- Ira/Phil: As new community members this level of discussion is impressive and encouraging. Feeling very encouraged about the choice to explore Cosmos so far.

## Follow-ups
-