- [ ] # Regen Cosmos SDK Architecture Review``

**Date:** Fri Feb 12, 2021
**Zoom:** https://us02web.zoom.us/s/86444484091?pwd=T2tabFhqaFVSYkwyM0cycmdITjJCdz09
**Attendees:**

## Agenda Items
- [x] Gas-floor (base transaction fees) [#8224](https://github.com/cosmos/cosmos-sdk/discussions/8224) [#4527](https://github.com/cosmos/cosmos-sdk/discussions/4527)
- [ ] Moving off of gogoproto (Exploring golang proto v2 API)
Bank Refactor unsafe API [#8473]``(https://github.com/cosmos/cosmos-sdk/pull/8473)
Tendermint events issue [#5963](https://github.com/tendermint/tendermint/issues/5963)
- [ ] PLEASE REVIEW: Gov Split Votes [#7802](https://github.com/cosmos/cosmos10000
- [ ] ****-sdk[](https://)/pull/7802)

## Notes
- Cory: Let's start with tx-floor / base feels
- Marko: I'm more a fan of specific messages needing specific gas (e.g. for validator key rotation we may want a higher gas fee than the base fee)
- If you make it queryable (with every msg definig its own base fee), then this would be better for devX
- For EIP 1559, it seems interesting, but also quite a lot of unknowns
- Sunny: EIP1559 seems well researched, but maybe further down the line
- Sunny: We could also have validators propose a min fee, and at the protocol layer we take an average min-fee
- Aaron: That proposal sounds good to me. I did have one concern w/ the adjusting-sliding approach that Bex proposed. It does not adjust the spamming issue as if there is not a lot of activity, then the min fees will be low.
- If the goal is spam prevention, the best strategy is probably having validators signal.
- Sunny: Really these could play together- the vlaidator min-fee is more a "minimum minimum fee", and you could still have sliding scale fees ontop of that.
- Aaron: You could still end up with a type of byzantine behavior where there is a minimum fee, but a byzantine validator could propose a block with lower or no fees
- We may need to introduce a new type of slashing here
- Sunny: I think new slashing behaviors is out of scope for this. ABCI++ will allow for slashing validators due to improper checkTx's
- Validators can already spam today with incorrect signature transactions
- Aaron: The other piece from Marko (individual modules having a higher base fee). In Regen's use case we may want (rather than higher gas fees), there could be fixed costs for certain operations (like 1 uatom for creating a new group).
- Fixed rate fees would then sit ontop as a new layer in addition to gas
- Sunny: When I want to add additional fees, I usually just add to the gas counter directly
- Sunny: My preference is for adding gas as opposed to adding fixed fees. As the gas price is the one thing that can be adjusted in proportion to market price
- Aaron: The one issue is that this doesn't account for a max-gas / max-computational cost per block. What about when you want something to cost a lot (of gas), but it shouldn't trigger some computation reason for failing a block.
- Sunny: We should probably have two gas counters, one for computational based gas, and one for "auxilary gas"
- Aaron: We do have certain things like "creating a new asset class" (for carbon credits), which don't cost in storage or computation, but we do want to have a min cost / fee for such actions
- Sunny: that actually reminds me more of governance min-deposit, where it works outside of the scope of gas
- Sunny: IMO we should focus gas on being a really good resource constraint measure. If we want to work on social constraints, we should use something else outside of that.
- Sunny: If we do build this "medianizer tool" (for validator signalling, taking a weighted medial), it would be great to generalize this to any number of parameter
- Aaron: If we did this as a params module extension (param_vote), then at the governance layer, you could switch between a parameter being dictated via gov votes versus live signaling
- Bank Refactor unsafe API
- Jonathan: This is related to the complete balance tracking
- This reduces the bank API to 3 methods:
- Mint, Send, Burn
- The idea is to have only these 3 points where we can throw events in order to control the balance movement as needed by the Rosetta API
- Frojdi: There is some urgency in us getting this merged, as we will need to fix a bunch of tests if more Send tests get created
- Robert: I can take a look
- Tendermint Events Issue
- Jonathan: In order to take advantage of this new balance tracking, we need to parse events from begin & end block and order them
- We saw an issue in tedermint where it looks impossible to get events that happen on Begin or End block...
- Marko: I'm not sure why it was made to be that way. As for a timeline for an improvement.. Of the two issues linked in that issue, Adding Begin/End block querying support is something that's less breaking and Bez is slated to begin work on it soon
- Events collapsing seems like a bigger change, and would probably come later
- Jonathan: Rosetta is not stateful, I need to query all events..
- Moving off of gogoproto
- Aaron: If we look at hte proto package, we can see proto.Message is an alias for protoreflect.Message
- You can create a new instance, you can iterate over a range of fields, get/set field values...
- At hte bottom there is a ProtoMethods() function which allows for non-reflection based marshaling
- As a reminder- gogoproto does non-refleshin based marshaling code which is quite fast (going through each attribute/field of your message, 1-by-1 and encodes it into a buffer)
- If you look at hte protobuf v2 generation, it's pretty short (basically implements this ProtoReflect() method using some internal reflection wrappers)
- So right away, we would need to write our own code-generator as none of that exists in the upstream golangv2
- You need to implement the method struct
- Robert: So all of the XXX_(methods) would be deprecated?
- Aaron: We could indeed use the same code generator and just modify it, but it still means using our own code generator
- Marko: Does APIv2 not allow for you to use its code generator and modify a few methods?
- Aaron: No, the core of what it does is this ProtoReflect() method, and there's no way to just override that method
- You could maybe wrap the return value of ProtoReflect()... but i'm not sure that's a good idea. I don't like their codegenerator at all and would rather not re-use any of it
- Gogoproto also gives us other nice things like customtypes and other customization of the generated code...
- I think you could do these same things w/ golang v2 and a custom code generator
- I'd like to explore instead of "Any"'s we could actually have Interfaces
- Right now we have custom `UnpackInterfaces` methods, and we could potentially move away from that with our own code generator
- One other thing we could make use of- We're currently doing bech32 unpacking manually to avoid using custom types...
- Robert: We are fine with what we have now, right? Maybe we could wait a year or two and see what else emerges
- Aaron: I agree that gogoproto is not broken right now
- Marko: The problem is that the SDK in. thefuture won't be able to update dependencies (like gRPC). The whole proto story gets left a generation behind. It could be like python (python 2-3 was a multi-year endeavor), or it could be that the ecosystem moves quite fast
- Robert: Is there a strong dependency btw gRPC and gogoproto?
- Aaron: gRPC-gateway doesn't deal with the customziation of gogoproto well
- It seems like other things in the ecosystem are moving away from gogoproto
-

## Follow-ups
- Regen will start with a basic implementation of consensus based min gas price. We will start with an approach that averages validator signals and sets a min gas price to the median price voted by the validator set. An algorithm with sliding scale updating of min-price could be implemented ontop of this.
- In the future, there could be other Msg specific fee floors implemented, but that will be tackled at a later point in time