Implement a minimum fee mechanism

[zmanian]

This is a prelaunch requirement. I've been part of a few in person discussions so I will document here.

The network needs to have an anti spam mechanism via a minimum fee. The minimum fee will also depend on relative value of the underlying token so it must be adjustable.

There seem to be roughly 3 possible designs.

Non-Consensus minimum fee

• Each validator sets a minimum fee locally in a config file. They reject any tx from the mempool with less than the required fee per gas. This has the implication of requiring checkTx to have depend on a config result. Potentially all nodes should set this value to prevent gossiping spam transactions.

☝️ @zmanian is a fan of this design.

Consensus Minimum fee

• Minimum fees are set in the consensus state via validator voting. This also allows setting new fee tokens. I believe @sunnya97 is a fan of this approach. Requires implementing something similar to governance with automatic parameter setting.

• Algorithmically derived minimum fee. Have the minimum fee rise automatically as capacity is consumed and decrease if capacity is underutilized. Requires adding information about block capacity utilization to state.
  @jaekwon prefers this approach.

[ValarDragon]

I think we should just do the Non-Consensus minimum fee. This seems like it will be the easiest to implement. Ease of implementation makes sense to optimize for, since #postlaunch we want the mempool to sort by fee. (Perhaps using the proposal here: tendermint/tendermint#2147)

[zmanian]

One of the complexities of non-consensus mode is the checktx needs to know if it is being run during Commit or in the mempool.

Apparently this context was removed at some point in the past and it would need to be restored. The effective min fee in Commit should be zero.

[ValarDragon]

An alternative is to run this check in the mempool itself, as that will allow for more of this code to be reused post launch. (We may want the mempool to have a min fee even after we sort by fees)

What would then be needed is an ABCI "priority" function on txs. (This function should not go into consensus) The SDK would return the fee on each message. Then the mempool will check if the return value of the priority is greater than its minimum. We would have to decide if we want the result of this ABCI query to be included in the relevant hashes, I'm leaning towards not having it included.

[cwgoes]

Strongly in favor of non-consensus minimum fee for launch, then considering alternative strategies (including fee-by-voting, fee-by-algorithm, no-minimum with fee-ordered mempool) post-launch.

One of the complexities of non-consensus mode is the checktx needs to know if it is being run during Commit or in the mempool.

It was removed, but this is trivial to add back in, far easier than a consensus minimum fee.

[cwgoes]

Concurred in SDK meeting to implement this next release & test example spam txs!

[alexanderbez]

Would be cool if out of this came a concise easy to use tool to spam!

[zmanian]

Relevant. Some alternate fee mechanisms proposed @vbuterin

zcash/zcash#3473

[ValarDragon]

I'm very in favor of using the style of scheme Vitalik is suggesting, postlaunch. Prelaunch I'm still in favor of just the single min-fee, chosen per node inside of a mempool config.

[cwgoes]

cc @AdityaSripal

[rigelrozanski]

@cwgoes I thought @sunnya97 was going to work on this one?

[cwgoes]

Ah possibly! Perhaps I missed that discussion. @sunnya97?

[ebuchman]

My understanding of the pre-launch scheme is a min_fee parameter in the config file that is only of interest to Gaia (not Tendermint) and which is used to inform validity of txs during CheckTx, but not during DeliverTx.

In other words, agree with Zaki on using Non-Consensus minimum fee option 1.

This option does not require any changes from ABCI or Tendermint