nimbus-eth1/nimbus/sync/beacon/worker
Jordan Hrycaj ea268e81ff
Beacon sync activation control update (#2782)
* Clarifying/commenting FCU setup condition & small fixes, comments etc.

* Update some logging

* Reorg metrics updater and activation

* Better `async` responsiveness

why:
  Block import does not allow `async` task activation while
  executing. So allow potential switch after each imported
  block (rather than a group of 32 blocks.)

* Handle resuming after previous sync followed by import

why:
  In this case the ledger state is more recent than the saved
  sync state. So this is considered a pristine sync where any
  previous sync state is forgotten.

  This fixes some assert thrown because of inconsistent internal
  state at some point.

* Provide option for clearing saved beacon sync state before starting syncer

why:
  It would resume with the last state otherwise which might be undesired
  sometimes.

  Without RPC available, the syncer typically stops and terminates with
  the canonical head larger than the base/finalised head. The latter one
  will be saved as database/ledger state and the canonical head as syncer
  target. Resuming syncing here will repeat itself.

  So clearing the syncer state can prevent from starting the syncer
  unnecessarily avoiding useless actions.

* Allow workers to request syncer shutdown from within

why:
  In one-trick-pony mode (after resuming without RPC support) the
  syncer can be stopped from within soavoiding unnecessary polling.
  In that case, the syncer can (theoretically) be restarted externally
  with `startSync()`.

* Terminate beacon sync after a single run target is reached

why:
  Stops doing useless polling (typically when there is no RPC available)

* Remove crufty comments

* Tighten state reload condition when resuming

why:
  Some pathological case might apply if the syncer is stopped while the
  distance between finalised block and head is very large and the FCU
  base becomes larger than the locked finalised state.

* Verify that finalised number from CL is at least FCU base number

why:
  The FCU base number is determined by the database, non zero if
  manually imported. The finalised number is passed via RPC by the CL
  node and will increase over time. Unless fully synced, this number
  will be pretty low.

  On the other hand, the FCU call `forkChoice()` will eventually fail
  if the `finalizedHash` argument refers to something outside the
  internal chain starting at the FCU base block.

* Remove support for completing interrupted sync without RPC support

why:
  Simplifies start/stop logic

* Rmove unused import
2024-10-28 16:22:04 +00:00
..
blocks_staged Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
headers_staged Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
start_stop Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
update Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
blocks_staged.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
blocks_unproc.nim Beacon sync block import via forked chain (#2747) 2024-10-17 17:59:50 +00:00
db.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
headers_staged.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
headers_unproc.nim Beacon sync block import via forked chain (#2747) 2024-10-17 17:59:50 +00:00
helpers.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
start_stop.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00
update.nim Beacon sync activation control update (#2782) 2024-10-28 16:22:04 +00:00