You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(l1): process blocks in batches when syncing and importing (#2174)
**Motivation**
Accelerate syncing!
**Description**
This PR introduces block batching during full sync:
1. Instead of storing and computing the state root for each block
individually, we now maintain a single state tree for the entire batch,
committing it only at the end. This results in one state trie per `n`
blocks instead of one per block (we'll need less storage also).
2. The new full sync process:
- Request 1024 headers
- Request 1024 block bodies and collect them
- Once all blocks are received, process them in batches using a single
state trie, which is attached to the last block.
3. Blocks are now stored in a single transaction.
4. State root, receipts root, and request root validation are only
required for the last block in the batch.
5. The new add_blocks_in_batch function includes a flag,
`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 the
`STATE_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
reach `STATE_TRIES_TO_KEEP`.
6. Throughput when syncing is now measured per batches.
7. A new command was added to import blocks in batch
Considerations:
1. ~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
#2216)~ Closes#2216.
2. Improve transaction handling: Avoid committing storage tries to the
database separately. Instead, create a single transaction for storing
receipts, storage tries, and blocks. This would require additional
abstractions for transaction management (see #2217).
3. This isn't working for `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 #2218).
4. In #2210 a new ci is added to run a bench comparing main and `head`
branch using `import-in-batch`
Closes None
---------
Co-authored-by: Martin Paulucci <martin.c.paulucci@gmail.com>
Co-authored-by: fmoletta <99273364+fmoletta@users.noreply.github.com>
0 commit comments