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): decouple size of execution batch from header request size during full-sync (#3074)
**Motivation**
Allow us to configure the amount of blocks to execute in a single batch
during full sync. Currently, the only way to do this is by changing the
amount of block headers we ask for in each request.
In order to achieve this, this PR proposes adding the enum
`BlockSyncState` with variants for Full and Snap sync so we can separate
behaviors between each mode and also allow each mode to keep its
separate state. This is key as we will need to persist headers and
bodies through various fetch requests so we can build custom-sized
execution batches.
It also replaces the previous configurable env var `BlOCK_HEADER_LIMIT`
with `EXECUTE_BLOCK_BATCH`
<!-- Why does this pull request exist? What are its goals? -->
**Description**
* Add `BlockSyncState` enum as a way to differentiate between each sync
mode's state during block syncing phase.
* Refactor `request_and_validate_block_bodies`: it now receives a slice
of headers and returns the requested block bodies instead of the full
blocks. This allowed us to completely get rid of header cloning.
* `validate_block_body` now receives a reference to the head & body
instead of the full block (as a result of refactoring its only user)
* `Store::add_block_headers` now only receives the headers (This lets us
simplify caller code)
* Removed `search_head` variable as having both current & search head
serves no purpose.
* Abtract current_head selection into `BlockSyncState::get_current_head`
* Fix bug in condition used to decide wether to switch from snap to full
sync
* `start_sync` no longer receives `current_head`
<!-- A clear and concise general description of the changes this PR
introduces -->
<!-- Link to issues: Resolves#111, Resolves#222 -->
Closes#2894
---------
Co-authored-by: SDartayet <[email protected]>
Co-authored-by: Martin Paulucci <[email protected]>
0 commit comments