fix: derive BlobParams from chain spec instead of hardcoding

[Evalir]

Closes ENG-2110

Summary

populate_initial_gas hardcoded BlobParams::prague() when computing max_fee_per_blob_gas for host chain blob transactions. When the network moved to BPO2, the exponential blob pricing formula amplified the parameter mismatch into an astronomically wrong blob fee.

Concretely, the mismatch affects both inputs to the blob fee exponential:

1. Target blob gas: Prague uses 786,432 vs BPO2's 1,835,008 — the builder subtracts less from excess, computing a higher excess value
2. Update fraction: Prague uses 5,007,716 vs BPO2's 11,684,671 — the builder divides by a smaller denominator, inflating the exponent further
3. blob_base_cost: Prague uses 0 (never takes the Osaka scaled-excess branch) vs BPO2's 8,192 — the builder uses a completely different excess formula than the network

With ~187M excess_blob_gas on the network (reachable in ~60 min of sustained blob demand, where the real blob fee is only ~9M wei per blob gas), the builder computes an exponent of 37.5 instead of the correct 15.3, producing a max_fee_per_blob_gas of ~20 quadrillion wei — 2.1 billion times higher than reality. This caused eth_estimateGas to report a required balance of ~2,618 ETH for a single blob transaction, failing with -32003: insufficient funds.

Fix

Replace the hardcoded BlobParams::prague() with dynamic resolution via EthChainSpec::blob_params_at_timestamp(), using the same chain spec that SignetCfgEnv::spec_id() already uses. This handles the full Cancun -> Prague -> Osaka -> BPO1 -> BPO2 schedule automatically, so the builder will always use the correct blob parameters for the current hardfork.

Test plan

• make clippy passes with -D warnings
• make test — all tests pass
• Deploy to a mainnet builder and confirm blob transactions submit successfully

Generated with Claude Code

[Evalir]

• fix: derive BlobParams from chain spec instead of hardcoding #254 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.