Batch posting delayed because of the frequency of messages

[Sneh1999]

Issue

The number of messages to be posted in a batch keeps increasing with each iteration, even if an error occurs that prevents the batch from being posted. This poses a problem for us because, in every iteration, we need to post new transactions to Espresso, which take approximately 10 minutes to verify due to the frequency at which the prover posts HotShot state to the light client contract.

Solution

The design needs to be updated so that, during the initial batch posting attempt, we store the last potential message of a batch. This value should remain unchanged in subsequent iterations, even if new messages are added, until the batch is successfully posted.

Testing

• Add a unit test to test this behaviour
• Run nitro-testnode to make sure end to end tests are working
• Test this in SGX to make sure we didnt break anything

[jbearer]

Note that even with the fix this is going to cause an additional 10 minute lag in batch posting compared to the non-Espresso case. With the fix, this lag should not accumulate over time, so batches are still posted every 30 minute interval. But the transactions in a batch will range from 10-40 minutes old, rather than 0-30. This seems fine but just something to keep in mind when we run tests that this is normal