2024-09-09 09:12:56 +00:00
|
|
|
# Nimbus
|
|
|
|
# Copyright (c) 2023-2024 Status Research & Development GmbH
|
|
|
|
# Licensed and distributed under either of
|
|
|
|
# * MIT license (license terms in the root directory or at
|
|
|
|
# https://opensource.org/licenses/MIT).
|
|
|
|
# * Apache v2 license (license terms in the root directory or at
|
|
|
|
# https://www.apache.org/licenses/LICENSE-2.0).
|
|
|
|
# at your option. This file may not be copied, modified, or distributed
|
|
|
|
# except according to those terms.
|
|
|
|
|
|
|
|
{.push raises:[].}
|
|
|
|
|
|
|
|
import
|
|
|
|
pkg/[chronicles, chronos],
|
|
|
|
pkg/eth/[common, rlp],
|
2024-11-01 19:18:41 +00:00
|
|
|
pkg/stew/[byteutils, sorted_set],
|
2024-10-17 17:59:50 +00:00
|
|
|
../../../core/chain,
|
2024-09-09 09:12:56 +00:00
|
|
|
../worker_desc,
|
|
|
|
./update/metrics,
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
./blocks_staged/staged_queue,
|
2024-10-28 16:22:04 +00:00
|
|
|
./headers_staged/staged_queue,
|
2024-11-01 19:18:41 +00:00
|
|
|
"."/[blocks_unproc, db, headers_unproc, helpers]
|
2024-09-09 09:12:56 +00:00
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Private functions
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
2024-12-12 17:35:10 +00:00
|
|
|
proc syncState(ctx: BeaconCtxRef; info: static[string]): SyncLayoutState =
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## Calculate `SyncLayoutState` from the download context
|
|
|
|
|
|
|
|
let
|
|
|
|
b = ctx.chain.baseNumber()
|
|
|
|
l = ctx.chain.latestNumber()
|
|
|
|
c = ctx.layout.coupler
|
|
|
|
d = ctx.layout.dangling
|
|
|
|
h = ctx.layout.head
|
|
|
|
|
|
|
|
# See clause *(8)* in `README.md`:
|
|
|
|
# ::
|
|
|
|
# 0 H L
|
|
|
|
# o---------------o----o
|
|
|
|
# | <--- imported ---> |
|
|
|
|
#
|
|
|
|
# where `H << L` with `L` is the `latest` (aka cursor) parameter from
|
|
|
|
# `FC` the logic will be updated to (see clause *(9)* in `README.md`):
|
|
|
|
#
|
|
|
|
if h <= c or h <= l: # empty interval `(C,H]` or nothing to do
|
|
|
|
return idleSyncState
|
|
|
|
|
|
|
|
# See clauses *(9)* and *(10)* in `README.md`:
|
|
|
|
# ::
|
|
|
|
# 0 B
|
|
|
|
# o---------------o----o
|
|
|
|
# | <--- imported ---> |
|
|
|
|
# C D H
|
|
|
|
# o---------------------o----------------o
|
|
|
|
# | <-- unprocessed --> | <-- linked --> |
|
|
|
|
#
|
|
|
|
# where *B* is the **base** entity of the `FC` module and `C` is sort of
|
|
|
|
# a placehoder with block number equal to *B* at some earlier time (the
|
|
|
|
# value *B* increases over time.)
|
|
|
|
#
|
|
|
|
# It is already known that `C < H` (see first check)
|
|
|
|
#
|
|
|
|
if c <= b: # check for `C <= B` as sketched above
|
|
|
|
|
|
|
|
# Case `C < D-1` => not ready yet
|
|
|
|
if c + 1 < d:
|
|
|
|
return collectingHeaders
|
|
|
|
|
|
|
|
# Case `C == D-1` => just finished the download
|
|
|
|
if c + 1 == d:
|
|
|
|
return finishedHeaders
|
|
|
|
|
|
|
|
# Case `C == D` => see below for general case
|
|
|
|
|
|
|
|
# Case `C == D` => set to import blocks (see *(10)* in `README.md`):
|
|
|
|
# ::
|
|
|
|
# 0 L
|
|
|
|
# o--------------------o
|
|
|
|
# | <--- imported ---> |
|
|
|
|
# D
|
|
|
|
# C H
|
|
|
|
# o--------------------------------o
|
|
|
|
# | <-- blocks to be completed --> |
|
|
|
|
#
|
|
|
|
# It is known already (see first check) that `L <`H`
|
|
|
|
#
|
|
|
|
if c == d:
|
|
|
|
return processingBlocks
|
|
|
|
|
|
|
|
# Case `B < C` oops:
|
|
|
|
# ::
|
|
|
|
# 0 B
|
|
|
|
# o---------------o----o
|
|
|
|
# | <--- imported ---> |
|
|
|
|
# C D H
|
|
|
|
# o---------------------o----------------o
|
|
|
|
# | <-- unprocessed --> | <-- linked --> |
|
|
|
|
#
|
2024-12-12 17:35:10 +00:00
|
|
|
debug info & ": inconsistent state",
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
B=(if b == c: "C" else: b.bnStr),
|
|
|
|
C=(if c == l: "L" else: c.bnStr),
|
|
|
|
L=(if l == d: "D" else: l.bnStr),
|
|
|
|
D=(if d == h: "H" else: d.bnStr),
|
|
|
|
H=h.bnStr
|
|
|
|
|
|
|
|
idleSyncState
|
|
|
|
|
|
|
|
# ------------
|
|
|
|
|
|
|
|
proc startHibernating(ctx: BeaconCtxRef; info: static[string]) =
|
|
|
|
## Clean up target bucket and await a new target.
|
2024-09-09 09:12:56 +00:00
|
|
|
##
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
ctx.sst.reset # => target.reset, layout.reset
|
|
|
|
ctx.headersUnprocClear()
|
|
|
|
ctx.blocksUnprocClear()
|
|
|
|
ctx.headersStagedQueueClear()
|
|
|
|
ctx.blocksStagedQueueClear()
|
|
|
|
ctx.dbHeadersClear()
|
|
|
|
|
|
|
|
ctx.hibernate = true
|
|
|
|
|
2024-12-12 17:35:10 +00:00
|
|
|
debug info & ": suspending syncer", L=ctx.chain.latestNumber.bnStr
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
|
|
|
|
# Update, so it can be followed nicely
|
|
|
|
ctx.updateMetrics()
|
|
|
|
|
|
|
|
|
|
|
|
proc setupCollectingHeaders(ctx: BeaconCtxRef; info: static[string]) =
|
|
|
|
## Set up sync target (see clause *(9)* in `README.md`) by modifying
|
|
|
|
## layout to:
|
2024-09-09 09:12:56 +00:00
|
|
|
## ::
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## 0 B
|
|
|
|
## o------------o-------o
|
|
|
|
## | <--- imported ---> | D
|
|
|
|
## C H
|
|
|
|
## o-----------------------------------o
|
|
|
|
## | <--------- unprocessed ---------> |
|
|
|
|
##
|
|
|
|
## where *B* is the **base** entity of the `FC` module and `C ~ B`. The
|
|
|
|
## parameter `H` is set to the new sync head target `T`.
|
2024-09-09 09:12:56 +00:00
|
|
|
##
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
let
|
|
|
|
c = ctx.chain.baseNumber()
|
|
|
|
h = ctx.target.consHead.number
|
|
|
|
|
|
|
|
if c+1 < h: # header chain interval is `(C,H]`
|
|
|
|
doAssert ctx.headersUnprocTotal() == 0
|
|
|
|
doAssert ctx.headersUnprocBorrowed() == 0
|
|
|
|
doAssert ctx.headersStagedQueueIsEmpty()
|
|
|
|
doAssert ctx.blocksUnprocTotal() == 0
|
|
|
|
doAssert ctx.blocksUnprocBorrowed() == 0
|
|
|
|
doAssert ctx.blocksStagedQueueIsEmpty()
|
|
|
|
|
|
|
|
ctx.sst.layout = SyncStateLayout(
|
|
|
|
coupler: c,
|
|
|
|
dangling: h,
|
|
|
|
final: ctx.target.final,
|
|
|
|
finalHash: ctx.target.finalHash,
|
|
|
|
head: h,
|
|
|
|
lastState: collectingHeaders) # state transition
|
|
|
|
|
|
|
|
# Save this header on the database so it needs not be fetched again from
|
|
|
|
# somewhere else.
|
|
|
|
ctx.dbHeadersStash(h, @[rlp.encode(ctx.target.consHead)], info)
|
|
|
|
|
|
|
|
# Save state
|
|
|
|
ctx.dbStoreSyncStateLayout info
|
|
|
|
|
|
|
|
# Update range
|
|
|
|
ctx.headersUnprocSet(c+1, h-1)
|
|
|
|
|
|
|
|
# Update, so it can be followed nicely
|
|
|
|
ctx.updateMetrics()
|
|
|
|
|
|
|
|
# Mark target used, reset for re-fill
|
|
|
|
ctx.target.changed = false
|
|
|
|
|
|
|
|
trace info & ": new header target", C=c.bnStr, D="H", H="T", T=h.bnStr
|
|
|
|
|
|
|
|
|
|
|
|
proc linkIntoFc(ctx: BeaconCtxRef; info: static[string]): bool =
|
|
|
|
## Link `(C,H]` into the `FC` logic. If successful, `true` is returned.
|
|
|
|
## Otherwise the chain `(C,H]` must be discarded.
|
|
|
|
##
|
|
|
|
## Condider the following layout (see clause *(10)* in `README.md`):
|
2024-09-09 09:12:56 +00:00
|
|
|
## ::
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## 0 B Y L
|
|
|
|
## o-------------o--o----o
|
|
|
|
## | <--- imported ----> |
|
|
|
|
## C Z H
|
|
|
|
## o----o--------------------------------o
|
|
|
|
## | <------------- linked ------------> |
|
2024-09-09 09:12:56 +00:00
|
|
|
##
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## for some `Y` in `[B,L]` and `Z` in `(C,H]` where `Y<-Z` with `L` the
|
|
|
|
## `latest` and `B` the `base` entity of the `FC` logic.
|
2024-09-09 09:12:56 +00:00
|
|
|
##
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## If there are such `Y <- Z`, then update the sync state to (see chause
|
|
|
|
## *(11)* in `README.md`):
|
2024-09-09 09:12:56 +00:00
|
|
|
## ::
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## 0 Y
|
|
|
|
## o----------------o----o
|
|
|
|
## | <--- imported ----> |
|
|
|
|
## D
|
|
|
|
## C Z H
|
|
|
|
## o-o------------------------------o
|
|
|
|
## | <-- blocks to be completed --> |
|
|
|
|
##
|
|
|
|
## where `C==Y`, `(C,H]==[Z,H]`, `C<-Z`
|
2024-09-09 09:12:56 +00:00
|
|
|
##
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
## Otherwise, if *Z* does not exists then reset to idle state.
|
|
|
|
##
|
|
|
|
let
|
|
|
|
b = ctx.chain.baseNumber()
|
|
|
|
l = ctx.chain.latestNumber()
|
|
|
|
c = ctx.layout.coupler
|
|
|
|
h = ctx.layout.head
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
if l < h:
|
|
|
|
# Try to find a parent in the `FC` data domain. For practical reasons the
|
|
|
|
# loop does not go further back than the base `B`. Blocks below/older than
|
|
|
|
# that will not be handled by the `FC`.
|
|
|
|
for bn in (l+1).countdown(max(b,c)):
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# The syncer cache holds headers for `(C,H]`. It starts with checking
|
|
|
|
# whether `L<-Z` holds (i.e. `Y==L` can be chosen.)
|
|
|
|
let
|
|
|
|
yHash = ctx.dbHeaderParentHash(bn).expect "Hash32" # maybe `Y`
|
|
|
|
yHdr = ctx.chain.headerByHash(yHash).valueOr: continue # test for `Y`
|
|
|
|
yNum = yHdr.number # == bn-1
|
|
|
|
|
|
|
|
ctx.layout.coupler = yNum # parent of `Z`
|
|
|
|
ctx.layout.dangling = yNum # .. ditto
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
trace info & ": linked into FC", B=b.bnStr,
|
|
|
|
C=(if yNum==l: "L" else: yNum.bnStr), L=l.bnStr, H=h.bnStr
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# Save layout state
|
|
|
|
ctx.dbStoreSyncStateLayout info
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# Update, so it can be followed nicely
|
|
|
|
ctx.updateMetrics()
|
|
|
|
return true
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
trace info & ": cannot link into FC", B=b.bnStr, L=l.bnStr,
|
|
|
|
C=c.bnStr, H=h.bnStr
|
|
|
|
false
|
2024-09-09 09:12:56 +00:00
|
|
|
|
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
proc setupProcessingBlocks(ctx: BeaconCtxRef; info: static[string]) =
|
Flare sync (#2627)
* Cosmetics, small fixes, add stashed headers verifier
* Remove direct `Era1` support
why:
Era1 is indirectly supported by using the import tool before syncing.
* Clarify database persistent save function.
why:
Function relied on the last saved state block number which was wrong.
It now relies on the tx-level. If it is 0, then data are saved directly.
Otherwise the task that owns the tx will do it.
* Extracted configuration constants into separate file
* Enable single peer mode for debugging
* Fix peer losing issue in multi-mode
details:
Running concurrent download peers was previously programmed as running
a batch downloading and storing ~8k headers and then leaving the `async`
function to be restarted by a scheduler.
This was unfortunate because of occasionally occurring long waiting
times for restart.
While the time gap until restarting were typically observed a few
millisecs, there were always a few outliers which well exceed several
seconds. This seemed to let remote peers run into timeouts.
* Prefix function names `unprocXxx()` and `stagedYyy()` by `headers`
why:
There will be other `unproc` and `staged` modules.
* Remove cruft, update logging
* Fix accounting issue
details:
When staging after fetching headers from the network, there was an off
by 1 error occurring when the result was by one smaller than requested.
Also, a whole range was mis-accounted when a peer was terminating
connection immediately after responding.
* Fix slow/error header accounting when fetching
why:
Originally set for detecting slow headers in a row, the counter
was wrongly extended to general errors.
* Ban peers for a while that respond with too few headers continuously
why:
Some peers only returned one header at a time. If these peers sit on a
farm, they might collectively slow down the download process.
* Update RPC beacon header updater
why:
Old function hook has slightly changed its meaning since it was used
for snap sync. Also, the old hook is used by other functions already.
* Limit number of peers or set to single peer mode
details:
Merge several concepts, single peer mode being one of it.
* Some code clean up, fixings for removing of compiler warnings
* De-noise header fetch related sources
why:
Header download looks relatively stable, so general debugging is not
needed, anymore. This is the equivalent of removing the scaffold from
the part of the building where work has completed.
* More clean up and code prettification for headers stuff
* Implement body fetch and block import
details:
Available headers are used stage blocks by combining existing headers
with newly fetched blocks. Then these blocks are imported/executed via
`persistBlocks()`.
* Logger cosmetics and cleanup
* Remove staged block queue debugging
details:
Feature still available, just not executed anymore
* Docu, logging update
* Update/simplify `runDaemon()`
* Re-calibrate block body requests and soft config for import blocks batch
why:
* For fetching, larger fetch requests are mostly truncated anyway on
MainNet.
* For executing, smaller batch sizes reduce the memory needed for the
price of longer execution times.
* Update metrics counters
* Docu update
* Some fixes, formatting updates, etc.
* Update `borrowed` type: uint -. uint64
also:
Always convert to `uint64` rather than `uint` where appropriate
2024-09-27 15:07:42 +00:00
|
|
|
doAssert ctx.headersUnprocTotal() == 0
|
|
|
|
doAssert ctx.headersUnprocBorrowed() == 0
|
|
|
|
doAssert ctx.headersStagedQueueIsEmpty()
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
doAssert ctx.blocksUnprocTotal() == 0
|
|
|
|
doAssert ctx.blocksUnprocBorrowed() == 0
|
|
|
|
doAssert ctx.blocksStagedQueueIsEmpty()
|
Flare sync (#2627)
* Cosmetics, small fixes, add stashed headers verifier
* Remove direct `Era1` support
why:
Era1 is indirectly supported by using the import tool before syncing.
* Clarify database persistent save function.
why:
Function relied on the last saved state block number which was wrong.
It now relies on the tx-level. If it is 0, then data are saved directly.
Otherwise the task that owns the tx will do it.
* Extracted configuration constants into separate file
* Enable single peer mode for debugging
* Fix peer losing issue in multi-mode
details:
Running concurrent download peers was previously programmed as running
a batch downloading and storing ~8k headers and then leaving the `async`
function to be restarted by a scheduler.
This was unfortunate because of occasionally occurring long waiting
times for restart.
While the time gap until restarting were typically observed a few
millisecs, there were always a few outliers which well exceed several
seconds. This seemed to let remote peers run into timeouts.
* Prefix function names `unprocXxx()` and `stagedYyy()` by `headers`
why:
There will be other `unproc` and `staged` modules.
* Remove cruft, update logging
* Fix accounting issue
details:
When staging after fetching headers from the network, there was an off
by 1 error occurring when the result was by one smaller than requested.
Also, a whole range was mis-accounted when a peer was terminating
connection immediately after responding.
* Fix slow/error header accounting when fetching
why:
Originally set for detecting slow headers in a row, the counter
was wrongly extended to general errors.
* Ban peers for a while that respond with too few headers continuously
why:
Some peers only returned one header at a time. If these peers sit on a
farm, they might collectively slow down the download process.
* Update RPC beacon header updater
why:
Old function hook has slightly changed its meaning since it was used
for snap sync. Also, the old hook is used by other functions already.
* Limit number of peers or set to single peer mode
details:
Merge several concepts, single peer mode being one of it.
* Some code clean up, fixings for removing of compiler warnings
* De-noise header fetch related sources
why:
Header download looks relatively stable, so general debugging is not
needed, anymore. This is the equivalent of removing the scaffold from
the part of the building where work has completed.
* More clean up and code prettification for headers stuff
* Implement body fetch and block import
details:
Available headers are used stage blocks by combining existing headers
with newly fetched blocks. Then these blocks are imported/executed via
`persistBlocks()`.
* Logger cosmetics and cleanup
* Remove staged block queue debugging
details:
Feature still available, just not executed anymore
* Docu, logging update
* Update/simplify `runDaemon()`
* Re-calibrate block body requests and soft config for import blocks batch
why:
* For fetching, larger fetch requests are mostly truncated anyway on
MainNet.
* For executing, smaller batch sizes reduce the memory needed for the
price of longer execution times.
* Update metrics counters
* Docu update
* Some fixes, formatting updates, etc.
* Update `borrowed` type: uint -. uint64
also:
Always convert to `uint64` rather than `uint` where appropriate
2024-09-27 15:07:42 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
let
|
|
|
|
c = ctx.layout.coupler
|
|
|
|
h = ctx.layout.head
|
2024-11-01 19:18:41 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# Update blocks `(C,H]`
|
|
|
|
ctx.blocksUnprocCommit(0, c+1, h)
|
2024-11-01 19:18:41 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# State transition
|
|
|
|
ctx.layout.lastState = processingBlocks
|
2024-11-01 19:18:41 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
trace info & ": collecting block bodies", iv=BnRange.new(c+1, h)
|
2024-11-01 19:18:41 +00:00
|
|
|
|
2024-09-09 09:12:56 +00:00
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Public functions
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
proc updateSyncState*(ctx: BeaconCtxRef; info: static[string]) =
|
|
|
|
## Update internal state when needed
|
|
|
|
let
|
|
|
|
prevState = ctx.layout.lastState # previous state
|
|
|
|
thisState = ctx.syncState info # currently observed state
|
|
|
|
|
|
|
|
if thisState == prevState:
|
|
|
|
# Check whether the system has been idle and a new header download
|
|
|
|
# session can be set up
|
|
|
|
if prevState == idleSyncState and
|
|
|
|
ctx.target.changed and # and there is a new target from CL
|
|
|
|
ctx.target.final != 0: # .. ditto
|
|
|
|
ctx.setupCollectingHeaders info # set up new header sync
|
|
|
|
return
|
|
|
|
# Notreached
|
|
|
|
|
2024-12-12 17:35:10 +00:00
|
|
|
debug info & ": sync state changed", prevState, thisState,
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
L=ctx.chain.latestNumber.bnStr,
|
|
|
|
C=(if ctx.layout.coupler == ctx.layout.dangling: "D"
|
|
|
|
else: ctx.layout.coupler.bnStr),
|
|
|
|
D=(if ctx.layout.dangling == ctx.layout.head: "H"
|
|
|
|
else: ctx.layout.dangling.bnStr),
|
|
|
|
H=ctx.layout.head.bnStr
|
|
|
|
|
|
|
|
# So there is a states transition. The only relevant transition here
|
|
|
|
# is `collectingHeaders -> finishedHeaders` which will be continued
|
|
|
|
# as `finishedHeaders -> processingBlocks`.
|
|
|
|
#
|
|
|
|
if prevState == collectingHeaders and
|
|
|
|
thisState == finishedHeaders and
|
|
|
|
ctx.linkIntoFc(info): # commit downloading headers
|
|
|
|
ctx.setupProcessingBlocks info # start downloading block bodies
|
2024-12-12 17:35:10 +00:00
|
|
|
debug info & ": sync state changed",
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
prevState=thisState, thisState=ctx.syncState(info)
|
|
|
|
return
|
|
|
|
# Notreached
|
2024-09-09 09:12:56 +00:00
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
# Final sync target reached or inconsistent/impossible state
|
|
|
|
ctx.startHibernating info
|
Flare sync (#2627)
* Cosmetics, small fixes, add stashed headers verifier
* Remove direct `Era1` support
why:
Era1 is indirectly supported by using the import tool before syncing.
* Clarify database persistent save function.
why:
Function relied on the last saved state block number which was wrong.
It now relies on the tx-level. If it is 0, then data are saved directly.
Otherwise the task that owns the tx will do it.
* Extracted configuration constants into separate file
* Enable single peer mode for debugging
* Fix peer losing issue in multi-mode
details:
Running concurrent download peers was previously programmed as running
a batch downloading and storing ~8k headers and then leaving the `async`
function to be restarted by a scheduler.
This was unfortunate because of occasionally occurring long waiting
times for restart.
While the time gap until restarting were typically observed a few
millisecs, there were always a few outliers which well exceed several
seconds. This seemed to let remote peers run into timeouts.
* Prefix function names `unprocXxx()` and `stagedYyy()` by `headers`
why:
There will be other `unproc` and `staged` modules.
* Remove cruft, update logging
* Fix accounting issue
details:
When staging after fetching headers from the network, there was an off
by 1 error occurring when the result was by one smaller than requested.
Also, a whole range was mis-accounted when a peer was terminating
connection immediately after responding.
* Fix slow/error header accounting when fetching
why:
Originally set for detecting slow headers in a row, the counter
was wrongly extended to general errors.
* Ban peers for a while that respond with too few headers continuously
why:
Some peers only returned one header at a time. If these peers sit on a
farm, they might collectively slow down the download process.
* Update RPC beacon header updater
why:
Old function hook has slightly changed its meaning since it was used
for snap sync. Also, the old hook is used by other functions already.
* Limit number of peers or set to single peer mode
details:
Merge several concepts, single peer mode being one of it.
* Some code clean up, fixings for removing of compiler warnings
* De-noise header fetch related sources
why:
Header download looks relatively stable, so general debugging is not
needed, anymore. This is the equivalent of removing the scaffold from
the part of the building where work has completed.
* More clean up and code prettification for headers stuff
* Implement body fetch and block import
details:
Available headers are used stage blocks by combining existing headers
with newly fetched blocks. Then these blocks are imported/executed via
`persistBlocks()`.
* Logger cosmetics and cleanup
* Remove staged block queue debugging
details:
Feature still available, just not executed anymore
* Docu, logging update
* Update/simplify `runDaemon()`
* Re-calibrate block body requests and soft config for import blocks batch
why:
* For fetching, larger fetch requests are mostly truncated anyway on
MainNet.
* For executing, smaller batch sizes reduce the memory needed for the
price of longer execution times.
* Update metrics counters
* Docu update
* Some fixes, formatting updates, etc.
* Update `borrowed` type: uint -. uint64
also:
Always convert to `uint64` rather than `uint` where appropriate
2024-09-27 15:07:42 +00:00
|
|
|
|
|
|
|
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
proc updateFinalBlockHeader*(
|
|
|
|
ctx: BeaconCtxRef;
|
|
|
|
finHdr: Header;
|
|
|
|
finHash: Hash32;
|
|
|
|
info: static[string];
|
|
|
|
) =
|
|
|
|
## Update the finalised header cache. If the finalised header is acceptable,
|
|
|
|
## the syncer will be activated from hibernation if necessary.
|
|
|
|
##
|
|
|
|
let
|
|
|
|
b = ctx.chain.baseNumber()
|
|
|
|
f = finHdr.number
|
|
|
|
if f < b:
|
2024-11-22 13:23:53 +00:00
|
|
|
trace info & ": finalised block # too low",
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
B=b.bnStr, finalised=f.bnStr, delta=(b - f)
|
|
|
|
|
|
|
|
ctx.target.reset
|
|
|
|
|
|
|
|
else:
|
|
|
|
ctx.target.final = f
|
|
|
|
ctx.target.finalHash = finHash
|
|
|
|
|
|
|
|
# Activate running (unless done yet)
|
|
|
|
if ctx.hibernate:
|
|
|
|
ctx.hibernate = false
|
2024-12-12 17:35:10 +00:00
|
|
|
debug info & ": activating syncer", B=b.bnStr,
|
Beacon sync update multi exe heads aware (#2861)
* Log/trace cancellation events in scheduler
* Provide `clear()` functions for explicitly flushing data objects
* Renaming header cache functions
why:
More systematic, all functions start with prefix `dbHeader`
* Remove `danglingParent` from layout
why:
Already provided by header cache
* Remove `couplerHash` and `headHash` from layout
why:
No need to cache, `headHash` is unused and `couplerHash` used typically
once, only.
* Remove `lastLayout` from sync descriptor
why:
No need to compare changes, saving is always triggered after actively
changing the sync layout state
* Early reject unsuitable head + finalised header from CL
why:
The finalised header is only passed by its hash so the header must be
fetched somewhere, e.g. from a peer via eth/xx.
Also, finalised headers earlier than the `base` from `FC` cannot be
handled due to the `Aristo` single state database architecture.
Luckily, on a full node, the complete block history is available so
unsuitable finalised headers are stored there already which is exploited
here to avoid unnecessary network traffic.
* Code cosmetics, remove cruft, prettify logging, remove `final` metrics
detail:
The `final` layout parameter will be deprecated and later removed
* Update/re-calibrate syncer logic documentation
why:
The current implementation sucks if the `FC` module changes the
canonical branch in the middle of completing a header chain (due
to concurrent updates by the `newPayload()` logic.)
* Implement according to re-calibrated syncer docu
details:
The implementation employs the notion of named layout states (see
`SyncLayoutState` in `worker_desc.nim`) which are derived from the
state parameter triple `(C,D,H)` as described in `README.md`.
2024-11-21 16:32:47 +00:00
|
|
|
finalised=f.bnStr, head=ctx.target.consHead.bnStr
|
|
|
|
|
|
|
|
# Update, so it can be followed nicely
|
|
|
|
ctx.updateMetrics()
|
Flare sync (#2627)
* Cosmetics, small fixes, add stashed headers verifier
* Remove direct `Era1` support
why:
Era1 is indirectly supported by using the import tool before syncing.
* Clarify database persistent save function.
why:
Function relied on the last saved state block number which was wrong.
It now relies on the tx-level. If it is 0, then data are saved directly.
Otherwise the task that owns the tx will do it.
* Extracted configuration constants into separate file
* Enable single peer mode for debugging
* Fix peer losing issue in multi-mode
details:
Running concurrent download peers was previously programmed as running
a batch downloading and storing ~8k headers and then leaving the `async`
function to be restarted by a scheduler.
This was unfortunate because of occasionally occurring long waiting
times for restart.
While the time gap until restarting were typically observed a few
millisecs, there were always a few outliers which well exceed several
seconds. This seemed to let remote peers run into timeouts.
* Prefix function names `unprocXxx()` and `stagedYyy()` by `headers`
why:
There will be other `unproc` and `staged` modules.
* Remove cruft, update logging
* Fix accounting issue
details:
When staging after fetching headers from the network, there was an off
by 1 error occurring when the result was by one smaller than requested.
Also, a whole range was mis-accounted when a peer was terminating
connection immediately after responding.
* Fix slow/error header accounting when fetching
why:
Originally set for detecting slow headers in a row, the counter
was wrongly extended to general errors.
* Ban peers for a while that respond with too few headers continuously
why:
Some peers only returned one header at a time. If these peers sit on a
farm, they might collectively slow down the download process.
* Update RPC beacon header updater
why:
Old function hook has slightly changed its meaning since it was used
for snap sync. Also, the old hook is used by other functions already.
* Limit number of peers or set to single peer mode
details:
Merge several concepts, single peer mode being one of it.
* Some code clean up, fixings for removing of compiler warnings
* De-noise header fetch related sources
why:
Header download looks relatively stable, so general debugging is not
needed, anymore. This is the equivalent of removing the scaffold from
the part of the building where work has completed.
* More clean up and code prettification for headers stuff
* Implement body fetch and block import
details:
Available headers are used stage blocks by combining existing headers
with newly fetched blocks. Then these blocks are imported/executed via
`persistBlocks()`.
* Logger cosmetics and cleanup
* Remove staged block queue debugging
details:
Feature still available, just not executed anymore
* Docu, logging update
* Update/simplify `runDaemon()`
* Re-calibrate block body requests and soft config for import blocks batch
why:
* For fetching, larger fetch requests are mostly truncated anyway on
MainNet.
* For executing, smaller batch sizes reduce the memory needed for the
price of longer execution times.
* Update metrics counters
* Docu update
* Some fixes, formatting updates, etc.
* Update `borrowed` type: uint -. uint64
also:
Always convert to `uint64` rather than `uint` where appropriate
2024-09-27 15:07:42 +00:00
|
|
|
|
2024-09-09 09:12:56 +00:00
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# End
|
|
|
|
# ------------------------------------------------------------------------------
|