How to deal with fees/gas in tendermint consensus?

[ethanfrey]

A good consensus algorithm needs a way to prioritize multiple transactions, when there is more than a trivial level of transactions.

In order to do this well, the tendermint core will need to be aware of the fees and gas associated with a given transaction. There are two general ideas how to do this:

1. We no longer broadcast arbitrary bytes, but a special format the core can validate tx, verify sigs, parse the fees and gas, etc.
2. Update check_tx so that abci app validates the tx in it's own way, but then returns the fees/gas of any valid transaction to the core, so it can use that for routing

After some discussion, @jaekwon and me decided that the second approach was more flexible. We could implement this base logic in basecoin, and people could write plugins to just take advantage of this existing logic. The other approach is a slippery slope, adding more and more logic into tendermint core, until it is no longer a general purpose consensus engine.

The proposal is to make the following changes:

abci interface:

• CheckTx returns two more fields, fees and gas
• These fields are optional. If an app doesn't return them, tendermint core will use some defaults
• Maybe define new error types for validation?

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

Question from Jae, how do you configure the gas limit? If it is different between nodes, this will quickly lead to a breakdown in consensus. Changing it is analogous to changing the maximum blocksize in bitcoin. In other words, quite easy 😉

As a first step, the gas limit per block can be set inside the genesis block to ensure consistency.

Midterm, some yet-to-be-invented, on-chain governance mechanism can provide a way that validators could vote on the changes. If a >2/3 majority approves a new gas limit, all nodes could update to that limit without breaking consensus.

Implementing this would be a breaking change to the abci interface, and should be rolled out as a minor release. Idea is targetting 0.9.0, along with the abci_proof enhancements. To break every abci app implementation again 😄 With luck, this could be early February 🤞

[rigelrozanski]

Updates on this issue? I'm guessing this didn't make it in 0.9.0... Make good sense to utilize CheckTx as you've mentioned here. How is Tendermint core going to calculate the actual amount of gas being used? Has this been investigated.

[ethanfrey]

This needs to be well specified with bucky and jae before working on it.

Important part that affects both the apps and the core and we need to spend some time architecting it well. And there is no time these days.... hopefully next week

[adrianbrink]

@rigelrozanski I guess that tendermint core does not care how much gas is used. It just passes it on to the app.

[ethanfrey]

@jaekwon @ebuchman This was heavily discussed in the retreat. Can you add your notes here and make this a clear set of requirements to the abci interface. We can even add these fields before we honor them in tendermint core.

[Ivshti]

Once this is finalized, how would it affect tendermint itself? As far as i can see, there's no particular ordering mechanism in tendermint/mempool/mempool.go implemented at the moment

Is there a reference implementation at the moment?