This subsystem is responsible for inspecting the chain state (likely via Runtime API) to see which candidates are pending approval and, when running as a validator, determine which of them we are assigned to check.
Approval assignments are divided into "Delay Tranches", with each tranche being 0.5 seconds long, and the first tranche (tranche 0) starting from the BABE slot of the block. This means that we may receive a relay-chain block (and thus, the candidates within it) after several delay-tranches have already passed due to network latency.
Validators compute their assignments by means of a Verifiable Random Function (VRF) parameterized by some data, which includes the tranche index. #1518 contains more information on the exact "stories" that parameterize assignments. There are different stories based on whether malicious validators appear to be attempting to reorganize the chain or not.
What it means for a tranche to be 0.5 seconds long is that every 0.5 seconds after being made aware of the candidate, validators will compute their local VRF using the tranche parameters, and see if it indicates that they have been selected for that tranche. As such, the number of validators in any given tranche is random, so we always select enough tranches so there is at least some constant number of validators assigned.
If validators announce their assignment but then do not issue an approval vote, that is considered a no-show (see https://github.com/paritytech/polkadot/issues/1599) and more tranches will be taken as it is a sign that an adversary may be censoring an honest validator.
Since this subsystem is only responsible for computing our assignment, it needs to interact with the following subsystems:
Assignment Distribution (#1600) for notifying other validators about our assignment
No-show tracker (#1599) for learning about no-shows and releasing further assignments to Assignment distribution
Approval Voting (#1601) for triggering an actual approval vote on the candidates we are assigned to.
rphmeier
commented
3 years ago
This subsystem is responsible for inspecting the chain state (likely via Runtime API) to see which candidates are pending approval and, when running as a validator, determine which of them we are assigned to check.
Approval assignments are divided into "Delay Tranches", with each tranche being 0.5 seconds long, and the first tranche (tranche 0) starting from the BABE slot of the block. This means that we may receive a relay-chain block (and thus, the candidates within it) after several delay-tranches have already passed due to network latency.
Validators compute their assignments by means of a Verifiable Random Function (VRF) parameterized by some data, which includes the tranche index. #1518 contains more information on the exact "stories" that parameterize assignments. There are different stories based on whether malicious validators appear to be attempting to reorganize the chain or not.
What it means for a tranche to be 0.5 seconds long is that every 0.5 seconds after being made aware of the candidate, validators will compute their local VRF using the tranche parameters, and see if it indicates that they have been selected for that tranche. As such, the number of validators in any given tranche is random, so we always select enough tranches so there is at least some constant number of validators assigned.
If validators announce their assignment but then do not issue an approval vote, that is considered a no-show (see https://github.com/paritytech/polkadot/issues/1599) and more tranches will be taken as it is a sign that an adversary may be censoring an honest validator.
Since this subsystem is only responsible for computing our assignment, it needs to interact with the following subsystems: