chore(trie): Implement OverlayStateProviderFactory#18854
Merged
mediocregopher merged 11 commits into18460-trie-changesetsfrom Oct 6, 2025
Merged
chore(trie): Implement OverlayStateProviderFactory#18854mediocregopher merged 11 commits into18460-trie-changesetsfrom
mediocregopher merged 11 commits into18460-trie-changesetsfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This implements the OverlayStateProviderFactory, which intends on replacing the ConsistentDbView for use with proof fetching.
When creating a new OverlayStateProvider, the OverlayStateProviderFactory can be configured to first revert that provider's state to a particular block number (similar to the HistoricalStateProvider) and then also apply some other overlay state on top of it. This gives us full flexibility in computing proofs on top of re-org chains, even if they are based on block prior to the db tip.
It uses a new method
trie_revertsto fetch trie changesets, alongside HashedPostState reverts using the existing method for that. With these two it is able to revert to any previous block for every provider it generates, ensuring a consistent view of the data. In the future if we switch to using tx children then the factory can fetch the reverts as part of its own constructor, rather than on every new provider.This PR required adding the ability to extend the HashedPostStateSorted and TrieUpdatesSorted types. This is implemented fairly efficiently by updating the collection in-place with updates/removals, and then appending additions onto the back and sorting.
Closes #18466