feat: introducing EvmWiring, a chain-specific configuration

[Wodann]

Experiment to see whether it would be possible to separate optimism and mainnet SpecIds and other types, such as HaltReason.

I'm curious to hear whether any of this is in line with #918

Supercedes #1378 (to allow editing by maintainers)

[Wodann]

@rakita if at any point it is helpful, I'd be happy to upgrade EDR to test the latest changes in our use case 🙂

[rakita]

@rakita if at any point it is helpful, I'd be happy to upgrade EDR to test the latest changes in our use case 🙂

Changes are mostly done and want to merge it as is. EvmBuilder it not great but would work on it in follow up PRs.

        let mut evm = Evm::<EthereumWiring<BenchmarkDB, ()>>::builder()
            .with_spec_id(SpecId::PRAGUE)
            .with_db(BenchmarkDB::new_bytecode(bytecode))
            .with_default_ext_ctx()

with_default_ext_ctx is required to build external ctx, if you build Evm without setting ext_ctx, build will panic.

Try to integrate and we can iterate. Reth has a simpler abstraction that creates Evm behind the trait so integration is easier.

[Wodann]

Awesome; I'll integrate today.

[DaniPopes]

FYI this increases MSRV to 1.81 https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#coreerrorerror

[Wodann]

Awesome; I'll integrate today.

I've been working on integrating the added changes into EDR.

The addition of the type Database and type ExternalContext to EvmWiring have been proving incredibly hard (and maybe impossible) to integrate into our codebase.

We are using references to a dynamic trait object (runtime polymorphic) State and BlockHashRef for the database. As these now need to be added to the EthereumWiring, that's polluting the whole codebase with lifetimes, whereas the EvmWiring is intended to be used as a compile-time constant.

I was able to work around this partially by splitting the EvmWiring into two traits but I'm still running into issues with runtime arguments.

For example:

    let env = Env::boxed(cfg, block, transaction);
    let evm_builder = Evm::builder().with_db(WrapDatabaseRef(DatabaseComponents {
        state,
        block_hash: blockchain,
    }));

    // NOTE: Precompiles don't have access to the external context but are still typed on the `type ExternalContext` due
    // to the `EvmWiring`. This requires duplication of this code into the two branches of the if-else statements below.
    // This seems overly restrictive on the typing.
    let precompiles: HashMap<Address, ContextPrecompile<Wiring<ChainSpecT, _, ()>>> =
        custom_precompiles
            .iter()
            .map(|(address, precompile)| (*address, ContextPrecompile::from(precompile.clone())))
            .collect();

    let result = if let Some(debug_context) = debug_context {
        let mut evm = evm_builder
            .with_external_context(debug_context.data)
            .with_env(env)
            .append_handler_register(debug_context.register_handles_fn)
            .append_handler_register_box(Box::new(move |handler| {
                register_precompiles_handles(handler, precompiles.clone());
            }))
            .build();

        evm.transact_commit()
    } else {
        let mut evm = evm_builder
            .with_env(env)
            .append_handler_register_box(Box::new(move |handler| {
                register_precompiles_handles(handler, precompiles.clone());
            }))
            .build();

        evm.transact_commit()
    }?;

To keep code as reusable as possible, I think it would be beneficial to restrict trait bounds by the smallest amount as possible.

I'm still in the process of adapting these changes, so I'll share more insights as I uncover them.

[rakita]

@Wodann can you show me an example, and we can start with that?

[Wodann]

For multi-chain support, most of our codebase is generalised on the trait ChainSpec (old code). One such example is a trait Block, which exposes information about an Ethereum block. It's variable for the ChainSpec::Transaction and block receipt.

Introducing the EvmWiring would require this trait to also be generic over the Database and Ext, whereas a Block has nothing to do with these types.

Some other examples are:

• a block builder
• errors

For an example of how we use the wiring, see this code. We construct a state using runtime parameters here (old code) and here (new code). This is using immutable references, which would be intertwined with the trait EvmWiring in our codebase.

I still haven't gotten the compiler to accept the code, as we need to construct an EvmWiring from a ChainSpec (trait that doesn't know about Database and ExternalContext. I have a feeling that the only way to get this to work is using:

trait EvmWiring {
  type ChainSpec: ChainSpec;
  type Database: Database;
  type ExternalContext;
}

but I am yet to try that. I'll circle when I've given it a try.

[rakita]

Why would you want to restrict Block to all those generics:

#[auto_impl(Arc)]
pub trait Block<ChainSpecT: EvmSpec>: Debug {

It Looks brittle. I would try with associated types (for Tx) on Block, maybe this is a good path.

[Wodann]

Why would you want to restrict Block to all those generics:

#[auto_impl(Arc)]
pub trait Block<ChainSpecT: EvmSpec>: Debug {

It Looks brittle. I would try with associated types (for Tx) on Block, maybe this is a good path.

Sure, in this case we that might simplify things.

However, there are some places where we need all or large parts of the RuntimeSpec, which is a constrained version (additional trait bounds) of ChainSpec (not the Database and ExternalContext).

For the exact reason you mention, we don't want to pollute our codebase with the ExternalContext and Database associated types, especially since those are not types with a 'static lifetime - in our use case.