The basic scheduler has shown weakness when handling high load, which
manifests with the occasional deadlock situation. This introduces an
advanced scheduler, which contains additional features in an attempt to
ensure that regardless of the concurrent load no job is ever left in an
inconsistent state, explicitly with outstanding items to read on its
channels.
The Dirk accountmanager was using a local scatter/gather concurrency
method to obtain wallets, however this uses the parallelism of the Vouch
server rather than the Dirk server. This chnages the Dirk
accountmanager to use a configuration value to select the concurrency
level.
This also standardizes the use of process concurency to allow for
hierarchical definition of the value.
Specification imports for phase0 were aliased as 'spec'. Due to the
mechanism decided upon to manage structs that vary beteween hard forks
this is no longer useful, so this removes the alias in preparation for
the Altair hard fork.
Accounts and distributed accounts were bundled up together for signing.
This was non-optimal, as they have different requirements (single shot
Vs. distributed threshold). This separates them in to two groups, and
signs them as separate sets of requests.
If a Vouch instance has many wallets it can be slow to start up, as
wallet information is fetched in sequence. This changes the methodology
to fetch wallets to be parallel, allowing for faster startup times even
when there are many wallets in use.
If Vouch contains a list of validators, and on refresh obtains an empty
list, assume the empty response is a result of an error and do not
remove the existing list in favor of it.
It is possible for network issues to result in an empty response when
requesting an update on the list of validators for which Vouch should
operate. In this situation, where Vouch already has a list of
validators, it retains that list rather than replace it with the empty
results of the request.
(cherry picked from commit 52c58216cb)
If a validator is due to propose a block but cannot obtain the RANDO
reveal it causes Vouch to crash. This change checks for an empty RANDAO
reveal and exits early from the block proposal process on such a
condition.
Fixes#15.
(cherry picked from commit fb2d95e97b)
`vouch_ready` is a prometheus metric that is `0` if Vouch is not yet
ready to validate, and `1` if it is.
`vouch_release` has a labeled value `version` that contains the release
version of Vouch.
When a chain reorganisation occurs it is possible that this impacts
Vouch's attestations and proposals for the current and next epoch. This
patch listens to the Ethereum 2 events stream for reorganisation
notifications. If it finds one it cancels existing and creates new
duties, as required.
This option allows users to control the maximum amount of time that
Vouch will wait for a block to arrive before starting its attestation
process. Note that this is a spec value, so changes can have a highly
detrimental impact on Vouch's behaviour.
This removes a mutex lock followed by an unlock that has no code
inbetween. This was a remnant from when job management was handled
within the control function, and is no longer required.
This adds a label `epoch_slot` to the prometheus metric
`vouch_block_receipt_delay_seconds`. It has been noted that the receipt
delay is often significantly higher for the first (and, to a lesser
extent, second) slot in a given epoch. This allows the receipt delay to
be examined for specific slots in a given epoch.
The "best" aggregate attestation strategy obtains aggregate attestations
from all listed nodes, scores them according to their attestation
coverage, and signs and broadcasts the one with the highest coverage.
The "first" aggregate attestation strategy signs and broadcasts the
first aggregate attestation returned from all listed nodes.
This metric used to count the number of internal attestation processes
carried out, however a single attestation process can involve multiple
validators if they are attesting in the same slot and committee. This
fix ensures that the metrics reflect the number of attestations, not the
number of processes.
This reintroduces prometheus metrics for the account manager module.
The metrics track the validating state of each account, and are found
under the `vouch_accountmanager_accounts_total` metric. The metrics are
differentiated using the `state` label.
Jim McDonald
Gary Rowe