Add incremental trie cache optimization for flashblocks state root calculation#385
Add incremental trie cache optimization for flashblocks state root calculation#385cliff0412 wants to merge 7 commits intoflashbots:mainfrom
Conversation
cliff0412
requested review from
0x416e746f6e,
SozinM,
avalonche and
karim-agha
as code owners
There was a problem hiding this comment.
Looks very good @cliff0412. As @SozinM said, this is pure optimization and I don't see scenarios where this should be disabled. You can remove the arg and simplify a bit build_block.
You can also add a few comments just to explain that trie updates are None in the first flashblock only.
cliff0412
force-pushed
the
feature/cliff/optimize-stateroot-calculation
branch
from
df54a8c to
fa38fdf
Compare
config arg removed. |
Apply trie updates to FlashblocksState via a local cache instead of mutating through Option in the state-root block. Cache trie updates in trie_updates_to_cache and set prev_trie_updates when consuming fb_state later, so the signature can stay fb_state: Option<&mut FlashblocksState> without requiring mut on the parameter. Made-with: Cursor
…ks state root Port flashbots/op-rbuilder#385 - caches TrieUpdates after each flashblock state root calculation so subsequent flashblocks reuse cached trie nodes instead of recomputing from the database each time, achieving ~2.4-2.5x speedup in state root calculation. Changes: - Add `prev_trie_updates: Option<Arc<TrieUpdates>>` field to FlashblocksState - Use `state_root_from_nodes_with_updates` with cached trie on subsequent flashblocks - Cache trie updates after each calculation and propagate to next flashblock - Add criterion benchmark: bench_flashblocks_state_root - Add reth-trie-db and criterion workspace dependencies Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
@cliff0412 could you rebase off main? |
|
We don't have write permissions on head branch so I rebased main onto this in #427 with minor changes and cleaning. Thank you for the valuable contribution @cliff0412 |
4 participants
In this PR, we cache the trie nodes after each flashblock state root calculation. Therefore,
future flashblock state root calculation can be faster. resolving this issue #345
Full benchmark report:
benchmark_logs/TRIE_CACHE_BENCHMARK_REPORT.md