refactor(blockgas): remove block gas

[tac0turtle]

look into removing blockgas from context and gas service.

It is used in upgrade but i dont see us consuming gas there.

[yihuang]

[feature request] along with removing block gas meter, add BlockGasUsed() to Context, which is filled with the sum of gasUsed of the txs after they are executed, the ethermint feemarket module needs access to that, currently it use ctx.BlockGasMeter().Consumed().

[akaladarshi]

Hey @tac0turtle, Just for clarification when you say removing the BlockGasMeter from context and gas service do you mean replace it with gasMeter or remove it altogether?

[tac0turtle]

the ethermint feemarket module needs access to that

when does this run?

[tac0turtle]

Hey @tac0turtle, Just for clarification when you say removing the BlockGasMeter from context and gas service do you mean replace it with gasMeter or remove it altogether?

gasmeter stays

[yihuang]

the ethermint feemarket module needs access to that

when does this run?

End blocker

[ValarDragon]

Happy to remove the block gas meter!

[yihuang]

another thing to be careful is, it's only safe to remove block gas meter if we check the sum of gas wanted in the process proposal handler, which is only the case when we use the SDK mempool, AFAIK

[alpe]

Removing the Block gas meter from the context would be nice to have a smaller footprint on the modules. Within the SDK it would not be hard as gas is consumed in baseapp.runTx only as far as I saw. But unfortunately, there are other use cases where the Block gas meter is used currently.

• Unique position of a TX in a block wasmd
• fail fast on gasWanted > blockGasLimit ante evmos + ante evmos

I did not look into other projects so there can be more use cases. Nevertheless we may be able to move this forward by providing the same functionality in a different way.
🤔 First step can be a read only Block gas meter decorator provided to the modules (but with a baseapp option to return the legacy one). By this, we should learn about all our Block gas meter users over time that consume gas.
To move the process a bit forward, we can deprecate the BlockGasMeter method and provide a new BlockGasConsumed method to the context to have the wasmd case covered. With this method, evmos and others could calculate the remaining block gas by ConsensusParams.Block.MaxGas - BlockGasConsumed.

I was also wondering if there is any reason to fail so late on block gas. IMHO it makes sense to check gasWanted > remainingBlockGas early in an ante handler or runtx.