Docs request: what precisely are the current semantics Tendermint applies to gas?

[coriolinus]

I see that in tendermint/abci#57 there was a proposal:

basecoin (or other abci implementation):

on CheckTx, app validates tx, checks sigs, checks fees and gas, checks the account has the money
On success, return gas/fees values to core
If any problem (account doesn't have the fees it promises), return an error
on DeliverTx, app removes 100% of Fees from account regardless of success/fail of app call
App specific logic what to do with them (destroy them? distribute to the validator)
This can be configured by passing a FeeHandler interface into NewBasecoin or a similar approach
plugin decides what to do with gas...

tendermint core:

on receive new tx, tendermint calls CheckTx (as now)
if tx is valid, core remembers the fees/gas associated with it for the consensus round
when voting on a block, reject any block with a total gas over the chain-configured gas limit
when proposing a block, do some algorithm to maximize the fees while staying within the gas limit
(this is a well known NP-problem and we can use some of the approximation algorithms from cs literature)
to limit breakdown of consensus, other nodes will not reject a proposal because they found a better solution

However, that proposal is almost two years old at this point, and there have been at least some modifications, such as removing fees.

I see that in the docs, CheckTx and DeliverTx return GasWanted and GasUsed fields. However, the docs are frustratingly vague for people without an Etherium background. Request docs expansion on the following points:

• What exactly is GasWanted, and how might it be computed? Is it a property of the transaction, of the application state, of some combination thereof?
• What exactly is GasUsed, and how might it be computed? Is it a property of the transaction, of the application state, of some combination thereof?
• What is the relationship between GasWanted and GasUsed?
• Given a single transaction, will the values for GasWanted and GasUsed ever be different in the CheckTx and DeliverTx methods? If yes, why, and when?
• Can an ABCI application function correctly by simply never setting the GasWanted or GasUsed fields? If yes, what is tendermint's behavior in that case?

[ebuchman]

Thanks for raising this and apologies for the confusion. The GasWanted and GasUsed fields are currently unused by Tendermint. You can do whatever you like with them.

Can an ABCI application function correctly by simply never setting the GasWanted or GasUsed fields? If yes, what is tendermint's behavior in that case?

Resounding yes. Tendermint ignores them.

The intention is for them to capture some sense of "wanted / willing-to-pay-for" and "actually used" resources in the application. In general, CheckTx can report on the wanted, but not the actually used, because it may not know the full extent of the computation that takes place in a DeliverTx in the block. DeliverTx should report correctly on both.

We have some open issues for how we want to start taking better advantage of app-level information about tx priority in the mempool: #1861, #2127, #2147

[ebuchman]

Here's a rough overview of how we want to actually use the GasWanted and GasUsed fields in Tendermint: #2310

[ebuchman]

This is now documented properly in the ABCI spec now refactored to hopefully be more clear, with the links to the relevant issues: https://github.com/tendermint/tendermint/blob/develop/docs/spec/abci/apps.md#transaction-results

Will be merged in #2350. Docs will be updated when #2310 is implemented.

I'll close the issue for now, but please let us know if you have more feedback on how the docs around this can be improved. Thanks!