chore(el): derive reth chainspecs from base-alloy-chains vs. duplicating configs

[danyalprout]

Description

Part one of deduplicating chain configurations and settings. Creates base-alloy-chains which has the chain configurations defined in Rust.

Upstream consumers will map this generic type into CL/EL specific types via a TryFrom/From impl.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	Mar 23, 2026 5:09am

[github-actions]

by_name does a linear scan with contains on each config's cli_names slice. With only 4 configs this is fine, but the &str parameter requires exact equality — consider documenting that this is case-sensitive. No functional issue, just noting for API clarity.

[github-actions]

parse_chain now constructs a fresh OpChainSpec (including deserializing the embedded genesis JSON) on every call. The old implementation returned Arc::clone() of LazyLock statics, which was essentially free after first access.

This is called from CLI parsing so it's unlikely to be a hot path, but if anything else calls parse_chain repeatedly (e.g., in tests or validation loops), the repeated deserialization is wasteful. Consider caching the result per chain, or documenting that callers should cache the Arc themselves.

[github-actions]

Behavioral change for dev chain base fee params. The deleted dev.rs used BaseFeeParamsKind::Constant(BaseFeeParams::ethereum()) which is { denominator: 8, elasticity: 2 }. The new From<&BaseChainConfig> impl derives params from these config values, producing BaseFeeParamsKind::Variable([(London, {50, 6}), (Canyon, {250, 6})]) because eip1559_denominator (50) != eip1559_denominator_canyon (250).

This changes the dev chain from Ethereum-style constant base fee params to OP-style variable params. If this is intentional (aligning devnet with production behavior), it's fine — but if the old Ethereum-style params were needed for dev/test compatibility, this is a regression.

[danyalprout]

This is a correct change

[github-actions]

SUPPORTED_CHAINS duplicates data already embedded in each config's cli_names. The test at the bottom catches drift, but this const could be derived at compile-time or as a function to eliminate the maintenance hazard entirely:

pub fn supported_chains() -> impl Iterator<Item = &'static str> {
    BaseChainConfig::all().into_iter().flat_map(|cfg| cfg.cli_names.iter().copied())
}

This would also remove the need for the sync test. If the const form is needed for CLI help strings (e.g., clap's possible_values), consider generating it from cli_names via a const fn or LazyLock instead of manually maintaining the list.

[github-actions]

Review Summary

This PR consolidates four per-chain LazyLock<Arc<OpChainSpec>> statics (BASE_MAINNET, BASE_SEPOLIA, BASE_DEVNET_0_SEPOLIA_DEV_0, OP_DEV) and their corresponding hardfork statics into a single From<&BaseChainConfig> for OpChainSpec impl, deriving chain specs on demand from BaseChainConfig data. It also moves SUPPORTED_CHAINS into base-alloy-chains and adds cli_names/prune_delete_limit fields to BaseChainConfig.

What looks good

• Base fee params are equivalent. Verified that the derived BaseFeeParams from config values match what the old named constructors (BaseFeeParams::optimism(), optimism_canyon(), base_sepolia(), base_sepolia_canyon()) produced. The fork-id and genesis hash tests confirm no regressions for mainnet and sepolia.
• Genesis header handling is correct. The genesis_l2_hash.is_zero() check correctly differentiates dev (slow-sealed) from production (pre-known hash) genesis headers.
• Test migration is mechanical and correct. All test changes are straightforward replacements of static refs with freshly constructed specs.
• Hardfork consolidation is clean. Only BASE_MAINNET_HARDFORKS is retained as a Lazy static (used in the OpChainSpec::from(Genesis) fallback path); the rest are properly derived via BaseChainUpgrades::new(BaseUpgrade::forks_for(cfg)).to_chain_hardforks().

Findings (inline comments posted)

All findings were posted as inline comments on this and prior review passes:

1. Dev chain base fee behavioral change — The old OP_DEV used BaseFeeParams::ethereum() ({8, 2}), the new path produces OP-style params ({50, 6} / {250, 6}). Should be confirmed intentional.
2. parse_chain no longer caches — Each call now deserializes genesis JSON. Not a regression for CLI use, but worth noting if called in loops.
3. SUPPORTED_CHAINS duplication — The const duplicates data from cli_names; a derived function would be more robust (though the sync test mitigates drift).
4. Panic in From impl — unwrap_or_else with chain ID in the message was adopted (good).
5. by_name linear scan — Fine at 4 configs, but exact-match / case-sensitivity is undocumented.

No blocking issues found. The main item requiring explicit confirmation is the dev chain base fee parameter change (#1 above).