ethereumjs-monorepo
ethereumjs-monorepo copied to clipboard
ethereumjs
Support using hashed account and storage tries
Currently, in order to put an account into the state manager, it has to be done so using the putAccount function, which requires an account address. During snap sync, account addresses are not known, only their hash. In order to store state from snap sync in state manager, it is necessary to add this functionality.
Also see #2345.
The same would also apply for storages. Can we not directly dump these into an unhashed trie into snap sync, or do we really need to use StateManager?
The same would also apply for storages. Can we not directly dump these into an unhashed trie into snap sync, or do we really need to use StateManager?
It is possible to put the data directly into tries, but it seems like we would be recreating a significant amount of StateManager functionality. It may be advantageous for code reuse to use a modified StateManager.
@jochem-brouwer @scorbajio is it eventually possible to combine both and initialize a StateManager "as is" with an unhashed trie? 🤔 Just to throw another option in the ring.
Hmm that would most likely fix the problem in an elegant way. Thoughts @scorbajio ?
@jochem-brouwer @scorbajio is it eventually possible to combine both and initialize a StateManager "as is" with an unhashed trie? thinking Just to throw another option in the ring.
@holgerd77 What do you mean by "combine both"? Do you mean support both hashed and unhashed trie puts for StateManager?
I meant: combine both ideas 🙂, so using the Trie library in an unhashed fashion (idea 1) and then put this in the StateManager (idea 2).
That was not a super-thought-through works-for-sure suggestion though, so I am neither sure if this has caveats or works at all. I just threw this in the ring as an additional eventual option, feel free to discard immediately if not fitting. 😋
@holgerd77 If I understand correctly, you are saying initialize the StateManager with useKeyHashing set to false, which means that if an address is passed in, it will have to be hashed before putting it, and if an already hashed key is passed in, it can just be put immediately, since it's not necessary to rehash it. Please correct me if I have misunderstood you.
The above seems like the best way to do it. One possible alternative is to just parameterize useKeyHashing for StateManager, though this would be less flexible since it won't give the hybrid option of putting by both address as well as hash.
Looking at the code, it seems like we can wrap all inputs for address with a function that returns the hash if it is an address or just the hash itself if it is already a hash. @jochem-brouwer do you see any potential blockers or shortcomings with this implementation approach? I'd be happy to work on this ticket if there are no immediate takers.