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>
Phragmén Election Module.
An election module based on sequential phragmen.
Term and Round
The election happens in rounds: every N blocks, all previous members are retired and a new
set is elected (which may or may not have an intersection with the previous set). Each round
lasts for some number of blocks defined by TermDuration storage item. The words term and
round can be used interchangeably in this context.
TermDuration might change during a round. This can shorten or extend the length of the round.
The next election round's block number is never stored but rather always checked on the fly.
Based on the current block number and TermDuration, the condition BlockNumber % TermDuration == 0 being satisfied will always trigger a new election round.
Voting
Voters can vote for any set of the candidates by providing a list of account ids. Invalid votes
(voting for non-candidates) are ignored during election. Yet, a voter might vote for a future
candidate. Voters reserve a bond as they vote. Each vote defines a value. This amount is
locked from the account of the voter and indicates the weight of the vote. Voters can update
their votes at any time by calling vote() again. This keeps the bond untouched but can
optionally change the locked value. After a round, votes are kept and might still be valid for
further rounds. A voter is responsible for calling remove_voter once they are done to have
their bond back and remove the lock.
Voters also report other voters as being defunct to earn their bond. A voter is defunct once all
of the candidates that they have voted for are neither a valid candidate anymore nor a member.
Upon reporting, if the target voter is actually defunct, the reporter will be rewarded by the
voting bond of the target. The target will lose their bond and get removed. If the target is not
defunct, the reporter is slashed and removed. To prevent being reported, voters should manually
submit a remove_voter() as soon as they are in the defunct state.
Candidacy and Members
Candidates also reserve a bond as they submit candidacy. A candidate cannot take their candidacy back. A candidate can end up in one of the below situations:
- Winner: A winner is kept as a member. They must still have a bond in reserve and they are automatically counted as a candidate for the next election.
- Runner-up: Runners-up are the best candidates immediately after the winners. The number
of runners_up to keep is configurable. Runners-up are used, in order that they are elected,
as replacements when a candidate is kicked by
[remove_member], or when an active member renounces their candidacy. Runners are automatically counted as a candidate for the next election. - Loser: Any of the candidate who are not a winner are left as losers. A loser might be an outgoing member or runner, meaning that they are an active member who failed to keep their spot. An outgoing will always lose their bond.
Renouncing candidacy.
All candidates, elected or not, can renounce their candidacy. A call to [Module::renounce_candidacy]
will always cause the candidacy bond to be refunded.
Note that with the members being the default candidates for the next round and votes persisting
in storage, the election system is entirely stable given no further input. This means that if
the system has a particular set of candidates C and voters V that lead to a set of members
M being elected, as long as V and C don't remove their candidacy and votes, M will keep
being re-elected at the end of each round.
Module Information
License: Apache-2.0