nimbus-eth1/nimbus/sync/snap
Jordan Hrycaj 7688148565
Snap sync can start on saved checkpoint (#1327)
* Stop negotiating pivot if peer repeatedly replies w/usesless answers

why:
  There is some fringe condition where a peer replies with legit but
  useless empty headers repetely. This goes on until somebody stops.
  We stop now.

* Rename `missingNodes` => `sickSubTries`

why:
  These (probably missing) nodes represent in reality fully or partially
  missing sub-tries. The top nodes may even exist, e.g. as a shallow
  sub-trie.

also:
  Keep track of account healing on/of by bool variable `accountsHealing`
  controlled in `pivot_helper.execSnapSyncAction()`

* Add `nimbus` option argument `snapCtx` for starting snap recovery (if any)

also:
+ Trigger the recovery (or similar) process from inside the global peer
  worker initialisation `worker.setup()` and not by the `snap.start()`
  function.
+ Have `runPool()` returned a `bool` code to indicate early stop to
  scheduler.

* Can import partial snap sync checkpoint at start

details:
 + Modified what is stored with the checkpoint in `snapdb_pivot.nim`
 + Will be loaded within `runDaemon()` if activated

* Forgot to import total coverage range

why:
  Only the top (or latest) pivot needs coverage but the total coverage
  is the list of all ranges for all pivots -- simply forgotten.
2022-11-25 14:56:42 +00:00
..
worker Snap sync can start on saved checkpoint (#1327) 2022-11-25 14:56:42 +00:00
constants.nim Snap sync can start on saved checkpoint (#1327) 2022-11-25 14:56:42 +00:00
range_desc.nim Snap sync can start on saved checkpoint (#1327) 2022-11-25 14:56:42 +00:00
worker.nim Snap sync can start on saved checkpoint (#1327) 2022-11-25 14:56:42 +00:00
worker_desc.nim Snap sync can start on saved checkpoint (#1327) 2022-11-25 14:56:42 +00:00