Benjamin Kampmann
c78c2892a4
* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
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