feat: Add state root calculation time from latest flashblock state to metering RPC #147

niran · 2025-10-28T20:03:57Z

Adds state root calculation timing with flashblock state support to the metering RPC to provide visibility into state root computation performance as an independent metric.

TODO

Add tests with state changes across blocks and flashblocks based on the upcoming refactored flashblocks-rpc test suite

Key Changes

1. Flashblock State Integration

Bundles now execute on top of pending flashblock state (not just canonical block)
Accurately accounts for nonces, balances, storage, and code changes from pending transactions
Adds state_flashblock_index to response

2. State Root Optimization

New FlashblockTrieCache: caches latest flashblock's trie nodes
Computes flashblock state root once, reuses for all subsequent bundle metering calls
Cache keyed by (block_hash, flashblock_index)
Uses TrieInput.prepend_cached() to combine cached flashblock trie with bundle changes
Significant performance improvement for repeated metering on same flashblock

3. State Root Metrics

Separately tracks state root calculation time
Flashblock trie computation excluded from timing metrics

4. Flashblocks-RPC Fixes (discovered during implementation)

Fixed incorrect database layering: Changed from CacheDB → State to State → CacheDB → StateProviderDatabase
Added bundle state tracking: PendingBlocks now tracks accumulated BundleState alongside cache
Added state accumulation: Uses with_bundle_prestate() to accumulate state changes across flashblocks
These fixes enable accurate state root calculations for metering and potentially benefit other flashblock state consumers

cb-heimdall · 2025-10-31T17:09:03Z

🟡 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

Add state root calculation after transaction execution and measure its time independently. The state root calculation time is included in the total execution time and also tracked separately.

Update tips-core dependency to include state_root_time_us field in MeterBundleResponse. This exposes the state root calculation time as an independent metric in the metering RPC response.

Add unit test to verify total_execution_time_us >= state_root_time_us invariant and RPC integration test to verify state_root_time_us is properly exposed in the response.

…ome wrapper

Integrate flashblocks state into metering to execute bundles on top of pending flashblock state rather than canonical block state. This ensures metered gas usage and execution time accurately reflect the effects of pending transactions (nonces, balances, storage, code changes). Implementation: - Add flashblocks-rpc dependency to metering crate - Update meter_bundle() to accept optional db_cache parameter - Implement three-layer state architecture: 1. StateProviderDatabase (canonical block base state) 2. CacheDB (applies flashblock pending changes via cache) 3. State wrapper (for EVM builder compatibility) - Update MeteringApiImpl to accept FlashblocksState - Get pending blocks and db_cache from flashblocks when available - Fall back to canonical block state when no flashblocks available - Update response to include flashblock_index in logs - Require flashblocks to be enabled for metering RPC - Update all tests to pass FlashblocksState parameter The metering RPC now uses the same state as flashblocks eth_call, ensuring consistent simulation results.

Adds a single-entry cache for the latest flashblock's trie nodes, allowing bundle metering operations to reuse the cached trie computation instead of recalculating from scratch each time. Key changes: - Add FlashblockTrieCache: thread-safe single-entry cache for latest flashblock - Add FlashblockTrieData: contains trie updates and hashed state for reuse - Cache keyed by block hash and flashblock index for accuracy - Compute flashblock trie once per flashblock, reuse for all bundle operations - Extract flashblock trie calculation outside timing metrics - Use TrieInput.prepend_cached() to combine flashblock + bundle tries The cache replaces previous entries when a new flashblock is cached, as it's designed only for the current/latest flashblock, not historical ones.

The timer and field names now better reflect that they measure the total elapsed time (including both transaction execution and state root calculation), rather than just execution time. This distinguishes them from the per-transaction execution_time_us metrics. Changes: - Renamed execution_start → total_start timer - Renamed total_execution_time → total_time variable - Renamed total_execution_time_us → total_time_us in MeterBundleOutput - Updated logging and tests to use new naming - Added TODO comment for tips-core field rename

Consolidate the logic for using cached vs computed flashblock trie data by introducing a single flashblock_trie_data variable that handles both cases. This eliminates duplicate code paths in the state root calculation section.

Add comments explaining that the trie cache ensures each bundle's state root calculation measures only the bundle's incremental I/O, not the accumulated I/O from previous flashblocks.

haardikk21 · 2025-11-26T17:06:17Z

crates/flashblocks-rpc/src/pending_blocks.rs

+    pub fn get_bundle_state(&self) -> BundleState {
+        self.bundle_state.clone()
+    }


Do we have any intuition for how expensive this clone can get? Slightly concerned about introducing a perf regression here. A not too older version here had a significant perf regression because of some extremely large clones that started happening. Im unsure how fast bundlestate can grow.

This may be worth testing on mainnet dev node before merging to main

Added metrics for this in 9752d0a.

haardikk21 · 2025-11-26T17:15:02Z

Could you also expand on this?

Fixed incorrect database layering: Changed from CacheDB → State to State → CacheDB → StateProviderDatabase

What issues existed previously and what implications does this have? i'm concerned about changes to the core processing pipeline introducing regressions not caught in the current tests. Definitely think this needs to go on mainnet dev node before being merged

Track duration and size (number of accounts) when cloning BundleState to help identify if this becomes a performance bottleneck.

niran · 2025-11-26T21:24:20Z

