Non-zero Default Fees

[aaronc]

As a short term solution to #8224, we have decided to make a change to how the minimum-gas-prices config parameter is processed.

There are a couple of ways this could work specifically:

1. by default make it an error for validators to set minimum-gas-prices to an empty value. This will require validators to set a minimum fee OR explicitly set their fees to zero, or
2. force app developers to set a default value for minimum-gas-prices which will be used if validators leave this param empty

Adding to the feature backlog for the next release.

[tac0turtle]

This seems like its already possible (https://github.com/cosmos/cosmos-sdk/blob/master/simapp/simd/cmd/root.go#L205) but it's not documented and everyone copies the simd implementation in the sdk.

Also it seems we set minGasPrice to "" and this defaults to 0, which could be considered a bug.

[MikeSofaer]

My chain (Pylons) is primarily a 0-fee chain, it's modeled on free-to-play games, where we want to get users engaged and playing before we start charging them money. Similarly for artists we want them to be able to mint pieces without paying up-front at all. I have other strategies for spam prevention. So I'd like to make sure that 0-fee remains possible, please!

[clevinson]

After discussing on the SDK Sprint Planning call today, the desired behavior we're wanting here is to have:

• server will error if there's an empty value for min-gas-price
• we will document how an app developer can set a default (to avoid all nodes from erroring if they leave it empty)

[robert-zaremba]

Linking a more general solution we discussed for cosmos, and we are proposing to implement in Regen for chain minimum gas price (gov controlled lower bound for validators' minimum_gas_price).

• https://forum.regen.network/t/gov-controlled-min-gas-price/213
• In Protocol Gas Price | Fee #8224 (reply in thread)

[hxrts]

This does raise a question of whether we want this to land in the SDK as a default solution. Any of the min-fee approaches discussed previously would likely supersede this feature. Long-term I think want the fee system to act more like modules where devs elect to add an encapsulated solution that works for their chain. Maybe it's useful to include in the short term though?

[robert-zaremba]

Yes - we were always talking about a need for the short term solution. Maybe it could be a secondary / optional in the future? Nobody is working on dynamic fee mechanism (we need to spec the mechanism which will work with tx prioritization epic). We are only hoping that the Terra story won't repeat with any other chain. Note that it's enough to have a sabotage validator to cause the spam attack.

As we discussed during the calls, we can't follow Ethereum 1.0 examples here, because Ethereum miners have much bigger cost to produce a block than Cosmos validators. And there is not much spam a sabotage miner can cause (max 15 spam tx / sec with aforementioned big mining cost).