allow configuration of baseFeePerGas

[wei3erHase]

each time evm_mine is called on a fork, since only 1 tx has been made in that block, it makes the future block to have a minor baseFee than the one before. When running calculations that depend on that baseFee, advancing blocks seems to disrupt the calculation, and be run with a very low baseFee that cannot be set

context: baseFee of future blocks cannot be predicted beforehand, so this behaviour is not unexpected

problem: making baseFee variable (and unpredictable) between blocks can disrupt all tx gas settings and calculations, creating an unpredictable environment for developers that rely on those settings

proposed solution: keep baseFee constant (despite having very light blocks), or either have a method to set a baseFee on the fork such as evm_setBaseFee, allowing the dev to have access to a predictable gas setting on a certain block

[gnidan]

Thanks for opening this! Interesting question. What do you think of evm_mine taking a parameter (or having a dedicated method to set the baseFee?). We could add a baseFee parameter that could take either a number or "auto", perhaps.

Would love to know more about your use case... you mention that Ganache's behavior disrupts your calculations; could you describe what you're doing in a bit more detail? Might be helpful for us to consider the pros and cons here.

Thanks!

[wei3erHase]

hi @gnidan, let me onboard you in our case scenario.
we're using ganache as a part of a bot, that has to evaluate a transaction in the future, and if it works, sign and send that transaction

so let's say we're in block 990, and since the process takes a little bit of time, we want to know if in block 1000 a transaction will be profitable. so we fork 990, advance 10 blocks, and run our transaction.
when this forked transaction has passed, let's say block 997, we evaluate the results, set a gas configuration, and send it to be included in block 1000.

notice: the results of the transaction depend on the baseFee (because the tx is payed for its gas used * baseFee)

the problem here, as pointed above, is that the baseFee of block 1000 has lowered a lot in the fork, since 10 blocks have passed without any transactions being included on it. given that the baseFee of the fork was really low, the reward is really low, and when setting the gas configuration, the result can give a baseFee lower than the actual block one.

it's a tricky one, because, we will never know the baseFee of the future blocks, but i believe it would make some sense for the fork, not to vary, since in other case, it is always going to go very down quickly, resulting in unexpected behaviour for the user that may not be actually aware of this variation

[kevinbluer]

Many thanks for the explanation @wei3erHase, we've added it to our backlog and we'll address it after the 7.0 stable release.