Refund Unused Fee

[AdityaSripal]

Summary

Currently, the SDK tx only allows a user to specify the maximum gas for a tx and the fee they're willing to pay. This creates an implied gasPrice. However, the fee gets deducted in its totality regardless of what the eventual gas ends up being. It would be ideal if the remainder of the fee gets refunded in cases where the consumed gas is less than the specified limit.

Problem Definition

• Users overpay on fees if they create a higher than necessary gas limit

Proposal

Solving this would require some form of post-processing of the transaction. We could still deduct the entire fee in the antehandler (in order to ensure beforehand that the user has enough fees to pay for their gas limit), however after the tx is complete, we should refund the fee like so:

distributionPool.Send(tx.feePayer, tx.Fee * (1 - ctx.GasConsumed()/tx.gasLimit))

The post processing can be done either as a decorator that wraps the entire msg processing, or as a separate post-processing function.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[fedekunze]

We implemented this on Ethermint

https://github.com/tharsis/ethermint/blob/main/x/evm/keeper/state_transition.go#L274

[tac0turtle]

can we close this in favor of #2150

[aaronc]

I think ante decorators should wrap all of runMsgs rather than just pre-processing. That seems like the most obvious architecture to generally solve this class of problems.

[AdityaSripal]

I think ante decorators should wrap all of runMsgs rather than just pre-processing. That seems like the most obvious architecture to generally solve this class of problems.

I'm in favor of the approach if the Regen team approves as well. I know I along with the initial SDK team decided to go with a less powerful approach, but as SDK has evolved I think it makes sense to enable this feature and potentially others.

[AdityaSripal]

One issue to note that the SDK team initially considered when making our decision was how CheckTx should change in light of this.

Originally the antehandler was purely doing pre-processing of a transaction, and made basic tx-level checks on validity before handlers did message-specific checks and state updates.

So CheckTx naturally just ran the antehandler and skipped message execution which happened after the antehandler was done executing.

In the case where antedecorators wrap the entire message processing, it becomes less clear what to do for CheckTx.

Should CheckTx run the entire transaction along with message processing?

We could make the last "antedecorator" implement the msg routing currently in runTx, and here we could skip the message processing if this is a (Re)CheckTx. However, this would require that all antedecorators skip post-processing on (Re)CheckTx as well.

[clevinson]

Closing in favor of #2150

[aaronc]

One issue to note that the SDK team initially considered when making our decision was how CheckTx should change in light of this.

Originally the antehandler was purely doing pre-processing of a transaction, and made basic tx-level checks on validity before handlers did message-specific checks and state updates.

So CheckTx naturally just ran the antehandler and skipped message execution which happened after the antehandler was done executing.

In the case where antedecorators wrap the entire message processing, it becomes less clear what to do for CheckTx.

Should CheckTx run the entire transaction along with message processing?

We could make the last "antedecorator" implement the msg routing currently in runTx, and here we could skip the message processing if this is a (Re)CheckTx. However, this would require that all antedecorators skip post-processing on (Re)CheckTx as well.

I think this makes sense. One thought I had was to have separate Check and Deliver methods in the ante-decorators so that it is more clear that there is a distinction. All ante-decorators would probably need to skip post-processing if we are not running the whole transaction in CheckTx, although running all the messages may not be a bad idea.