• # Regen Cosmos SDK Architecture Review``

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

Agenda Items

• Gas-floor (base transaction fees) #8224 #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
• PLEASE REVIEW: Gov Split Votes [#7802](https://github.com/cosmos/cosmos10000
• ****-sdk/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