The docs for generate_solution_type say:
/// Moreover, the maximum number of edges per voter (distribution per assignment) also need to be
/// specified. Attempting to convert from/to an assignment with more distributions will fail.
///
/// For example, the following generates a public struct with name `TestSolution` with `u16` voter
/// type, `u8` target type and `Perbill` accuracy with maximum of 4 edges per voter.
///
/// ```
/// # use frame_election_provider_solution_type::generate_solution_type;
/// # use sp_arithmetic::per_things::Perbill;
/// generate_solution_type!(pub struct TestSolution::<
/// VoterIndex = u16,
/// TargetIndex = u8,
/// Accuracy = Perbill,
/// >(4));
Note that this type is generic to a graph based election algorithm where a voter may elect multiple targets. With this in mind in the context of the staking pallet, the phrase “edges per voter” can be understood as the the maximum number of targets (validators), that a nominator can nominate; in other words the max nominations that a nominator can have.
The two primary considerations when configuring this value are:
- How does changing this value affect the worst case space / memory complexity of operations on nominators?
- How does changing the value affect the election algorithms ability to achieve its goals (i.e. maximize total stake, maximize min staked validator’s exposure, minimize difference between exposure of max and min staked validators).
To address (1), one should consider how many total nominators they want in the system. Essentially, increasing the MAX_NOMINATIONS will increase the worst case space complexity of each nominator; so as the MAX_NOMINATIONS increase, the number of nominators the system can handle will decrease. For example see the discussion here about lower the max number of voters on Kusama.
To address (2), one should consider that hypothetically a phragmen election algorithm can do a better job of creating an optimal set when nominators have selected a wide array of validators (in practice the increase of max nominations is not guaranteed to lead to an increase in solution quality). As an extreme, imagine a max nominations of 1: the algorithm would practically do nothing and we would have the equivalent of a DPoS outcome.
Also keep in mind that nominator accounts make no sybil resistance guarantees; a low max nominations may encourage some users to break up 1 nominator account into several nominator accounts so they can select a wider variety of validators, thus increasing the nominator space complexity per "real" user.
