fix(precompiles): preserve mega overrides across spec changes

[Troublor]

Context

Two PrecompileProvider impls live in crates/mega-evm/src/evm/precompiles.rs:

1. impl<CTX> PrecompileProvider<CTX> for MegaPrecompiles where CTX: ContextTr<Cfg: Cfg<Spec = MegaSpecId>> at lines 105-135. set_spec rebuilds the provider via MegaPrecompiles::new_with_spec(spec), branching on MegaSpecId to install the correct precompile table.

2. impl<DB, ExtEnvs> PrecompileProvider<MegaContext<DB, ExtEnvs>> for PrecompilesMap at lines 143-182. set_spec(OpSpecId) delegates to PrecompileProvider::<OpContext<DB>>::set_spec, which would rebuild the table from a vanilla OpSpecId.

MegaContext declares its Cfg as CfgEnv<OpSpecId> (crates/mega-evm/src/evm/context.rs:606), so Cfg::Spec = OpSpecId. The trait bound on impl (1) requires Cfg::Spec = MegaSpecId — unsatisfiable for MegaContext. Impl (1) is therefore unselectable through MegaContext.

In addition, the EVM construction path at crates/mega-evm/src/evm/mod.rs:153 builds the runtime provider as:

PrecompilesMap::from_static(MegaPrecompiles::new_with_spec(spec).precompiles())

This extracts the &'static Precompiles table and discards the MegaPrecompiles struct, so the struct's set_spec and Default impls cannot be invoked at runtime. Mega's customizations (OSAKA modexp + 100k-gas KZG) take effect today only because the static table baked at construction already contains them.

Potential issue to flag

revm currently does not call precompile_provider.set_spec(cfg.spec) on the warm transaction-execution path, so impl (2)'s op-revm delegation is never exercised and the baked-in overrides survive.

If a future revm version adds such a call, impl (2) would receive an OpSpecId and op-revm would rebuild a vanilla table, replacing:

• 100k-gas KZG point evaluation override → vanilla 50k-gas pricing
• OSAKA modexp → ISTHMUS modexp (different gas curve)

The MegaSpecId → OpSpecId mapping is many-to-one (all Mega specs currently map to ISTHMUS), so OpSpecId alone cannot reconstruct the correct Mega-specific table. Two clients running different revm minor versions could end up computing different gas usage on any block invoking these precompiles.

Filing this so the dead-code path and the warm-path delegation are visible before the next revm dependency bump.

[TroublorBot]

🤖 Engineer agent picked up this issue. Triaging...

[TroublorBot]

🤖 Engineer agent picked up this issue. Triaging...

[TroublorBot]

Good investigation — the concern is valid and actionable. After tracing through the current dependency chain I found the timeline is more urgent than described, plus a clarification on which upstream is the risk.

set_spec is already being called today

revm-handler-8.1.0 already calls precompiles.set_spec(gen_spec) on every transaction in pre_execution::load_accounts() — this is not a hypothetical future change:

// revm-handler-8.1.0/src/pre_execution.rs:30-34
let gen_spec = context.cfg().spec();   // → OpSpecId (MegaContext::Cfg::Spec = OpSpecId)
let precompiles_changed = precompiles.set_spec(gen_spec);

Why Mega's overrides currently survive (and the real risk)

The delegation in impl (2) — PrecompileProvider::<OpContext<DB>>::set_spec(self, spec) — resolves to the alloy-evm 0.15.0 blanket impl of PrecompileProvider<Context<...>> for PrecompilesMap, which is a no-op:

// alloy-evm-0.15.0/src/precompiles.rs:328
fn set_spec(&mut self, _spec: CfgEnv::Spec) -> bool {
    false  // table is never rebuilt
}

The static table baked at EVM construction — containing the 100k-gas KZG override and OSAKA modexp — is never replaced. Safety comes from this upstream no-op, not from any correctness in mega-evm's own set_spec impl.

The risk is therefore an alloy-evm bump, not a revm bump. If alloy-evm changes PrecompilesMap::set_spec to rebuild from spec (as EthPrecompiles::set_spec does in revm), impl (2)'s delegation would silently produce a vanilla ISTHMUS table and silently drop Mega's overrides.

The rest of the analysis is correct:

• Impl (1) (MegaPrecompiles as PrecompileProvider<CTX> requiring Cfg::Spec = MegaSpecId) is permanently unreachable for MegaContext — the constraint is unsatisfiable since MegaContext::Cfg::Spec = OpSpecId. MegaPrecompiles today exists solely as a builder to produce the static table at construction time.
• The MegaSpecId → OpSpecId many-to-one mapping means no rebuild-from-spec path can correctly reconstruct Mega's table.

Proposed fix

The correct impl for PrecompilesMap::set_spec under MegaContext is an explicit no-op with a comment explaining why:

impl<DB: Database, ExtEnvs: ExternalEnvTypes> PrecompileProvider<MegaContext<DB, ExtEnvs>>
    for PrecompilesMap
{
    fn set_spec(&mut self, _spec: OpSpecId) -> bool {
        // The precompile table is baked at EVM construction via
        // MegaPrecompiles::new_with_spec and must not be rebuilt from an
        // OpSpecId. OpSpecId is many-to-one with MegaSpecId (all Mega specs
        // map to ISTHMUS), so an OpSpecId cannot recover Mega-specific
        // overrides (100k-gas KZG, OSAKA modexp).
        false
    }
    // run, warm_addresses, contains unchanged ...
}

This removes the dependency on alloy-evm's set_spec staying a no-op and makes the intent self-documenting.

Additionally, a regression test that calls set_spec(OpSpecId::ISTHMUS) on the PrecompilesMap after construction and then verifies the KZG gas cost is still 100k would catch any future upstream change that triggers a table rebuild.

[Troublor]

@TroublorBot Looks good to me. Will the caller be able to know that his invocation to set_spec is rejected?