owned this note
owned this note
Published
Linked with GitHub
# Regen Cosmos SDK Architecture Review
**Date:** Fri Dec 18, 2020 — 4pm CET / 10am ET / 7am PT
**Zoom:** https://us02web.zoom.us/s/86444484091?pwd=T2tabFhqaFVSYkwyM0cycmdITjJCdz09
**Attendees:**
**Recording link**: https://us02web.zoom.us/rec/share/pVZe913d7T8D-vEQo5aUPXf2M-tvFSCFnfX6IRs2zyLRMd_Kzmo1LVLXetGwSFHq.g8a0FnWIQAsZ5w2j
Passcode: J0Gg6hV#
## Agenda Items
- [x] [ADR038](https://github.com/cosmos/cosmos-sdk/pull/8012)
- [x] [ADR033](https://github.com/cosmos/cosmos-sdk/pull/8190)
- [ ] Stargate Update
- [ ] Non ADR walkthrough with Aaron
- [ ] x/bank refactor
- [ ] Group module in SDK
- [ ] protov2 learnings / codegen exploration
- [ ] Rosetta API code walkthrough. Happy to arrange it Monday/Tuesday morning CET timezone. Ideas are welcome
## Notes
- ADR036 -- Status is that the issues should be folded into "Further Discussion" section, and it should be merged as a Draft
- ADR033
- Paddy - Concept ACK from AiB side
- Aaron:
- We could walk through a reworked bank that meets ADR33. I'd be curious if its useful to walk through that today?
- Without Bez / Alessio here, i'm not sure if this is the best to walk through today
- *talks through potential walkthroughs*
- Marko: I'd like to hear about learnings for proto-v2 / codegen
- proto-v2 & codegen
- First part about is just service definitions (which generate client/server interfaces)
- Took official golang grpc code generated (just 400 lines or so)
- We don't have streaming services... so i dropped the streaming lines of code (and now its 280ish lines of code)
- We can really customize the codegen however we want to improve ergonomic
- They highly recommend people write their own codegen for services
- In order to make it work effectively, I needed to wrap context in SDK.Context. Now clients will use `context.Context`, but servers will use `SDK Context`
- This way for inter module calls, you don't need to wrap the context when making inter module calls
- I wrapped the fully qualified Msg names as constants
- Would like to create seperation between Msg services and Query services
- For Msg clients, you'd ideally like to have an actual async client (where you return a channel)
- For Queries - you may want have a function for each query, without needing to construct a client first
- Robert: Question about the query- so Client will be initialized in the Context?
- Is there any usecase where we would need to create the client before?
- Aaron: In ADR33 yes, but that's only for authorization
- Currently there's a pull request on Regen Ledger, and this could be easily be added to the SDK if there was a concept ACK
- Let's create a github issue and link to regen-ledger/#207
- Proto v2
- It seems pretty clear that gogoproto will get deprecated, and the maintainers from gogoproto have suggested users just start from scratch and write a condegen for protov2
- The default codegenerator for protov2, does not create any customization for generation of the struct
- they don't want to do that for an official codegen
- it uses reflection to do marshalling, so that is slower than gogoproto
- It does also support hooks for custom marshaling
- Robert: do you have an idea of the performance increase?
- Aaron: we'd have to do custom code generation, and i think the performance should be fine
- Sounds like using v2 protoreflect would be 4-5 times slower than what gogoproto is doing
- Basic marshaling-
- Custom fields may be a challenge
- For `Anys` we have a path forward
- For custom types, its a bit more complicated, particularly wrt bech32 encoding
- Alessio:
- I like it, thanks for the overview
- Q: Perhaps the only downside is that someone will have to maintain the code generation / customization
- Q: This nice thing, currently lives in one of your repositories?
- Aaron: The service generator lives in regen. This is much simpler than upgrading to golang-proto v2. Upgrading to golang-protov2 is a much bigger task
- Alessio: if you're ok with that, we should move that under the cosmos org on github, and maybe create a seperate repository?
- Marko: In thinking about this and the larger community, I think more people would benefit from these implementations- something specific to cosmos sdk and something generalized to protobuf?
- Aaron: I think for the service code generation (it's much more specific to Cosmos SDK), for golang-v2 it definitely makes sense to think about other users within the cosmos ecosystem at a minimum
- I would be hesitant to say "let's do this for the whole golang community"
- If we want to use bech32 in some custom way... its much easier
- If a lot of other projects are expecting us to use & maintain, that could be a burdon that we need to assess
- This would involve setting a handful of cosmos-proto annotations
- Service codegen could be just a package within the SDK
- Anil: If we have custom annotations, will there be grpc-gateway support? They stopped supporting gogoproto already.. so this is another reason for moving to golang v2.
- It is possible for us to also take advantage of cosmos specific annotations
- Rosetta:
- Alessio- we found some limitations of the Rosetta specification
- the SDK provides state machiens, and when events happen at endblocker or beginblocker (and your coins become liquid / available for you), and this presents a problem
- With rosetta API it becomes impossible to track teh supply for beginblock / endblock
- There is no way for us to represent state changes as a rosetta API transaction
- Monday / Tuesday we're happy to do a code walkthrough, we are happy to setup and talk through what we've done
- Robert: If we will do migration to golang proto2, how big is the task?
## Follow-ups
-