Fixed incorrect database layering: Changed from CacheDB → State to State → CacheDB → StateProviderDatabase

What issues existed previously and what implications does this have?

CacheDB is a read-through cache. Writes are not propagated. As a result, I believe the State layer in the previous implementation wasn't doing anything. State is for producing BundleStates that the rest of the reth machinery can use to persist the changes, or in our case, calculate the state root. If a CacheDB is in front of it, no changes will be written to the State.

We can either remove the CacheDB entirely, or we can keep it around like the current PR does to maintain a cache of reads.

~~I could be wrong about this since I haven't actually written code that compares both outcomes. But that's my reading of the docs.~~ (Tests added in 1942db8.)

Definitely think this needs to go on mainnet dev node before being merged

Makes sense.

Add tests verifying the correct State<CacheDB<StateProviderDatabase>> layering order. These tests demonstrate that CacheDB<State<...>> loses writes because CacheDB intercepts all writes into its internal cache without propagating them to State's bundle tracking.

niran · 2025-11-26T22:04:46Z

There are now tests in 1942db8 that prove that the new State<CacheDB<StateProviderDatabase>> layering is correct and necessary for state root calculation.

niran force-pushed the meter-state-root branch from bea1d62 to ea0edba Compare October 29, 2025 16:18

Base automatically changed from metering-rpc to main October 29, 2025 17:36

niran force-pushed the meter-state-root branch from ea0edba to 20b881b Compare October 30, 2025 05:59

niran changed the title ~~feat: Add state root calculation time to metering RPC~~ feat: Add state root calculation time from latest flashblock state to metering RPC Oct 30, 2025

niran force-pushed the meter-state-root branch from 8941245 to 9830d93 Compare November 8, 2025 23:01

niran changed the base branch from main to refactor-tests November 8, 2025 23:01

niran marked this pull request as ready for review November 14, 2025 17:08

niran force-pushed the refactor-tests branch 2 times, most recently from 70e71ed to 56ba57b Compare November 23, 2025 07:37

niran force-pushed the meter-state-root branch from 81107e1 to 76b41e6 Compare November 26, 2025 02:21

Base automatically changed from refactor-tests to main November 26, 2025 16:18

niran added 18 commits November 26, 2025 11:00

Include state root calculation time in metering

fda04a5

Add state root calculation after transaction execution and measure its time independently. The state root calculation time is included in the total execution time and also tracked separately.

Update tips-core and expose state root time in RPC response

fe163b4

Update tips-core dependency to include state_root_time_us field in MeterBundleResponse. This exposes the state root calculation time as an independent metric in the metering RPC response.

Add tests for state root time metrics

305a2ce

Add unit test to verify total_execution_time_us >= state_root_time_us invariant and RPC integration test to verify state_root_time_us is properly exposed in the response.

Simplify state root calculation by removing unnecessary ExecutionOutc…

ad9586d

…ome wrapper

linter fixes

2c8699f

Add chain-state metering tests and flashblock harness support

62bd1c3

Fix chain-state metering tests with L1 deposit

8749989

Restore beacon root for successful metering tests

5aacb8a

Have storage persistence test meter the next block

e55c43a

Rename metering tests for clarity

a41a001

Drop redundant beacon-root RPC test

3572284

Document why flashblock trie caching isolates bundle I/O

eb37396

Add comments explaining that the trie cache ensures each bundle's state root calculation measures only the bundle's incremental I/O, not the accumulated I/O from previous flashblocks.

Move build_single_flashblock from metering to test-utils

82b03cb

tweak comments

4211c10

niran added 3 commits November 26, 2025 11:00

Update tips-core and fix metering harness/tests

5b05bb2

Silence the global executor errors

9d07837

Add TODO for state_root_time

d8c7184

niran force-pushed the meter-state-root branch from 76b41e6 to d8c7184 Compare November 26, 2025 17:01

niran requested review from danyalprout and haardikk21 November 26, 2025 17:01

haardikk21 reviewed Nov 26, 2025

View reviewed changes

Add metrics for bundle state clone cost

9752d0a

Track duration and size (number of accounts) when cloning BundleState to help identify if this becomes a performance bottleneck.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: Add state root calculation time from latest flashblock state to metering RPC #147

feat: Add state root calculation time from latest flashblock state to metering RPC #147

niran commented Oct 28, 2025 •

edited

Loading

Uh oh!

cb-heimdall commented Oct 31, 2025 •

edited

Loading

Uh oh!

haardikk21 Nov 26, 2025

Uh oh!

niran Nov 26, 2025

Uh oh!

haardikk21 commented Nov 26, 2025

Uh oh!

niran commented Nov 26, 2025 •

edited

Loading

Uh oh!

niran commented Nov 26, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

feat: Add state root calculation time from latest flashblock state to metering RPC #147

Are you sure you want to change the base?

feat: Add state root calculation time from latest flashblock state to metering RPC #147

Conversation

niran commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Key Changes

Uh oh!

cb-heimdall commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🟡 Heimdall Review Status

Uh oh!

haardikk21 Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

niran Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

haardikk21 commented Nov 26, 2025

Uh oh!

niran commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

niran commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

niran commented Oct 28, 2025 •

edited

Loading

cb-heimdall commented Oct 31, 2025 •

edited

Loading

niran commented Nov 26, 2025 •

edited

Loading

niran commented Nov 26, 2025 •

edited

Loading