Prover will accept too many request in short amount of time when it is still processing block info

[v54dt]

Prover only check TTKOj if it is sufficient to accept proof request from a proposer when the prover is not generating proof.

When a prover just restart, it will start process block from last verified block after a stable initialize (L2 execution engine sync to latest block). The last verified block may left behind 1k or 2k block from the latest block. So when the prover is still checking who is the assigned prover from the last verified block to the latest block, meanwhile the prover can be assigned as a prover of a newly proposed block.
The speed of the prover checking each block's prover info may deteriorate when receiving lots of proof requests from many proposers. The priority of checking the prover's TTKOj amount and answering the proposer request is much higher than the prover checking the block info. It may dragging the prover to catch up to latest block.

I run two provers on alpha-5. One is a public prover using Alchemy RPC endpoint. Another is a private prover with local sepolia node. The private one is fine. The public one `s prover process block info will lags behind the latest block (it still sync to latest block) due to too many proof request from market. Prover will not start generating proof until it catch up to a block which is assigned to it. It may seems that the prover's ttkoj get drained. And in my case if the proof is slow at processing block info then it can't start proving and submit in time. My avg proof time is 6m30s.

My solution is to stop the prover to accept request, all the followings works:

1. block the port from firewall
2. set rate limit on public endpoint
3. withdraw TTKOj manually from L1 taiko contract if node need restart

[davidtaikocha]

Plz try alpha-6 later on :)