Investigate Geth/Besu different behaviors re. tx retainment in txpool

[julien-marchand]

Description

When:

• a user creates a transaction (A) without having the balance
• or a user creates a batch of transactions and one (A) of the future ones (not direct nonce) doesn't have the balance to be executed
  Then:
• Besu keeps it as it's a transient problem, but Geth discards it
• If the user tries to send a new transaction (B), it will be accepted by Geth (and shown on the explorer), but will be rejected by Besu if the gas price isn't above the previous gas price (plus margin) as Besu has already a transaction (A) for this nonce

It is extra painful because (A) does not appear in explorers, will (B) does.
RPC providers may only run Besu, so the fix needs to be included properly in Besu. This problem will be exacerbated as we push Besu into infra providers and dapps without Geth.

Acceptance criteria

• Review the solution to use the tx-pool-min-score, and investigate edge cases around transaction retention, tx propagation, mining, and sharing to explorers
• If it doesn't work, propose a new solution, potentially:
  • Drop transactions in Besu if they reach a not-enough-balance state at a given point (maybe when the previous nonce was mined)
  • Accept transactions in the RPC and P2P (regardless of the replacement penalty) if and only if the existing one is in not-enough-balance. Investigate edge cases around DDoS of the RPC node.

[fab-10]

Drop transactions in Besu if they reach a not-enough-balance state at a given point (maybe when the previous nonce was mined)

this approach makes sense, adding a periodical sweep of the txpool to remove txs that are unlikely to be included in a block.
Currently Besu has not this periodical sweep feature, but it seems a good feature to add.

Accept transactions in the RPC (regardless of the replacement penalty) if and only if the existing one is in not-enough-balance. Investigate edge cases around DDoS of the RPC node.

This requires some more reasoning, since my understanding is that if also we accept the replacement tx in the RPC node, that is not enough, because it will always be propagated to other nodes via P2P, where it will not be accepted.

[julien-marchand]

this approach makes sense, adding a periodical sweep of the txpool to remove txs that are unlikely to be included in a block.
Currently Besu has not this periodical sweep feature, but it seems a good feature to add.

Yes it could have multiple triggers, either:

• periodic
• periodic AND when the previous nonce is mined (best in terms of UX IMO)
• when the previous nonce is mined AND when the account balance is impacted (should be enough but the balance trigger might be complicated)

This requires some more reasoning, since my understanding is that if also we accept the replacement tx in the RPC node, that is not enough, because it will always be propagated to other nodes via P2P, where it will not be accepted.

Is there anything preventing us from doing that at the rpc AND p2P layer?