feat: migrate account state to trie#407
Conversation
mpaulucci
left a comment
There was a problem hiding this comment.
Great work! 🚀 🚀 🚀
As a follow-up, I think we should make a cleaner api that what we have currently in Store, making the Trie just an internal representation that is not leaked to the outside (for example, in the future we might use snapshots to query the state)
For example, we could do something like:
let state_reader = store.get_state_at(block_number);
let info = state_reader.get_account_info(...);
But let's get this merged and then we can do a follow up.
| pub struct StoreWrapper(pub Store); | ||
| pub struct StoreWrapper { | ||
| pub store: Store, | ||
| pub block_number: BlockNumber, |
There was a problem hiding this comment.
I think it makes more sense to store a block_hash here since we might want to execute a block that is not from the canonical chain. Thoughts?
There was a problem hiding this comment.
We only use this field to fetch account_info from the store, which is indexed by block_number, so changing the field to block hash wouldn't fix the issue.
I would leave it to a separate refactor
I don't understand this, the methods exposing the trie are only part of the |
Motivation
Migrate handling of account state from DB tables into a state trie
Description
Refactor how we interact with account state across the codebase:
apply_state_transitionswithget_state_transitions, which returns a list ofAccountUpdatesand add the methodStore::apply_account_updateswhich applies the changes on top of the given block's state and returns the new state root after the updates.Store(such as add_account, remove_account, add_account_info, etc)Storemethods that fetch account state data now receive ablock_numberargument so that historical state can be accessedOther:
withdrawals_root&parent_beacon_block_rootfor non-cancunGenesisCloses #272