Show the crate…
2 stable releases
2.0.2 | Apr 3, 2021 |
---|---|
2.0.0 | Apr 2, 2021 |
#119 in #tetcoin
335KB
7.5K
SLoC
election-providers
lib.rs
:
Primitive traits for providing election functionality.
This crate provides two traits that could interact to enable extensible election functionality within FRAME pallets.
Something that will provide the functionality of election will implement ElectionProvider
,
whilst needing an associated ElectionProvider::DataProvider
, which needs to be fulfilled by
an entity implementing ElectionDataProvider
. Most often, the data provider is the receiver
of the election, resulting in a diagram as below:
ElectionDataProvider
<------------------------------------------+
| |
v |
+-----+----+ +------+---+
| | | |
pallet-do-election | | | | pallet-needs-election
| | | |
| | | |
+-----+----+ +------+---+
| ^
| |
+------------------------------------------+
ElectionProvider
It could also be possible that a third party pallet (C), provides the data of election to an election provider (B), which then passes the election result to another pallet (A).
Election Types
Typically, two types of elections exist:
- Stateless: Election data is provided, and the election result is immediately ready.
- Stateful: Election data is is queried ahead of time, and the election result might be ready some number of blocks in the future.
To accommodate both type of elections in one trait, the traits lean toward stateful
election, as it is more general than the stateless. This is why ElectionProvider::elect
has no parameters. All value and type parameter must be provided by the ElectionDataProvider
trait, even if the election happens immediately.
Election Data
The data associated with an election, essentially what the ElectionDataProvider
must convey
is as follows:
- A list of voters, with their stake.
- A list of targets (i.e. candidates).
- A number of desired targets to be elected (i.e. winners)
In addition to that, the ElectionDataProvider
must also hint ElectionProvider
at when
the next election might happen (ElectionDataProvider::next_election_prediction
). A stateless
election provider would probably ignore this. A stateful election provider can use this to
prepare the election result in advance.
Nonetheless, an ElectionProvider
shan't rely on this and should preferably provide some
means of fallback election as well, in case the elect
was called immaturely early.
Example
type AccountId = u64;
type Balance = u64;
type BlockNumber = u32;
mod data_provider {
use super::*;
pub trait Config: Sized {
type ElectionProvider: ElectionProvider<
AccountId,
BlockNumber,
DataProvider = Module<Self>,
>;
}
pub struct Module<T: Config>(std::marker::PhantomData<T>);
impl<T: Config> ElectionDataProvider<AccountId, BlockNumber> for Module<T> {
fn desired_targets() -> u32 {
1
}
fn voters() -> Vec<(AccountId, VoteWeight, Vec<AccountId>)> {
Default::default()
}
fn targets() -> Vec<AccountId> {
vec![10, 20, 30]
}
fn next_election_prediction(now: BlockNumber) -> BlockNumber {
0
}
}
}
mod generic_election_provider {
use super::*;
pub struct GenericElectionProvider<T: Config>(std::marker::PhantomData<T>);
pub trait Config {
type DataProvider: ElectionDataProvider<AccountId, BlockNumber>;
}
impl<T: Config> ElectionProvider<AccountId, BlockNumber> for GenericElectionProvider<T> {
type Error = ();
type DataProvider = T::DataProvider;
fn elect() -> Result<Supports<AccountId>, Self::Error> {
Self::DataProvider::targets()
.first()
.map(|winner| vec![(*winner, Support::default())])
.ok_or(())
}
}
}
mod runtime {
use super::generic_election_provider;
use super::data_provider;
use super::AccountId;
struct Runtime;
impl generic_election_provider::Config for Runtime {
type DataProvider = data_provider::Module<Runtime>;
}
impl data_provider::Config for Runtime {
type ElectionProvider = generic_election_provider::GenericElectionProvider<Runtime>;
}
}
Dependencies
~3–11MB
~128K SLoC