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]

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.