Peter Goodspeed-Niklaus
49be0579db
* Add PJR challenge functions - Updates the PJR check to return a counterexample if one exists - Adds functions to cheaply check counterexamples This is in support of off-chain PJR challenges: if a miner discovers that an accepted election solution does not satisfy PJR, it will be eligible for substantial rewards. This helps ensure that validator elections have an absolute quality floor, so even if someone manages to censor well-behaved solutions to give themselves unfair representation, we can catch them in the act and penalize them. * counterexample -> counter_example * reorganize: high -> low abstraction * reorganize challenges high -> low abstraction * add note justifying linear search * Simplify max_pre_score validation Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * add minor test of pjr challenge validation Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
A set of election algorithms to be used with a substrate runtime, typically within the staking sub-system. Notable implementation include:
- [
seq_phragmen]: Implements the Phragmén Sequential Method. An un-ranked, relatively fast election method that ensures PJR, but does not provide a constant factor approximation of the maximin problem. - [
phragmms]: Implements a hybrid approach inspired by Phragmén which is executed faster but it can achieve a constant factor approximation of the maximin problem, similar to that of the MMS algorithm. - [
balance_solution]: Implements the star balancing algorithm. This iterative process can push a solution toward being morebalances, which in turn can increase its score.
Terminology
This crate uses context-independent words, not to be confused with staking. This is because the election algorithms of this crate, while designed for staking, can be used in other contexts as well.
Voter: The entity casting some votes to a number of Targets. This is the same as Nominator
in the context of staking. Target: The entities eligible to be voted upon. This is the same as
Validator in the context of staking. Edge: A mapping from a Voter to a Target.
The goal of an election algorithm is to provide an ElectionResult. A data composed of:
winners: A flat list of identifiers belonging to those who have won the election, usually ordered in some meaningful way. They are zipped with their total backing stake.assignment: A mapping from each voter to their winner-only targets, zipped with a ration denoting the amount of support given to that particular target.
// the winners.
let winners = vec![(1, 100), (2, 50)];
let assignments = vec![
// A voter, giving equal backing to both 1 and 2.
Assignment {
who: 10,
distribution: vec![(1, Perbill::from_percent(50)), (2, Perbill::from_percent(50))],
},
// A voter, Only backing 1.
Assignment { who: 20, distribution: vec![(1, Perbill::from_percent(100))] },
];
// the combination of the two makes the election result.
let election_result = ElectionResult { winners, assignments };
The Assignment field of the election result is voter-major, i.e. it is from the perspective of
the voter. The struct that represents the opposite is called a Support. This struct is usually
accessed in a map-like manner, i.e. keyed vy voters, therefor it is stored as a mapping called
SupportMap.
Moreover, the support is built from absolute backing values, not ratios like the example above.
A struct similar to Assignment that has stake value instead of ratios is called an
StakedAssignment.
More information can be found at: https://arxiv.org/abs/2004.12990
License: Apache-2.0