referrerpolicy=no-referrer-when-downgrade
pub const DISPUTE_CANDIDATE_LIFETIME_AFTER_FINALIZATION: BlockNumber = 10;
Expand description

How many blocks after finalization an information about backed/included candidate should be pre-loaded (when scraping onchain votes) and kept locally (when pruning).

We don’t want to remove scraped candidates on finalization because we want to be sure that disputes will conclude on abandoned forks. Removing the candidate on finalization creates a possibility for an attacker to avoid slashing. If a bad fork is abandoned too quickly because another better one gets finalized the entries for the bad fork will be pruned and we might never participate in a dispute for it.

Why pre-load finalized blocks? I dispute might be raised against finalized candidate. In most of the cases it will conclude valid (otherwise we are in big trouble) but never the less the node must participate. It’s possible to see a vote for such dispute onchain before we have it imported by dispute-distribution. In this case we won’t have CandidateReceipt and the import will fail unless we keep them preloaded.

This value should consider the timeout we allow for participation in approval-voting. In particular, the following condition should hold:

slot time * DISPUTE_CANDIDATE_LIFETIME_AFTER_FINALIZATION > APPROVAL_EXECUTION_TIMEOUT

  • slot time