core: prevent negative fee during RPC calls

[PlasmaPower]

During RPC calls such as eth_call and eth_estimateGas, st.evm.Config.NoBaseFee is set which allows the gas price to be below the base fee. This results the tip being negative, and balance being subtracted from the coinbase instead of added to it, which results in a potentially negative coinbase balance interestingly. This can't happen during normal chain processing as outside of RPC calls the gas price is required to be at least the base fee, as NoBaseFee is false.

One alternative I considered is changing the if statement above this change from if rules.IsLondon { to if rules.IsLondon && !st.evm.Config.NoBaseFee {. However, that seems less intuitively similar to the treatment of the base fee elsewhere. The smart contracts querying the base fee in an RPC call will still get a non-zero balance, for instance. In my opinion, a better mental model of NoBaseFee is that it simply allows setting the gas price below the base fee, not entirely eliminating the base fee. This PR intuitively fits into that by only giving the coinbase a tip when the gas price is higher than the base fee. The user can also match real EVM behavior by simply setting the gas price to the base fee or above. However, I'd be happy to change this PR to instead give the entire gas charge to the coinbase if that's desired.

[lightclient]

@PlasmaPower just checking if you have further thoughts on this. If not, I will update this PR so that it checks whether feeCap < baseFee check is executed when feeCap is non-zero and NoBaseFee is set. Please also feel free to make this change yourself.

[PlasmaPower]

My only concern there would be if someone's gas estimating or eth_calling against the current base fee, but it rises in the next block and their gas estimation therefore fails. I could imagine that could breaking some existing applications, but if the risk is deemed low enough, I'd be happy to change it.

[lightclient]

@PlasmaPower I'm not sure I follow? It is recommended to set feeCap to be twice as large as the previous baseFee so that it won't become invalid in the next block.

[PlasmaPower]

I understand, but misbehaving clients might attempt an eth_call with the previous block's basefee for instance.

[lightclient]

Are you aware of any applications with this behavior? I think this type of behavior has been discouraged from the beginning so I don't see an issue with impacting applications that set feeCap as the previous baseFee.

[PlasmaPower]

I was going to go implement that change, but it seems it already works that way:

go-ethereum/core/state_transition.go

Line 238 in e394d01

if !st.evm.Config.NoBaseFee || st.gasFeeCap.BitLen() > 0 || st.gasTipCap.BitLen() > 0 {

If gasFeeCap or gasTipCap is non-zero, the fee cap is required to be above the base fee.

[lightclient]

Hi @PlasmaPower, I made a small modification to your change. They should have the same effect, but I find that NoBaseFee && gasFeeCap == 0 && gasTipCap is a bit more explicit and helpful for understanding. PTAL and let me know if you feel this is acceptable.

[PlasmaPower]

Looks good to me :)

[holiman]

LGTM