Still allows custom message hasher, but ties together the crypto
types used for private+public keys and the signature.
Signed-off-by: acatangiu <adrian@parity.io>
* implement crate publishing from CI
* fix indentation
* use resource_group for job exclusivity
ensure that at most one instance of the publish-crates job is running at any given time to prevent race conditions
* correct publish = false
* Remove YAML anchors as GitLab's `extends:` doesn't need it
* Temporarily force cache upload for the new jobs
* Revert `RUSTY_CACHIER_FORCE_UPLOAD`
* pin libp2p-tcp=0.37.0 for sc-telemetry
* Revert "pin libp2p-tcp=0.37.0 for sc-telemetry"
This reverts commit 29146bfad6c31e8cf0e2f17ad92a71bb81a373af.
* always collect generated crates
* increase timeout for publish-crates-template
* Force upload the new job cache again
* Revert "Force upload the new job cache again"
This reverts commit 5a5feee1b2c51fdef768b25a76be4c3949ec1c99.
* reformat
* improve timeout explanation
* s/usual/average
Co-authored-by: Vladimir Istyufeev <vladimir@parity.io>
* client/beefy: prepare worker for persisting state
* client/beefy: persist voter state
* client/beefy: initialize persistent state
* client/beefy: try to vote from the very beginning
Now that voter is initialized from persistent state, it makes
sense that it can attempt voting right away. This also helps
the genesis case when we consider block `One` as mandatory.
* client/beefy: add tests for voter state db
* client/beefy: persist voter state as soon as initialized
* client/beefy: make sure min-block-delta is at least 1
* client/beefy: persist state after voting
Persist state after handling self vote to avoid double voting in case
of voter restarts.
* client/beefy: persist state after handling mandatory block vote
For mandatory blocks we want to make sure we're not losing votes
in case of crashes or restarts, since voter will not make further
progress without finalizing them.
* frame/beefy: use GENESIS_AUTHORITY_SET_ID on pallet genesis
* client/beefy: initialize voter at either genesis or last finalized
To guarantee unbroken chain of mandatory blocks justifications, voter
will always resume from either last BEEFY-justified block or
`pallet-beefy` genesis, whichever is more recent.
Initialization walks back the chain from latest GRANDPA finalized
block looking for one of the above. Along the way, it also records
and enqueues for processing any BEEFY mandatory blocks that have
been already GRANDPA finalized but not BEEFY finalized.
* client/beefy: decouple voter init from aux db state load
* client/beefy: fix voter init tests
* remove debug prints
* gadget future must be type ()
* fix init from last justification
Signed-off-by: Adrian Catangiu <adrian@parity.io>
* histor. batch proof: make best block arg optional
* correct testing range
* make generate_batch_proof stub for historical
* merge generate_{historical_}batch_proof functions
* merge generate_{batch_}proof functions
* merge verify_{batch_}proof functions
* merge verify_{batch_}proof_stateless functions
* remove {Leaf}Proof
Not utilized by API anymore, so superfluous.
Removal consistent with prior changes to just use "batch" proof API.
* rename BatchProof->Proof
no need to qualify if only one universal proof type.
* cleanup
* expose verify_proof rpc api
* document verify_proof
* expose verify_proof_stateless rpc api
* add optional BlockHash to mmr_root rpc api
* fixup! expose verify_proof rpc api
* fix documentation phrasing
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* documentation grammar
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* define mmr error msgs together with error enum
Co-authored-by: Serban Iorga <serban@parity.io>
* fixup! define mmr error msgs together with error enum
* map decoding errors to CallError::InvalidParams
Co-authored-by: Serban Iorga <serban@parity.io>
* fixup! map decoding errors to CallError::InvalidParams
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: parity-processbot <>
Co-authored-by: Serban Iorga <serban@parity.io>
* Use `array-bytes` for All Array/Bytes/Hex Operations
Signed-off-by: Xavier Lau <xavier@inv.cafe>
* Reorder
* Self Review
* Format
* Fix Tests
* Bump `array-bytes`
* Optimize large test res
Signed-off-by: Xavier Lau <xavier@inv.cafe>
Co-authored-by: parity-processbot <>
* 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>
* pallet-beefy: add Config::OnNewValidatorSet type
Add a hook to pallet-beefy for doing specific work when
BEEFY validator set changes.
For example, this can be used by pallet-beefy-mmr to cache
a lightweight MMR root over validators and make it available
to light clients.
* pallet-beefy-mmr: implement OnNewValidatorSet
Implement pallet-beefy::OnNewValidatorSet to be notified of BEEFY
validator set changes. Use the notifications to compute and cache
a light weight 'BEEFY authority set' which is an MMR root over
BEEFY validator set plus some extra info.
Previously, pallet-beefy-mmr was interogating pallet-beefy about
validator set id on every block to find out when it needs to recompute
the authority set.
By using the event-driven approach in this commit, we also save one
extra state interogation per block.
* pallet-beefy-mmr: add new authority_set() API
Expose current and next BEEFY authority sets through runtime API.
These can be directly used by light clients to avoid having them
compute them themselves based on BEEFY validator sets.
Signed-off-by: acatangiu <adrian@parity.io>
* rename BeefyMmr exposed runtime api
* refactor beefy mmr
* use plain vector of bytes for leaf extra
* update comment
* update comments
* remove unused vars
* Use sp_std::vec::Vec
Co-authored-by: Adrian Catangiu <adrian@parity.io>
* make extra data generic
* fix tests
* refactor beefy-mmr
* Update frame/beefy-mmr/src/lib.rs
* minor fix
* fmt
* Update frame/beefy-mmr/src/lib.rs
Co-authored-by: Adrian Catangiu <adrian@parity.io>
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>
* Upgraded dependencies
* Adapting code to scale v3
* Empty commit to trigger CI
* Triggering CI
* Fixing UI test
* Remove superfluous dev-dep added by #9228
* Cryout for CI
* Introduce `SecretUri`
* `inspect-key`: Adds support for `expect-public`
`expect-public` can be used to check that a given secret uri corresponds to the given public key.
This is mainly useful when the secret uri is protected by a password and a new derived account
should be generated. With `--expect-public` the user can pass the public key/account-id of the
"base" secret uri aka the one without any derivation to ensure the correct password was inserted.
* Fixes
* 🤦
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Review feedback
* FMT
* Bump the versions
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Intend to reactivate cargo-unleash check
It appears the bug it was deactivated for has been resolved a while ago. Trying to reactivate the checks.
* adding missing cargo.toml metadata for BEEFY crates
* fix wrong version reference
* matching up versions
* disable faulty cache
* switching more versions to prerelease
* Revert "disable faulty cache"
This reverts commit 411a12ae444a9695a8bfea4458a868438d870b06.
* bump minor of sc-allocator to fix already-published-issue
* fixup another pre-released dependency problem
* temp switch to latest unleash
* fixing dependency version and features
* prometheus endpoint has also been changed
* fixing proposer metrics versioning
* fixing hex feature for beefy
* fix generate-bags feature selection
* fixup Cargo.lock
* upgrade prometheus dependencies
* missed one
* switch to latest release