* stubbed SelectRelayChain
* disconnected overseer handlers
* add is_disconnected
* add fallback in case overseer is disconnected
* fall back on fallback
* fetch leaves by calling into chain-selection subsystem
* implement best_chain
* mostly implement finality_target
* chain constrain
* metrics and maximum safeguard
* remove review comment after review
* node/approval-voting: Introduce LruCache for pending Approval work
This commit adds an LruCache that is intended to track the approval work
submitted as background tasks in order to ensure that the validator needn't
launch duplicate approval work for the same candidate across multiple blocks.
A simple state machine is also introduced in order to differentiate pending
and completed tasks. In addition, this LruCache will retain ValidationResults
from the completed approval work once the task has completed. As per LruCache
implementation, the oldest tasks will get evicted as new approval work is
submitted to this cache.
* node/approval-voting: Revert changes to master
This commit reverts changes from the previous commit in order
to simplify addressing the architecture discussion raised in the PR.
* node/approval-voting: remove background task mpsc construct
This diff removes the mpsc construct for background tasks in preparation
for a move to leveraging RemoteHandles to launch approvals, rather than
passing ApprovalRequests to a mpsc channel and handling the ApprovalRequests
in the main subsystem task.
* node/approval-voting: Introduce LRU Cache
This commit introduces an LRU Cache but does not yet make use of it.
* node/approval-voting: Remove BackgroundTasksMap and memoize currently_checking
This commit removes the BackgroundTasksMap in the main subsystem task
and introduces a method to keep track of RemoteHandles in such a way that
we can ensure that a task is spawned once for a CandidateHash and
relay parent tuple.
* node/approval-voting: Remove BackgroundTasksMap and memoize currently_checking
This commit removes the BackgroundTasksMap in the main subsystem task
and introduces a map of FuturesUnordered per BlockNumber. In addition,
a FusedFuture is generated by iterating across all FuturesUnordered for
the BlockNumbers for which at least one candidate has approvals work
running in the subsystem.
* node/approval-voting: Address Rob's comments
This diff removes the prior HashMap<BlockNumber, FuturesUnordered>
construction and instead moves to a simple FuturesUnordered where
all the work is await with Timeout.
* node/approval-voting: Update Cargo.lock
Due to a mismatch in rustc versions
* node/approval-voting: Make use of actions when issuing_approval
This commit fixes a small oversight in the logic of the prior commit.
* node/approval-voting: Address Rob's feedback
* node/approval-voting: Introduce lazy launch_approval evaluation
* node/approval-voting: Send DistibruteApproval message on every LaunchApproval
In addition to fixed the DistributeApproval bug, this commit also
increases the size of the approvals cache and ensures the StaleGuard
is removed when the advantageous approval state is reached.
* node/approval-voting: Address final comments
This commit removes the CandidateIndex from the ApprovalVoteRequest.
Instead, the launch_approval function will compute the candidate_index
from the block entry.
In addition, a comment has been added explaining the difficulty of
issuing approvals in the handle_actions function.
* node/approval-voting: Set timeout to be 120s rather than 2s
* Update Cargo.lock
* Dispute distribution initial design.
* WIP.
* Dispute distribution guide update.
* Make invalid statement include `InvalidStatementKind`.
* Clarify the scope of disputes.
* A few fixes + introduced back pressure oneshot.
* Fixes and spam protection WIP.
* More spam considerations.
* More fixes.
* Fixes + add note about not dispute participating nodes.
* Only fetch one collation at a time per relay parent
Before a validator would fetch all collations that were advertised to
him. This pr changes the behavior to always just fetch one collation at
a time. If fetching fails, the validator will start fetching one of the
other collations.
* Use enum to be more explicit
* Review comments
* crate skeleton and type definitions
* add ChainSelectionMessage
* add error type
* run loop
* fix overseer
* simplify determine_new_blocks API
* write an overlay struct and fetch new blocks
* add new function to overlay
* more flow
* add leaves to overlay and add a strong type around leaves-set
* add is_parent_viable
* implement block import, ignoring reversions
* add stagnant-at to overlay
* add stagnant
* add revert consensus log
* flow for reversions
* extract and import block reversions
* recursively update viability
* remove redundant parameter from WriteBlockEntry
* do some removal of viable leaves
* address grumbles
* refactor
* address grumbles
* add comment about non-monotonicity
* extract backend to submodule
* begin the hunt for viable leaves
* viability pivots for updating the active leaves
* remove LeafSearchFrontier
* partially -> explicitly viable and untwist some booleans
* extract tree to submodule
* implement block finality update
* Implement block approval routine
* implement stagnant detection
* ensure blocks pruned on finality are removed from the active leaves set
* write down some planned test cases
* floww
* leaf loading
* implement best_leaf_containing
* write down a few more tests to do
* remove dependence of tree on header
* guide: ChainApiMessage::BlockWeight
* node: BlockWeight ChainAPI
* fix compile issue
* note a few TODOs for the future
* fetch block weight using new BlockWeight ChainAPI
* implement unimplemented
* sort leaves by block number after weight
* remove warnings and add more TODOs
* create test module
* storage for test backend
* wrap inner in mutex
* add write waker query to test backend
* Add OverseerSignal -> FromOverseer conversion
* add test harnes
* add no-op test
* add some more test helpers
* the first test
* more progress on tests
* test two subtrees
* determine-new-blocks: cleaner genesis avoidance and tighter ancestry requests
* don't make ancestry requests when asking for one block
* add a couple more tests
* add to AllMessages in guide
* remove bad spaces from bridge
* compact iterator
* test import with gaps
* more reversion tests
* test finalization pruning subtrees
* fixups
* test clobbering and fix bug in overlay
* exhaustive backend state after finalizaiton tested
* more finality tests
* leaf tests
* test approval
* test ChainSelectionMessage::Leaves thoroughly
* remove TODO
* avoid Ordering::is_ne so CI can build
* comment algorithmic complexity
* Update node/core/chain-selection/src/lib.rs
Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>
Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>
* node/approval-voting: test for invalid validator index in assignments
This commit adds a unit test to show that, currently, validator indexes
greater than n_validators (or the length of the approvals bitvector) are
counted in n_assignments. In the subsequent commit we will correct this
behavior.
* node/approval-voting: ignore invalid validator indexes in n_assignments
This commit ignores any validator assignments whose index is beyond
n_validators. Without this check, an improperly crafted assignment would
be counted towards the approval.
It still remains that n_assignments and count_no_shows inspect the
number of validators and approvals, respectively. Ideally we would
add greater safety around ensuring these two values cannot differ.
* node/approval-voting: extract and test count_no_shows method
This commit extracts no_show computation into a pure function so that it can be
extensively unit tested.
* node/approval-voting: ignore invalid validator indexes in count_no_show
Previously indexes that were past the length of the approvals bitvector
would contribute to the no_show count or the next_no_show value. This
commit changes the behavior to ignore garbage values.
* node/approval-voting: add comment for next_no_show adding clock_drift
* node/approval_checking: break out filled_tranch_iterator method
In the subsequent commit, we will begin to test this method in
isolation.
* node/approval-voting: fix tranche back-filling algorithm
Previously, this algorithm would generate duplicate, empty entries for
tranches (1..pre_end). This is caused because the initial value (0) for
gap_end is treated as the end of a prior tranche that wasn't actually
processed. The first pass thus would add (1..tranche) empty entries, in
addition to the (0..pre_end) empty entries chained at the end of the
method.
This is fixed by using the current tranche as the gap_start for the
first iteration, ensuring that the approval_entries_filled only produces
entries in the range (pre_end..post_start).
* Address feedback
antonio-dropulic