[FEATURE] Better logic for prover transaction submission (While I don't check other l1 TX submissions it applies to sequencers if they had same logic) #19710
Description
Problem Statement
At the moment the chain is completely empty. The proofs are created in under 5 minutes for most of the provers, and we still have a lot of provers arriving late too. For any prover to be actually operational at production conditions, even heavy proofs should be under 20 minutes. Right now there is not much of an issue because we have over 20 provers, but imagine the assumption when proof weight increases significantly and our prover numbers drop to a few. Considering all will be around the same speed because there is cost and many other things to optimize, they will probably drop into the same range.
Currently, the prover just sends two transactions at the same time and just waits until the next one. Assuming proofs arrive at the 15 to 20 minute mark, if a spike happens around that time, even though the spike is not high, when prover numbers are low it can cause a prover transaction to miss the necessary window. As some loads on Ethereum take a while, even though they do not cause a huge spike, they can easily keep certain gwei transactions out of blocks for 30 to 60 minutes.
Proposed Solution
For reasons explained above, a logic to monitor and submit a new transaction towards the end of windows as a final attempt at current gas estimations would make provers and the protocol much more resilient.
Example Use Case
No response
Alternative Solutions
We can have full monitoring and have logic trying every 3 to 5 minutes to submit the transaction if it fails, but I do not see the point of building a very complicated structure. I just believe the current way to handle the transaction with two transactions at the same time with a normal estimation and a higher gas fee is not a good way and will cause issues when system under stress.
Additional Context
No response