* 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>