# Regen Cosmos SDK Architecture Review

**Date:** Fri April 9, 2021. 4pm CET / 10am ET / 7am PT
**Attendees:**
**Zoom:** https://us02web.zoom.us/j/86444484091?pwd=T2tabFhqaFVSYkwyM0cycmdITjJCdz09

## Agenda Items
- [x] When Cosmos SDK v1.0.0?
- [x] Gas Fee Framework [#9072](https://github.com/cosmos/cosmos-sdk/discussions/9072)
- [x] Pulling in tm-db (Marko)
- [x] Discuss snapshotting hooks [#7430](https://github.com/cosmos/cosmos-sdk/issues/7340)
- [ ] ADR Status Review (pending conversations)

## Postponed
These items will be better discussed when there's a more concrete proposal:
- [ ] TxBuilder Refactor ([#7541](https://github.com/cosmos/cosmos-sdk/issues/7541), [#8138](https://github.com/cosmos/cosmos-sdk/issues/8138))
- [ ] Regen's Configurator Registration [regen-ledger#301](https://github.com/regen-network/regen-ledger/issues/301)

This will wait until we have Sunny on the call:
- [ ] x/gov and x/group alignment [#9066](https://github.com/cosmos/cosmos-sdk/discussions/9066)

## Notes
### Gas Fee Framework
- Robert: I started a discussion to better understand how we charge gas (specifically what operations do we charge for)
- In the integration of authz & fee grant we've been concerned about additional cost, and wanting to have a standardized way of calculating gas amounts
- The proposal is a simple framework w/ high level operations & storage costs
- Marko: Is this conflating per-message fee consumption / desiging a fee API for applicaitons to inject their own fee models?
- Robert: this is seperate, but they could be integrated in some way
- Marko: This seems to be conflated w/ a mechanism for an application to create its own gas fees
- Robert: The main thing here is to have a reference place or reference table with common costs
- Aaron: It's maybe useful for us to walk through our use case:
- We have situations where we have a loop, without dealing w/ storage, and we want to have a mechanism for determining what the gas cost would be
- The idea is to simplify some top level things at the app level as opposed to with each specific module
- Marko: And similarly to the "loop use case" it'd be nice to be able to assign specific gas fees to certain messages on a per-chain basis

### Pulling in tm-db
- The goal of the tendermint team is to archive the tm-db repo
- By pulling tm-db into the SDK, we can optimize usage for certain databases (aka badger & rocks) within the sdk. And we won't need to work w/ the tendermint team on modifications
- Marko: in SDK config you can pick which database you want to use. Within the tm-db repo you have a batch & iterator interfaces for these different databases
- Cory: what's timeline?
- Marko: I'll open an issue with a timeline, asking which db's we'd like to support. I'll timebox it to a week and pull in whatever is needed
- Robert: With lazy ledger team we did some benchmarking and were happy w/ badger & rocks-db

### Snapshotting Hooks

- Marko: Some VMs (cosmwasm/agoric) don't actually store all data in an IAVL tree
- state-sync takes a snapshot of IAVL tree, but nothing else
- By allowing hooks, the snapshotter will also looks for files that have been predefined in app.go to allow other apps to sync non IAVL state in a state sync
- Robert: Its nice to hear that many people are interested in this.
- There might be some use cases for modules that would prefer to have their own database (maybe sqlite, etc). We could provide some tooling or library to help w/ managing that, but in essence the module receives some db handler and can do whatever they want with that
- This would give more freedom to module developers / module designers
- Zaki: I expect this is giong to become blocking real quickly for cosmwasm and agoric. Right now there's a question of "who needs this / who is willing to work on this". It'd be very helpful to have some design sketch with someone whose more familiar w/ the SDK to figure out who can implement it.
- Ideally there's just one implementation that meets the needs of agoric, cosmwasm, ethermint.
- Robert: For cosmwasm this is needed for the state machine right? Internally we were thinking about which route to prioritize-- whether its more module or app determined.
- Aaron: I think the idea that you're providing hooks is not incompatible with providing a general framework
- Shahan: With regards to injecting different data systems together- this is a very challenging problem. If i were designing this i would keep just to hooks. A very simple example of this would be when you want to shard/backup postgres, the sync mechanism is well defined. My recommendation would be to stick to as low overhead as possible, just providing hooks.
- One last thing- when dealing w/ things like cosmwasm or agoric. Cosmwasm may not be able to access the system directly bc of how wasm works. Something like agoric may have access to that- and so this could increase complexity.
- Zaki: Bc of the security model, any hook system needs to not only say "here's how you feed data for syncs", but it also effects consensus behavior where every node must commit to all data that is ever syncable. A model must then be told "you must do this for this height".
- Aaron: So does it sound like the next step here is for someone to work on a candidate spec, and review it here when ready?
- Zaki: Is this on Cosmwasm/agoric or is resourcing available from another team?
- Aaron: I think the thing that its not blocking right now, but may be blocking for the current SDK roadmap is: when we transition to SMT, the idea is to separate the state commitments from the storage layer. Here, the state commitments would just have the hashes of the data, and we would need to find some way for the data to live separately.
- Zaki: Quick comment on that- One way of reading what you just said is "the choice of certain projects to not commit on every height, is a result of the poor performance of IAVL implementation, and maybe we don't need a framework we just need to solve the tree performance problem". My understanding of the agoric problem, is that they don't actually want to commit to every single height.
- Aaron: Our current thinking is that there will still be a commit on every height. There's also some other things that are stored (like secondary indices), and there should not need to be a proof around these.
- In my mind this is something being worked on, but not the highest priority thing to be done in 3 months
- Marko: Seems like there's multiple things to be done in this project. First thing is to see if there's synnergies btw the existing storage work and the needs of agoric & cosmwasm.
- Marko: I'll touch base w/ agoric & cosmwasm to see if they are more concrete written pieces on their use case
- Robert: Storage relevant design we were thinking about for module managed storage: https://github.com/regen-network/regen-ledger/issues/304

### Gov & Group Overlap

- Sunny: I'll take what Dev and I had written so far and post it here
- Aaron: Would it be useful to talk through what was posted here?
- Aaron: We would add an account field to the MsgSubmitProposal. For the current gov case, we would call the chain-wide governance "root", and the root account could delegate to sub groups/accounts
- We would also deprecate gov.Content in favor of regular `Msg`s
- For each account that can work w/ the gov framework, there would be a tally handler or decision policy (a pluggable system for different types of voting parameters that an account has)
- We would need to figure out how exactly you assocliate an account w/ a decision policy.
- One thing that has been proposed a few times is that one could create DAO tokens, where holders of DAO tokens could vote on proposals
- A difficulty of this, is that we do tallying each time a vote is cast. As opposed to doing this in the endblocker when we can't charge gas in an endblocker.
- We would need to figure out some way to set that framework up for fees being delayed until the end-blocker runs
- One idea would have been to snapshot balances at a certain point, but i think we need to figure out what works in practice
- Zaki: Have you thought of the method of people having to stake their tokens when they vote?
- Aaron: we'd need to understand more closely what this means
- Sunny: We basically designed different tallying strategies for different use cases
- Aaron: I think the strategy of tallying at end of voting is the simplest i've seen, but maybe we can do some design later to see what the interface is to make that pluggable
- Sunny: This is also meant to be useful for if you have a DAO on your chain- and doesn't really concern itself w/ root chain governance.
- Aaron: The root module wouldn't need to authorize all other modules, just ones that represent operations only allowed by the root module
- Marko: Callum from the tendermint team has expressed interest in working on some governance pieces

## Follow-ups
- Marko to touch base w/ agoric & cosmwasm on their use case for hooks and get more details
- Marko to reach out to Callum on supporting some governance work