Can we query optimism-specific transactions?

[Wodann]

Definition of Done

• The ability to have in-memory representations of Optimism-specific transaction types
• Answer the question: Can we have optimism and non-optimism transactions side-by-side in a single provider class?

[Wodann]

revm (sha: 1edfeb6) has the following variations when the optimism feature flag is enabled:

• Optimism introduces 4 new gas cost tables (in hardforks bedrock, regolith, canyon, and ecotone)
• TxEnv contains additional field optimism for OptimismFields. This also affects:
  • New variants are added to enum InvalidTransaction: DepositSystemTxPostRegolith and HaltedDepositPostRegolith
  • HaltReason::FailedDeposit was added
• SpecId contains additional variants for optimism: bedrock, regolith, canyon, and ecotone. This also affects:
  • match statement
  • mapping to PrecompileSpecId
• HandlerCfg contains additional field is_optimism for a boolean toggle between vanilla and optimism ethereum
• There is an optimism handle register with custom ~bytecodes~ logic
• InnerEvmContext contains additional field l1_block_info
  • This is only used in optimism-specific handlers

In Rust:

When a dependency is used by multiple packages, Cargo will use the union of all features enabled on that dependency when building it. This helps ensure that only a single copy of the dependency is used.

As such, if we want to support both vanilla Ethereum and optimism, no matter what we do, we'll always be compiling revm with optimism enabled. When scaling to even more chains, this would quickly explode the complexity of the revm code.

My analysis of this design is that the complexity can be reduced by:

1. No longer dealing with SpecIds inside revm directly, but using them as an external helper type that's specific for vanilla Ethereum vs optimism. Internally this would map to EIPs being toggled. The Evm would then internally check whether an EIP is enabled.
2. Moving InnerEvmContext::l1_block_info and TxEnv::optimism to the external context (or a separate "chain context"). This would then be exposed to the handlers to enable different chains (incl. transaction types).
3. Point 2 also voids the need for is_optimism as this would be signalled through a struct OptimismContext.
4. The gas cost tables don't need to be part of the interpreter but can rather be passed in by the EvmBuilder pattern.
5. The ExecutionResult would need to be a generic in order to support different types of HaltReason. The result type of transactions would be determined this way too.
6. It is likely possible to have a trait that expresses all of the generic types required for the Evm to work for a particular type of chain.

This should be extensible to other chains - beyond optimism - as well.

[Wodann]

See https://github.com/NomicFoundation/edr/issues/377#issuecomment-2098784211 for how we can work around the optimism feature flag limitation.

With this in place, we should:

• be able to have in-memory representations of Optimism-specific transaction types based on this code
• be able to have optimism and non-optimism transactions side-by-side in a single provider class using generics and a trait ChainSpec which specifies types

[fvictorio]

There is an optimism handle register with custom bytecodes

Can you expand on this?

[Wodann]

There is an optimism handle register with custom bytecodes

Can you expand on this?

I fixed the wording. They're not custom bytecode. Rather, custom handler logic which is used in the EVM