Parallel transaction execution using Block-Level Access Lists

[bhartnett]

Depends on EIP-7928 being implemented first which is being tracked here: #3735

The main benefit of BALs is that they enable deterministic transaction parallelization because the transaction dependencies and storage access locations are known up front.

The areas that we may be able to parallelize to improve performance include:

• IO - All state read by the block can be pre-fetched in parallel using the account and storage locations contained in the BAL.
• Execution - Transactions can be executed in parallel regardless of dependencies between them using the post execution values in the BAL.
• Stateroot computation - We should in theory be able to parallelize the stateroot computation to some extent after applying the state updates to the database.

To-Do:

• Optimize single threaded performance - It makes sense to start by profiling the existing code before adding in multi-threaded execution.
• Optimize IO - Can start by using the RocksDb multiGet API to prefetch all the block state and then also using multiple threads to fetch in parallel (one task per transaction).
• Implement parallel transaction execution using the TaskPool threadpool scheduler. One task per transaction.
• Implement parallel stateroot computation.

[bhartnett]

Multi-threading is not very well supported in the current code base so we may need to do some groundwork to add better support for concurrency. For example the Aristo database code makes extensive use of LRU caches which are not thread safe and therefore even reading from the database across multiple threads will not work.

Note that some of the nim-rocksdb library is thread safe, notably the main RocksDbRef type used for reading and writing directly to the database.