core/state/snapshot: reduce disk layer depth during generation #21477
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.
The snapshotter operates on state (roots) and is oblivious to blocks. This is needed because there's really no notion of a block inside the state snapshot or the statedb and introducing them would make things extremely messy. This however creates a weird corner case:
If two blocks have the same state root (Clique empty block), these two 128 concepts will go out of sync. The snapshotter will still maintain 128 unique states, but that will correspond to more than 128 blocks. Essentially the snapshotter's disk layer will reference state that does not exist in trie form any more.
This is completely fine in normal mode of operation. The hiccup is during snapshot construction, because there it can happen that the trie based on which we are building the snapshot gets deleted. In that case in the existing code we need to wait for 128 non-empty blocks to shift the discrepancy out and resume generation. This is kind of bad on networks with limited tx throughput.
This PR makes a tiny hack so that during generation (and only then), the snapshot depth is kept at 8 instead of 128. This ensures that as long at there are at least 8 blocks with txs in them in a 128 block range, the snapshotter will be able to generate itself. The reason I picked 8 instead of 1 (which would work for a completely idle network too) is that the snapshotter's persistent layer can't reorg, so we need something that won't ever get reorged (during generation, or at least super improbable).