-
Notifications
You must be signed in to change notification settings - Fork 81
feat(l1): process blocks in batches when syncing and importing #2174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Lines of code reportTotal lines added: Detailed view
|
crates/blockchain/blockchain.rs
Outdated
// todo only execute transactions | ||
// batch account updates to merge the repeated accounts | ||
self.storage | ||
.apply_account_updates_to_trie(&account_updates, &mut state_trie)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I understand now. I was hoping we could just call: https://github.com/lambdaclass/lambda_ethereum_rust/blob/0acc5e28b861f88c30cebb6cbfe0230970df25ed/crates/vm/backends/revm.rs#L96 get_state_transitions
only once.
We would need to add a execute_blocks
inside vm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can discuss this later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried this approach but it won't work without making larger modifications to the vm backend.
we were missing to set the cannonical block hash for the number
19e3593
to
6c037c7
Compare
Motivation
Accelerate syncing!
Description
This PR introduces block batching during full sync:
n
blocks instead of one per block (we'll need less storage also).should_commit_intermediate_tries
. When set to true, it stores the tries for each block. This functionality is added to make the hive test pass. Currently, this is handled by verifying if the block is within theSTATE_TRIES_TO_KEEP
range. In a real syncing scenario, my intuition is that it would be better to wait until we are fully synced and then we would start storing the state of the new blocks and pruning when we reachSTATE_TRIES_TO_KEEP
.Considerations:
Optimize account updates: Instead of inserting updates into the state trie after each block execution, batch them at the end, merging repeated accounts to reduce insertions and improve performance (see Optimize account updates inCloses Optimize account updates inadd_blocks_in_batch
#2216)add_blocks_in_batch
#2216.add_blocks_in_batch
#2217).levm
backend we need it to cache the executions state and persist it between them, as we don't store anything until the final of the batch (see Makeadd_blocks_in_batch
work for LEVM #2218).head
branch usingimport-in-batch
Closes None