feat: abstraction to allow customized EVMs

[zobront]

Currently kona-executor exposes the revm handler in order to customize block execution. However, larger customizations of the EVM are not possible.

An abstraction to perform these deeper customizations already exists in reth/revm, where:

• when reth executes, its BasicBlockExecutor contains a strategy for execution
• in order to execute() (link), it calls apply_pre_execution_changes(), execute_transactions(), apply_post_execution_changes(), and finish() on the strategy.
• reth includes the OpExecutionStrategy which is a good example of this implementation.
• All strategies contain an evm_config which must implement ConfigureEvm.

This evm_config is what allows customization. Specifically for Kona's context, three of the functions it implements replace some of the hardcoded actions in Kona:

• fill_cfg_env() replaces self.evm_cfg_env()
• fill_block_env() replaces Self::prepare_block_env()
• fill_tx_env() replaces Self::prepare_tx_env()

I believe the best option to allow Kona more flexibility in execution is to refactor Executor to rely on a struct implementing the ConfigureEvm trait in order to perform the above actions. For "normal" Kona, we can break the existing functions into a new type that implements the ConfigureEvm trait. For other customized chains like Odyssey, we can simply inherit whatever ConfigureEvm struct they are passing to reth for execution.

@clabby You had mentioned implementing the traits in alloy / op-alloy. I assume this accomplishes what you wanted, or was there a reason you prefer it to exist there?

Let's talk through this and make sure it's the right strategy before touching any code. I'm available async or for a live call on Monday if that's easier. Thanks guys.

[clabby]

I believe the best option to allow Kona more flexibility in execution is to refactor Executor to rely on a struct implementing the ConfigureEvm trait in order to perform the above actions. For "normal" Kona, we can break the existing functions into a new type that implements the ConfigureEvm trait. For other customized chains like Odyssey, we can simply inherit whatever ConfigureEvm struct they are passing to reth for execution.

Yeah, this sounds like a nice minimal diff approach. Though if we have the time / are willing to make the effort, I think it would be great if we could upstream the traits that reth / revm are using for this configurability to alloy and/or op-alloy so that we can all operate on a common set of abstractions. In the medium-longer term, that buys us quite a bit - modifications to the OP Stack would only have to make their execution layer changes in one place and get kona + reth compatibility in one go.

@clabby You had mentioned implementing the traits in alloy / op-alloy. I assume this accomplishes what you wanted, or was there a reason you prefer it to exist there?

Yeah I'd prefer if it wasn't in kona or reth. A common set of executor abstractions is pretty desirable.

---

All that said, let me know your appetite for making that sort of change. I'm open to taking a more minimal approach at first, but would def prefer if we could work w/ @mattsse et. co on standardizing the interface and placing it somewhere that we can all use.

[clabby]

Chatted about this a bit more with @mattsse today. Looking like the effort on creating a unified interface has picked back up, issue should be able to be revived soon.

[clabby]

Adding M-blocked meta: blocked , we're waiting on ithacaxyz/evm to be open sourced. cc @mattsse

Some more info on why this is important to us:

1. Having a shared executor interface between kona and op-reth will lower our maintenance burden for adding features to the EL a ton.
2. Lowers implementation disparity risk, deduplicating the EL STF code between op-reth and kona
3. Allows for easy drop-ins of EL STF diffs, such as Odyssey's, to kona.