WIP 2 Improve snapshot generation #22500
Conversation
* core/state/snapshot: refactor * core/state/snapshot: tiny fix and polish Co-authored-by: rjl493456442 <[email protected]>
- fix error that cause re-iteration of accounts - logging fix - fix error where we got stuck iterating the trie - fix error in merging writes/deletes to the accounts
| // This is an odd case. How can this happen? It means our snap data | ||
| // is correct, but not compelete? Maybe we can just continue here without | ||
| // deleting the existing data. | ||
| // We definitely need a testcase for this path |
There was a problem hiding this comment.
It's a special case that: all the snap states in the disk are iterated and verified, but there are some extra states on the right side in the trie. So the data is loss in the snap. Actually In my PR I have a testcase for it. https://github.com/ethereum/go-ethereum/pull/22465/files#diff-692791523abdbacf9c463a59f5ceffc649df9c6cc646ab1fdab0d6c1a4fa9ac8R193
| // to check validity. We can just feed the key/vals into a stacktrie and obtain the | ||
| // root hash | ||
| if len(origin) == 0 && !aborted { | ||
| stackTr := trie.NewStackTrie(nil) |
There was a problem hiding this comment.
Actually in this case, we don't need the stacktrie. For tiny storage trie, we don't need to build the edge proofs at all. We can pass the nil proof and the entire key/val set to the range prover.
Regarding the standard trie VS stacktrie, I think there is no big difference in the performance. StackTrie is more memory friendly, but for the tiny trie it's unnecessary to introduce the stacktrie.
Not to be merged!
This is a version of #22465, just posting it here so people can more easily try it out. At one point it should be merged back to @rjl493456442 's branch, but it's deviated so far now so I might aswell postpone it a bit longer.