Jon Häggblad
0d6884b919
* primitives/runtime: initial changes on supporting multiple Justifications * primitives/runtime: make Justifications strongly typed * Encode/decode Justifications * primitives/runtime: add Justification type * backend: apply_finality and finalize_block takes a single Justification * manual-seal: create engine id and let rpc take encoded justification * backend: skeleton functions for appending justifications * backend: initial implementation append_justification Initial implementation of append_justification on the Backend trait, and also remove unused skeleton functions for append_justificaton on Finaziler trait. k * backend: guard against duplicate consensus engine id * client/db: add check for block finality * client/api: add append_justification to in_mem db * client/light: add no-op append_justification * network: fix decode call for Justification * network: only send a single Justification in BlockData * network: minor comment update * protocol: update field names to distinguish single justification * client: further field renames to plural * client: update function names to plural justifications * client/db: upgrade existing database for new format * network: remove dependency on grandpa crate * db: fix check for finalized block * grandpa: check for multiple grandpa justifications hwne importing * backend: update Finalizer trait to take multiple Justifications * db: remove debugging statements in migration code * manual-seal: update note about engine id * db: fix check for finalized block * client: update variable name to reflect it is now plural * grandpa: fix incorrect empty Justications in test * primitives: make Justifications opaque to avoid being empty * network: fix detecting empty Justification * runtime: doc strings for Justifications functions * runtime: add into_justifications * primitives: check for duplicates in when adding to Justifications * network/test: use real grandpa engine id in test * client: fix reviewer comments * primitives: rename Justifications::push to append * backend: revert changes to Finalizer trait * backend: revert mark_finalized * backend: revert changes to finalize_block * backend: revert finalized_blocks * db: add a quick early return for performance * client: minor reviewer comments * service/test: use local ConsensusEngineId * network: add link to issue for sending multiple Justifications * Apply suggestions from code review Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> * Apply suggestions from code review Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> * network: tweaks to review suggestions * network: revert change to BlockData for backwards compatibility * Apply suggestion from code review Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> * Apply suggestions from code review Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> * primitives: update doc comment for Justifications * client/db/upgrade: avoid grandpa crate dependency * consensus: revert to single Justification for import_justification * primitives: improve justifications docs * style cleanups * use and_then * client: rename JUSTIFICATIONS db column * network: revert to using FRNK in network-test Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com> Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> Co-authored-by: André Silva <andrerfosilva@gmail.com>
BABE (Blind Assignment for Blockchain Extension)
BABE is a slot-based block production mechanism which uses a VRF PRNG to randomly perform the slot allocation. On every slot, all the authorities generate a new random number with the VRF function and if it is lower than a given threshold (which is proportional to their weight/stake) they have a right to produce a block. The proof of the VRF function execution will be used by other peer to validate the legitimacy of the slot claim.
The engine is also responsible for collecting entropy on-chain which will be used to seed the given VRF PRNG. An epoch is a contiguous number of slots under which we will be using the same authority set. During an epoch all VRF outputs produced as a result of block production will be collected on an on-chain randomness pool. Epoch changes are announced one epoch in advance, i.e. when ending epoch N, we announce the parameters (randomness, authorities, etc.) for epoch N+2.
Since the slot assignment is randomized, it is possible that a slot is assigned to multiple validators in which case we will have a temporary fork, or that a slot is assigned to no validator in which case no block is produced. Which means that block times are not deterministic.
The protocol has a parameter c [0, 1] for which 1 - c is the probability
of a slot being empty. The choice of this parameter affects the security of
the protocol relating to maximum tolerable network delays.
In addition to the VRF-based slot assignment described above, which we will call primary slots, the engine also supports a deterministic secondary slot assignment. Primary slots take precedence over secondary slots, when authoring the node starts by trying to claim a primary slot and falls back to a secondary slot claim attempt. The secondary slot assignment is done by picking the authority at index:
blake2_256(epoch_randomness ++ slot_number) % authorities_len.
The secondary slots supports either a SecondaryPlain or SecondaryVRF
variant. Comparing with SecondaryPlain variant, the SecondaryVRF variant
generates an additional VRF output. The output is not included in beacon
randomness, but can be consumed by parachains.
The fork choice rule is weight-based, where weight equals the number of primary blocks in the chain. We will pick the heaviest chain (more primary blocks) and will go with the longest one in case of a tie.
An in-depth description and analysis of the protocol can be found here: https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html
License: GPL-3.0-or-later WITH Classpath-exception-2.0