About how to run the txs parallel to warm the storage when executing a block

[yutianwu]

Hi, we have been working on enhancing the live sync performance for opBNB. One of our strategies is to warm up the storage by executing block transactions in parallel during block insertion, similar to our approach in opBNB.

We aim to implement this in a simple manner, but we have encountered some problems.

One issue is that the State we use to execute the block in the executor can't be shared across threads like in opBNB.

pub struct State<DB> {
    pub cache: CacheState,
    pub database: DB,
   ...
}

If the storage fetched from the database to cache or database can be shared across the threads, we can increase performance by executing the transactions in parallel to warm up the cache. But CacheState or DB are not designed to do so. However, to change this would involve a lot of work.

Then we decided to execute the transactions in parallel in the executor, but we encountered another issue.

Since DB does not implement the Clone trait and there are many traits in the executor and provider, it is very difficult to handle concurrency due to the constraints or features of Rust. We need a dedicated design to handle concurrency effectively.

Overall, we want to help to improve the performance of the live syncing but we encountered some issues due to the lack of insights of the design and the constraints of the Rust language itself.

Can you give us some suggestions on this or we can work out a design for this to achieve the 1 giga gas goal together. Thanks for your reply~

[mattsse]

hey @yutianwu thanks for bringing this up.

this is indeed not trivial atm, but we could make this possible.
since the evm operates on revm::Database we need an implementation of this that can handle external updates.

in the most primitive form this would be an Arc<Rwlock> over storage but we can likely come up with something that's a bit smarter

as you mentioned, the biggest limitation rn is that DB input is not clone.
I need to think about this a bit and will get back to you.

we likely need a new executor impl

reth/crates/ethereum/evm/src/execute.rs

Lines 353 to 369 in 892d5dd

	impl<EvmConfig, DB> Executor<DB> for EthBlockExecutor<EvmConfig, DB>
	where
	EvmConfig: ConfigureEvm,
	DB: Database<Error = ProviderError>,
	{
	type Input<'a> = BlockExecutionInput<'a, BlockWithSenders>;
	type Output = BlockExecutionOutput<Receipt>;
	type Error = BlockExecutionError;
	/// Executes the block and commits the state changes.
	///
	/// Returns the receipts of the transactions in the block.
	///
	/// Returns an error if the block could not be executed or failed verification.
	///
	/// State changes are committed to the database.
	fn execute(mut self, input: Self::Input<'_>) -> Result<Self::Output, Self::Error> {

and then a way to wrap the given Database

[yutianwu]

That's great, thanks for your reply. Hope we can align on the design so I can move on to the implementation.