###### tags: `Cosmos SDK` # SDK Architecture Review - 2021-05-21 The **SDK Architecture Review** meeting is a bi-weekly meeting focused on architecture discussions of ADRs and features currently in development (any issues tagged with the label "Status: Needs Architecture Review"). ## Agenda - [x] Working Group Checkin - https://github.com/cosmos/cosmos-sdk/wiki/Architecture-Design-Process - [x] Updating module specifications to align with ADR-031 - https://github.com/cosmos/cosmos-sdk/issues/9352 - [x] ADR-036 implementation and potential followups - https://github.com/cosmos/cosmos-sdk/pull/7896 - [x] Typed Events https://github.com/cosmos/cosmos-sdk/issues/7563 - [x] gov deposits querier not returning all deposits - https://github.com/cosmos/cosmos-sdk/issues/8758 - [x] adr-40: use prefix store instead of multistore - https://github.com/cosmos/cosmos-sdk/pull/9355 - [x] Module Hooks - [x] Standardize Bank Module Funds Movement Events - https://github.com/cosmos/cosmos-sdk/issues/9375 ## Notes ### Working Group Checkin We currently have five active working groups. We should start these meetings with a quick update from each working group. #### Consensus Fees (#8224) We have an ongoing discussion about Transaction Types [here](https://github.com/cosmos/cosmos-sdk/discussions/9348#discussioncomment-767176). #### Gov/Group Module Alignment (#9066) Meeting weekly and going through iterations thinking about governance on-chain and discussing group module integration. #### Module Wiring (#9182) Exploring AD-053, which we will discuss today. #### x/auth, x/bank and vesting re-design (#9336) There is discussion currently happening around making the interfaces for bank much cleaner. We are currently working on how we track vesting and how to untangle the current mess around vesting. #### Protobuf golang v2 migration and codegen (#7488) We are going to focus on fast marshaling and user interface design. ### Updating module specifications to align with ADR-031 Currently the interfaces for modules are built around messages. We are considering updates to the specification to reflect a service-oriented architecture. Are we still proposing the "Msg Service" nomenclature? We have discussed updating to a "Tx Service". 95% of our message structs are empty structs. We could consider dropping the message resonse altogether and focus on events. The tendermint team believes events should not be relied upon. They are not part of the block hash. The reason the message responses are not used as often is because of the ### ADR-036 implementation and potential followups We should further discuss when involved members are present. If AiB is not going to move forward with it, we should consider closing it. There is interest and some projects have started implementing. Marko is happy to champion this. Aaron will add to working group. ### Typed Events The idea is to have an event represented by a protobuf message. We are serializing a protobuf message to json. The values end up as quoted strings. Marshalling the json is pretty inefficient. We should take this into consideration as a performance adjustment. A possible solution would be to pass a protobuf Any that would be indexed into Postgres in a logical way. Changing the events to protobuf. We need further clarification on the querying and matching. How are the protobuf Any's repsented when they are persisted? It would probably be a json blob. Tendermint might not know how to decode the blob. Ras does not use tendermint event system. We could expose our own event streamer from the application directly. We would advise operators to disable tendermint indexing and we would rely on the SDK indexer. It would mean a separate interface. We need to consider Tendermint roadmap. ### gov deposits querier not returning all deposits A possible solution would be to not use event query and to keep the proposal records. No oppositions. Let's move forward with solution. ### adr-40: use prefix store instead of multistore We should maybe consider a zero-byte prefix. This might reduce collisions and simplify the implementation. Maybe two bytes. ### Module Hooks There are concerns around doing this at the message level. Every time there is an event is usually a good time to emit a hook. Do these hooks need to be synchronous? Would the hooks ever cause failure? They currently do not cause error or return a value. The idea is that the module emitting the hook does not know who is using the hook. See example in Osmosis: https://github.com/osmosis-labs/osmosis/blob/main/app/app.go#L364 Having more typed hooks can be useful. It should be up to the module whether or not hooks should be implemented.