take_block_and_execution_range and remove_block_and_execution_range share the exact the same logic for unwinding trie state from database which this PR unifies into a single unwind_trie_state_range
The primary motivation however is to reuse unwind_trie_state_range in reth debug execution command. I'm preparing changes to make remove_block_and_execution_range to also prune static files which is inappropriate for debug utilities which expect the database to only be changed during commits.
When simulating unwinds, reth debug execution will now only call unwind_trie_state_range which will verify state root consistency during unwind which I believe is the purpose of this uncommited unwind per https://github.com/paradigmxyz/reth/pull/2619
take_block_and_execution_rangeandremove_block_and_execution_rangeshare the exact the same logic for unwinding trie state from database which this PR unifies into a singleunwind_trie_state_rangeThe primary motivation however is to reuse
unwind_trie_state_rangeinreth debug executioncommand. I'm preparing changes to makeremove_block_and_execution_rangeto also prune static files which is inappropriate for debug utilities which expect the database to only be changed during commits.When simulating unwinds,
reth debug executionwill now only callunwind_trie_state_rangewhich will verify state root consistency during unwind which I believe is the purpose of this uncommited unwind per https://github.com/paradigmxyz/reth/pull/2619