feat(metering): use pending flashblocks state for bundle metering

[niran]

Summary

Enable bundle metering to use the current pending flashblocks state instead of just the canonical block state. This ensures that bundle simulations see the same state that will be used when the bundle is actually included in a flashblock.

Changes

Metering Crate

• meter.rs: Add FlashblocksState struct containing Cache and BundleState. Update meter_bundle to accept an optional FlashblocksState parameter. Implement three-layer database architecture: State<CacheDB<StateProviderDatabase>> where:
  • StateProviderDatabase reads from canonical chain state
  • CacheDB provides pending flashblock reads via the cache
  • State tracks bundle writes with flashblock prestate via with_bundle_prestate()
• rpc.rs: Update MeteringApiImpl to integrate with flashblocks API. Get pending blocks state and pass it to meter_bundle. Include state_flashblock_index in response.
• extension.rs: Update MeteringExtension to accept flashblocks configuration and cell.
• lib.rs: Export FlashblocksState.

Flashblocks Crate

• tests/state.rs: Add integration tests verifying that bundle metering correctly sees pending flashblock state changes.

Architecture

Bundle Metering Database Layers:

┌─────────────────────────────────┐
│  State (bundle tracking)        │  ← Tracks writes, includes flashblock prestate
├─────────────────────────────────┤
│  CacheDB (flashblock cache)     │  ← Provides pending reads from flashblocks
├─────────────────────────────────┤
│  StateProviderDatabase          │  ← Reads from canonical chain state
└─────────────────────────────────┘

Test Plan

• Bundle metering correctly fails for nonce=1 tx without flashblock state (canonical nonce is 0)
• Bundle metering succeeds for nonce=1 tx with flashblock state showing pending nonce=1
• State visibility tests pass
• cargo clippy passes

[danyalprout]

I think the metering crate needing the FlashblocksConfig to init this feels like a design flaw in our node setup.

I would suggest we make the following change in main.rs

let fb_state = Arc::new(FlashblocksState::new())

install_ext::<Flashblocks>({ fb_state.clone() })
install_ext::<Metering>({ fb_state })

We should be able to just totally remove the oncecell setup and dependency. This was the symptom of a time where we had two tokio routines racing to initialize it, but I suspect we can get rid of it now.

[niran]

FlashblocksState needs a Client/Provider object, which we currently get from the context passed to extend_rpc_modules. Unless the builder provides a way to get a reference to something that will eventually give us a provider, we're kind of stuck. One option we still have is to move
the cell inside FlashblocksState, which should be able to give us your code snippet above. But it just moves the mess somewhere else, and probably adds more of it since FlashblocksState would be full of checks for an empty cell.

[danyalprout]

Gotcha, lets pair tomorrow morning, I have an idea

[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