feat: introduce evm config trait

[mattsse]

closes #6180

[onbjerg]

do we dedupe with

reth/crates/storage/provider/src/traits/executor.rs

Line 21 in 2a5efb2

pub trait BlockExecutor {

eventually?

[Rjected]

yep, actually I think I'll move this to a new crate that reth-provider and node-api will both depend on, instead of including this (and relevant types) in node-api. Mainly to avoid circular dependencies, and avoid making node-api gigantic

[Rjected]

actually, hmm, need to think more about this, this might not work

[Rjected]

Thinking we can get rid of potential reth-provider dependency issues by making the error type an associated type on BlockExecutor.

[Rjected]

final challenge w.r.t. the BlockExecutor trait: BundleStateWithReceipts, part of the BlockExecutor trait, is currently in reth-provider and has a method write_to_db. This pulls in methods from reth-db (for writing) and pulls in the reth-provider types StateChanges and StateReverts. These types wrap corresponding revm types and implement a write_to_db method.

Two potential solutions:

• We could move the non-db-related BundleStateWithReceipts methods to node-api, and wrap it, similar to StateChanges and StateReverts.
• Create provider traits responsible for reading and writing these data structures. For example, BlockWriter was created to replace the same methods in Block: refactor: add BlockWriter and BlockExecutionWriter  #3384

Wrapping is easy but the trait seems more idiomatic, so I'm proposing we create a trait that can write BundleStateWithReceipts, StateChanges, and StateReverts

[onbjerg]

I'd lean towards proposal 2 as well since it is the approach we are doing for other things

[Rjected]

Defining BlockExecutor in node-api for this purpose:

trait EvmConfig {
    /// the executor type
    type Executor: BlockExecutor;
    
    /// returns the executor with the installed db
    fn evm(&self, db: impl Database) -> Self::Executor;
}

has been scoped out for a few reasons:

1. EvmProcessor has a lifetime, which means using BlockExecutor as a bound on an associated type would require that associated type to be a GAT.
2. The alternative, returning EvmProcessor<'static> would require the DB to be 'static, which is basically never true.

The idea to have take_output_state consume self was proposed in #6568, but is not feasible, unless we want to run into the above problems with GATs and object safety because ExecutorFactory returns a Box<dyn PrunableBlockExecutor>, which we can't turn into an owned value

Where are we now?

Now we're focusing on a trait like this:

/// Trait for configuring the EVM for executing full blocks.
pub trait EvmConfig {
    /// Returns new EVM builder
    fn evm(&self) -> EvmBuilder<'static, SetGenericStage, (), EmptyDB> {
        Default::default()
    }
}

Because we're no longer worrying about defining BlockExecutor in node-api, the Error associated type can be removed.

[mattsse]

we need them to be stateful, so we can capture additional state for precompiles etc.

[onbjerg]

small nits

[mattsse]

This should unblock us.

then we can figure out how to make the blockexecutor work.

feel free to close this PR and submit it as your own, can't approve myself.

[mattsse]

I'd like a few more docs here wrt what the responsibilities of the caller are: env config

[Rjected]

ah forgot to push these changes before merging, will add in another PR

[mattsse]

we can add one more fn that also accepts the Handler type as arg

[Rjected]

@mattsse handler method is blocked on bluealloy/revm#1124 - going to merge this, so we can work on the handler method and evm processor / executor factory refactor separately