fix: use cumulative prefix sets for incremental trie state root

[avalonche]

Fix: track cumulative TriePrefixSetsMut across all flashblocks. Before building TrieInput, extend the current prefix sets with all prior flashblocks' prefix sets. This forces the walker to re-visit every path modified in earlier flashblocks.

The fix is also ~30% faster than the unfixed incremental path because descending into cached in-memory nodes is faster than DB cursor seeks for skipped branches.

Benchmarks (10 flashblocks, 50k accounts):

• Without cache: ~2,200ms (baseline)
• Incremental (no fix): ~844ms (2.6x faster, incorrect on reverts)
• Incremental (with fix): ~650ms (3.4x faster, correct)

[akundaz]

The benchmark and tests run against replicated state root calculations instead of the actual production code path. Can you extract the code to run this calculation and and update the benchmark and tests to call that directly? Otherwise we can't really draw conclusions about real world performance from these results. And if the code drifts we should be able to catch with our tests and the benchmark.

[akundaz]

The test_storage_revert_to_original_with_populated_trie test asserts both that the old incremental computation is buggy and that the new computation is correct. But we don't need to check the old computation and prove that the bug existed in an older version of the code, just that the fix works. And then the test should be able to catch the regression if the fix is removed by failing.

I would also like to see better encapsulation of the state root computation. Right now it's spread across state_root.rs and payload.rs but we should try to get it all in state_root.rs (the unit test should go there as well). I would suggest that instead of FlashblocksState containing fields enable_incremental_state_root, prev_trie_updates, and cumulative_prefix_sets, you define a new type for the state root computation.

[avalonche]

@akundaz

The test_storage_revert_to_original_with_populated_trie test asserts both that the old incremental computation is buggy and that the new computation is correct. But we don't need to check the old computation and prove that the bug existed in an older version of the code, just that the fix works. And then the test should be able to catch the regression if the fix is removed by failing.

This change was just illustrative to prove that the issue is reproducible and that the new code fixes the issue. I can remove it if you're satisfied this fix works with reverts.

[akundaz]

This change was just illustrative to prove that the issue is reproducible and that the new code fixes the issue. I can remove it if you're satisfied this fix works with reverts.

That's fine! Just make sure to have a test with reverts since it triggers the bug

[akundaz]

Just adding a few comments. I think once they are resolved and CI passes this will probably be good