Fix for world state root mismatch after parallel preprocessing with zero block reward

[mirgee]

This PR fixes a bug in the implementation of the parallel block processor, leading to frequent world state root mismatches during block persistence, similar to #7844.

When the block reward is zero and the mining beneficiary account doesn't exist yet, if the parallel preprocessing finishes in time to be applied, the resulting world state differs from the one produced by the sequential transaction processing, because, during application of the transaction processing result, parallel transaction processor creates the mining beneficiary address, whereas plain sequential processing, at least with clearEmptyAccounts on, does not, leading to mismatch between world states computed during block creation and parallelized block processing.

This PR also contains an integration test covering this scenario. The test fails without the fix and passes with it.

A complete fix would probably account for the value of clearEmptyAccounts in parallel transaction processor, but this flag seems to be in place for legacy purposes, so I am not sure it is worth further code change.

It is quite possible that this is not the only discrepancy between parallel and sequential processing leading to world state root mismatches.

This PR has been contributed on behalf of Absa Group Ltd.

[matkt]

will take a look thanks

[matkt]

Thans for that it's really a good catch and I think it can clearly explain some issues

I noticed that the call to the constructor of ParallelTransactionPreprocessing was moved to the constructor of MainnetParallelBlockProcessor. This change creates the instance only once when the node starts for each specific fork, rather than per block. Why I created a new one for each block before it"s because of the ParallelizedConcurrentTransactionProcessor and more for parallelizedTransactionContextByLocation map

This map is saving the result of each background transaction execution of the block but if you have the same instance for each block you can have some transaction execution for the block before and it can create inconsistency

For example, consider block 5 with transactions tx0, tx1, and tx2:

• Background Processing: Transactions tx0, tx1, and tx2 start executing in the background.
• Sequential Processing: The sequential processing begins. However, due to timing, the ParallelizedConcurrentTransactionProcessor might retrieve the result for tx2 and not for tx0 and tx1 because the sequential process reached tx0 and tx1 before their background results were available.
• Residual Data: At the end of block 5, results for tx0 and tx1 remain in the map.
• Then, when block 6 (with tx0', tx1', and tx2') is processed, the system detects the results from block 5 (for tx0 and tx1) and applies them to the world state, leading to an inconsistency.

It is an important modification ?

A complete fix would probably account for the value of clearEmptyAccounts in parallel transaction processor, but this flag seems to be in place for legacy purposes, so I am not sure it is worth further code change.

It will be nice to manage it if we want to do a fullsync or if we have a configuration that take care of that.

[mirgee]

@matkt Good point regarding ParallelizedConcurrentTransactionProcessor, that was an unnecessary leftover. Both that and clearEmptyAccounts should be addressed now.