txpool is stuck due to heavy transaction

[YoshihitoAso]

Is your feature request related to a problem? Please describe.

If there is a transaction that takes a long time to process and the transaction GasLimit is set to a large value, the following error will occur and the transaction will not be included in the block.

INFO [06-21|11:39:50.021] BFT: block proposal committed            author=0x47A847fbDF801154253593851aC9A2E775323534 hash=807ae2..2e9fc7 number=20427
INFO [06-21|11:39:50.025] Imported new chain segment               blocks=1 txs=0  mgas=0.000  elapsed=6.187ms     mgasps=0.000   number=20427 hash=807ae2..2e9fc7 dirty=4.77MiB
INFO [06-21|11:39:50.025] QBFT: handle final committed             address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 state=Committed
INFO [06-21|11:39:50.027] QBFT: initialize new round               address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 target.round=0 lastProposal.number=20427 lastProposal.hash=807ae2..2e9fc7
INFO [06-21|11:39:50.027] QBFT: changed state                      address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20428 old.state=Committed        new.state="Accept request"
INFO [06-21|11:39:50.028] QBFT: start new round                    address=0x47A847fbDF801154253593851aC9A2E775323534 old.round=0  old.sequence=20427 old.state=Committed        old.proposer=0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 next.round=0 next.seq=20428 next.proposer=0x35D56A7515e824BE4122f033D60063D035573a0c next.valSet="[0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 0x35D56A7515e824BE4122f033D60063D035573a0c 0x47A847fbDF801154253593851aC9A2E775323534 0xc25d04978fd86ee604FeB88f3C635D555eB6D42D]" next.size=4 next.IsProposer=false
INFO [06-21|11:39:50.044] Aborting transaction processing due to 'commitInterruptNewHead', elapsed time=954.247024ms
INFO [06-21|11:39:50.047] Submitted transaction                    hash=0x362d014bc51e7b344378d03fed12925c8c76caddf280515114410ae25fdb00e1 from=0xA2ab4ae7e48A0f6AFd66B4e9d03fc605aB1de23C nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.065] Commit new mining work                   number=20428 sealhash=96200e..62b131 uncles=0 txs=0  gas=0          fees=0 elapsed=18.269ms
INFO [06-21|11:39:50.118] Setting new local account                address=0xeDeA99399f361aE7abb268a9cCb794922d64AE74
INFO [06-21|11:39:50.133] Submitted transaction                    hash=0xb00218488412d79957b929c1545e5be3579716d51f6b058a30eb91c02a9d7338 from=0xeDeA99399f361aE7abb268a9cCb794922d64AE74 nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.161] Setting new local account                address=0xefB808a0D5730cC3622023cB07F5D5555dB796C7

As a result, the following situations can occur.

• Transactions are stored in txpool's executable transaction.
• Validator tries to process txpool with FIFO.
• A transaction with a high processing load becomes an error(revert).
• An invalid Tx gets stuck and subsequent Tx's are not processed. Since executable transactions do not have a time limit, they will remain in this state until txpool is cleared.

When such invalid Tx is stuck, it is necessary to manually clear the txpool on the Validator side, but we would like to eliminate such manual operation.

Describe the solution you'd like

We are planning to incorporate NewPayloadTimeout introduced in geth.
Ref: ethereum/go-ethereum#25407

[YoshihitoAso]

There is currently no effective solution to this problem. An immediate workaround is likely to be to set globalslots on the validator to adjust the size of pending transactions. However, the specific size needs to be carefully decided and discussed with ibet consortium members.

[YoshihitoAso]

We are planning to incorporate NewPayloadTimeout introduced in geth.
Ref: ethereum/go-ethereum#25407