Force tx replacement price bump to zero when zero base fee market is configured

[fab-10]

PR description

This PR allows to replace txs on zero base fee markets, or on gas price network, where the txs have gas price set to zero (with min-gas-price=0).

To achieve that we force the tx-pool-price-bump=0 when the zeroBaseFee:true genesis option is present, or when min-gas-price=0 and tx-pool-price-bump option is not set.
But this was not enough, since the transaction replacement rules were forcing the new price to be strictly greater than the price bump, that in my opinion is not intuitive, since for example if your existing tx has a gas price of 100, and the price bump is 10%, then we should accept a valid replacement a tx with a gas price of 110, and not 111 as it was before.
So the other change is to accept, as valid replacement, tx with a gas price greater than or equal to the price bump. This make also the tx-pool-price-bump=0 case more intuitive, since you can replace a tx without increasing the gas price.

doc-change-required to explain that if zeroBaseFee:true in the genesis, then tx-pool-price-bump=0 is forced internally, and any attempt to specify a value for it results in an error, and that if you set min-gas-price=0 then tx-pool-price-bump=0 is forced internally, unless you specifically set it to a different value.

Fixed Issue(s)

fixes #6043

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I thought about the changelog and included a changelog update if required.
• If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[matthew1001]

Is this from another PR? It doesn't seem related to the price-bump behaviour.

[fab-10]

removed, this is not related to this PR

[matthew1001]

Does this mean that you need to be on the london fork in order to get the new behaviour? Could it be made to work in the same way for --min-gas-price=0 for users pre-london?

[fab-10]

I thought about that, but setting --min-gas-price=0 does not necessarily imply that it is a zero-gas-price network (actually also in zeroBaseFee network, the maxGasPrice could be > 0).

So what if we introduce a specific option, that acts like a profile, that state clearly that we want a gas free network, for example --gas-free? that has the effect of setting sound values for other options like the min-gas-price and the tx-pool-price-bump, instead of trying to deduce the intent of the network from single options.

what do you think of this approach?

[matthew1001]

In principle I agree @fab-10. However, I do have a couple of concerns about introducing it under this PR:

1. Most people are probably using --min-gas-price=0 and/or zeroBaseFee: true to create what they think of as a gas free network. I agree it's not strictly gas free - but it probably means that defaulting --tx-pool-price-bump to 0 if you're using one/both of those settings is what most people would expect. They can after all set --tx-pool-price-bump= (num > 0) if they don't want it
2. I think if we had a --gas-free option people would have additional expectations if they set it - not just a default price bump of 0. For example, would allocating initial funds to accounts be valid if --gas-free was set? Would setting a transaction with a gasPrice>0 be allowed?

So I agree that --gas-free would be a really useful option. But I think it's probably worth separate discussion & PR to introduce it.

[fab-10]

Ok I see your point about min-gas-price and will implement your suggestion.

And let's continue the discussion about a gas-free profile, and all the feature that it should enable separately.

[matthew1001]

Again this seems to be unrelated to this PR?

[fab-10]

I put this here since, I am in the process of refactoring how we manage the option, and so when I took some, I also take the opportunity to iterate on it, in this case it was the merging of (un)stable options in a single place.

[matthew1001]

@fab-10 I've pulled and built this branch and run a 5-node QBFT chain. The transaction replacement works just as you'd expect - replacement transactions are accepted for any un-mined transaction. Thanks, I think this will be really useful for a lot of users.

I've added a couple of specific comments in the PR review.

[matthew1001]

Re. docs updates, I think https://besu.hyperledger.org/public-networks/concepts/transactions/pool is the main page that would need updating for this PR, particularly the line You can replace a pending transaction with a transaction that has the same sender and nonce but a higher gas price. which would need a mention of the behaviour if zeroBaseFee is true.

[matthew1001]

Happy approving this based on the discussion. I'm OK with --min-gas-price=0 not defaulting to --tx-pool-price-bump=0 as long as if you do set --tx-pool-price-bump=0 then it's honoured.

[matthew1001]

Happy approving this based on the discussion. I'm OK with --min-gas-price=0 not defaulting to --tx-pool-price-bump=0 as long as if you do set --tx-pool-price-bump=0 then it's honoured.

Just realised that you've updated it to set price bump when --min-gas-price=0 is set :)

[fab-10]

Just realised that you've updated it to set price bump when --min-gas-price=0 is set :)

yes, unless you specifically set a price bump > 0, the it is internally set to 0 when --min-gas-price=0, since as you reported, this should be the most common setup.