Optimize the trie prefetcher

[rjl493456442]

By revamping the block prefetcher, state retrieval has been significantly optimized.
However, the account trie and storage trie updates is occasional slow.

In Geth’s workflow, state is typically fetched from the flat-state, while dirty states,
such as accounts and storage slots modified during transaction execution, are
scheduled for prefetching from the trie. This is based on the assumption that these
trie nodes are likely to be updated at the end of block execution.

Once all transactions in the block have been processed, Geth flushes all dirty states
into the trie and re-computes the state root. At this point, Geth is blocked until all
pending trie prefetching tasks are completed and then reuse the trie from prefetcher
for state rehasing. Preliminary investigation shows that a significant portion of the
time spent on storage updates is actually due to waiting on the trie prefetcher,
which appears to be inefficient.

An additional observation is that storage modifications are highly uneven. Some
contracts may modify hundreds of storage slots within a single transaction, creating
huge workload imbalances for the trie prefetcher.

[nadtech-hub]

May I take on it?

[will-2012]

hello, Https://github.com/ethereum/go-ethereum/blob/master/core/state/statedb.go#L789 triggers the slow, and blocking wait here https://github.com/ethereum/go-ethereum/blob/master/core/state/trie_prefetcher.go#L322 ??

[rjl493456442]

@will-2012
It's blocked here.

https://github.com/ethereum/go-ethereum/blob/master/core/state/state_object.go#L296

[will-2012]

@will-2012 It's blocked here.

https://github.com/ethereum/go-ethereum/blob/master/core/state/state_object.go#L296

Got it, is the inner getPrefetchedTrie waiting for the prefetcher to finish?

[rjl493456442]

yes