* beefy: use VersionedFinalityProof instead of SignedCommitment.
* Change the exposed RPC API to support versioned proofs.
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* client/beefy: don't accept vote for older rounds
* client/beefy: clean up and reorg the worker struct
* client/beefy: first step towards Full BEEFY
The first step from Lean->Full BEEFY is to have the worker
enforce uninterrupted line of BEEFY finalized mandatory blocks.
There is one mandatory block per session (the first block in the
session). As such, votes processing and votes generation now
enforces that all mandatory blocks are finalized in strict
monotonically increasing sequence and no block 'N' will be worked
on if there is any GRANDPA finalized but BEEFY non-final mandatory
block 'M', where 'M < N'.
Implementation details:
- Introduced 'VoterOracle' to separate the voting decisions logic,
and track new/pending sessions.
- New sessions get queued up with the worker operating either:
1. up-to-date - all mandatory blocks leading up to current GRANDPA
finalized: queue has ONE element, the 'current session' where
`mandatory_done == true`,
2. lagging behind GRANDPA: queue has [1, N] elements, where all
`mandatory_done == false`.
In this state, everytime a session gets its mandatory block
BEEFY finalized, the session is popped off the queue,
eventually getting to operating mode `1. up-to-date`.
- Votes get triaged and those that fall withing the `VoterOracle`
allowed window get processed, the others get dropped if stale,
or buffered for later processing (when they reach the window).
- Worker general code was also updated to fall in one of two roles:
1. react to external events and change internal 'state',
2. generate events/votes based on internal 'state'.
Signed-off-by: acatangiu <adrian@parity.io>
* client/beefy: sketch idea for block import and sync
Signed-off-by: acatangiu <adrian@parity.io>
* client/beefy: add BEEFY block import
* client/beefy: process justifications from block import
* client/beefy: add TODOs for sync protocol
* client/beefy: add more docs and comments
* client/beefy-rpc: fix RPC error
* client/beefy: verify justification validity on block import
* client/beefy: more tests
* client/beefy: small fixes
- first handle and note the self vote before gossiping it,
- don't shortcircuit on err when processing pending votes.
* client/beefy: remove invalid justifications at block import
* todo: beefy block import tests
* RFC: ideas for multiple justifications per block
* Revert "RFC: ideas for multiple justifications per block"
This reverts commit 8256fb07d3124db69daf252720b3c0208202624d.
* client/beefy: append justif to backend on block import
* client/beefy: groundwork for block import test
* client/beefy: groundwork2 for block import test
* client/beefy: groundwork3 for block import test
* client/beefy: add block import test
* client/beefy: add required trait bounds to block import builder
* remove client from beefy block import, backend gets the job done
Signed-off-by: acatangiu <adrian@parity.io>
* Update UI test output for rust 1.62.1
* switch ci to staging image to check that everything works
* fix artifacts node-bench-regression-guard
* Imeplement `scale_info::TypeInfo` manually to silence aggressive rust warning
* Fix more clippy lints
* Make clippy happy by relying on auto-deref were possible
* Add tracking issue to the comments
* pin ci image
Co-authored-by: alvicsam <alvicsam@gmail.com>
* Remove direct dependency of `sc-network` on `sc-network-light`
* Move `WarpSyncProvider` trait and surrounding data structures into `sc-network-common`
* Move `WarpSyncProvider` trait and surrounding data structures into `sc-network-common`
* Create `sync` module in `sc-network-common`, create `ChainSync` trait there (not used yet), move a bunch of associated data structures from `sc-network-sync`
* Switch from concrete implementation to `ChainSync` trait from `sc-network-common`
* Introduce `OpaqueStateRequest`/`OpaqueStateResponse` to remove generics from `StateSync` trait
* Introduce `OpaqueBlockRequest`/`OpaqueBlockResponse`, make `scheme` module of `sc-network-sync` private
* Surface `sc-network-sync` into `sc-service` and make `sc-network` not depend on it anymore
* Remove now unnecessary dependency from `sc-network`
* Replace crate links with just text since dependencies are gone now
* Remove `warp_sync` re-export from `sc-network-common`
* Update copyright in network-related files
* Address review comments about documentation
* Apply review suggestion
* Rename `extra_requests` module to `metrics`
Co-authored-by: Bastian Köcher <info@kchr.de>
* updated mmr rpc api with functions for batch generation of proof
* update code comments
* fix build errors
* added tests to mmr-rpc
* add tests to pallet-mmr
* update comments
* minor comment fix
* remove unused variables
* fix rust doc errors
* refactor mmr runtime api
* fix tests
* minor fix
* minor fix
* fix node-runtime
* revert to initial api
* impl from proof fot batchproof
* minor fix
* minor fix
* use explicit functions to convert btw batch proof and single proof
* minor fix
* add new variant to mmr error
* fmt
* update conversion to single leaf proof
* fix style nit
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* beefy: gadget should always use current validator set
The gadget/client-voter was using previous' session validator set
to sign the 1st block in the new session (to have chained validator
set handoffs).
This is not necessary because:
1. BEEFY piggy-backs on GRANDPA and only works on canonical chain,
so it need not concern itself with the validity of the block header
(which contains digest with the new session's validator set). It
can safely assume header is valid and simply use new validator set.
2. The BEEFY payload itself already contains a merkle root for the
next validator set keys. So at the BEEFY-payload layer we already
have a validated/trusted hand-off of authority.
Signed-off-by: acatangiu <adrian@parity.io>
* beefy: buffer votes for not yet finalized blocks
Signed-off-by: acatangiu <adrian@parity.io>
* beefy: add buffered votes regression test
* beefy-gadget: allow custom runtime api provider
* beefy-gadget: use mock runtime api in tests
* pallet-mmr: expose mmr root from state through runtime API
* beefy-gadget: get mmr root from runtime state
* pallet-beefy-mmr: remove MmrRoot from header digests
* frame/mmr: move mmr primitives out of frame
* frame/mmr: completely move primitives out of frame
* address review comments
* beefy-mmr: bring back mmr root from header digest
* clippy fixes for rustc 1.60
* address review comments
Simplified BEEFY worker logic based on the invariant that GRANDPA
will always finalize 1st block of each new session, meaning BEEFY
worker is guaranteed to receive finality notification for the
BEEFY mandatory blocks.
Under these conditions the current design is as follows:
- session changes are detected based on BEEFY Digest present in
BEEFY mandatory blocks,
- on each new session new `Rounds` of voting is created, with old
rounds being dropped (for gossip rounds, last 3 are still alive
so votes are still being gossiped),
- after processing finality for a block, the worker votes if
a new voting target has become available as a result of said
block finality processing,
- incoming votes as well as self-created votes are processed
and signed commitments are created for completed BEEFY voting
rounds,
- the worker votes if a new voting target becomes available
once a round successfully completes.
On worker startup, the current validator set is retrieved from
the BEEFY pallet. If it is the genesis validator set, worker
starts voting right away considering Block #1 as session start.
Otherwise (not genesis), the worker will vote starting with
mandatory block of the next session.
Later on when we add the BEEFY initial-sync (catch-up) logic,
the worker will sync all past mandatory blocks Signed Commitments
and will be able to start voting right away.
BEEFY mandatory block is the block with header containing the BEEFY
`AuthoritiesChange` Digest, this block is guaranteed to be finalized
by GRANDPA.
This session-boundary block is signed by the ending-session's
validator set. Next blocks will be signed by the new session's
validator set. This behavior is consistent with what GRANDPA does
as well.
Also drop the limit N on active gossip rounds. In an adversarial
network, a bad actor could create and gossip N invalid votes with
round numbers larger than the current correct round number. This
would lead to votes for correct rounds to no longer be gossiped.
Add unit-tests for all components, including full voter consensus
tests.
Signed-off-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com>
Co-authored-by: David Salami <Wizdave97>
Squirrel