Generic Normalize impl for arithmetic and npos-elections

[kianenigma]

Context:

When converting certain types to one another, we typically lose some accuracy based on what type of PerThing we are using. This is normal, as these types are limited.

When it comes to staking, we want to make sure that this always compensated. For example, we have an Assignment saying that someone's stake should be distributed between [a, b, c] by [33%, 33%, 33%]. This is actually a plausible example, and we have to make sure we always inject a 1% into this to have it add up to 100%.

Same story applies to when we are dealing with stake values. If I own 100 tokens, and my weight distribution is [66, 33], then we need to inject to 1 which has been lost due to rounding errors.

This is critically important for offchain phragmen as well, since validators need to compute the score offchain, which is a function of stake values, and it must be exactly the same one as computed on-chain on the validation phase, hence these rounding errors could cause a mismatch. The submit_solution fuzzer in staking particularly checks and catches bugs related to this.

Before

We had a pitiful, minimal and potentially buggy implementation for this operation here:

substrate/primitives/npos-elections/src/lib.rs

Lines 201 to 213 in db8916a

	if fill {
	// NOTE: we can do this better.
	// https://revs.runtime-revolution.com/getting-100-with-rounded-percentages-273ffa70252b
	if let Some(leftover) = stake.checked_sub(sum) {
	if let Some(last) = distribution.last_mut() {
	last.1 = last.1.saturating_add(leftover);
	}
	} else if let Some(excess) = sum.checked_sub(stake) {
	if let Some(last) = distribution.last_mut() {
	last.1 = last.1.saturating_sub(excess);
	}
	}
	}

in which we simply and blindly added all the leftovers of any accuracy loss to the last element.

Now

We do this much better, and in a generic way. See trait Normalizable and fn normalize().

The implementation is not idea, but fast, and based on our need in which the errors are almost always small, it is the most sensible.

Next

This was part of a much bigger refactor that I am doing toward the second goal of #6242, but I don't want to again submit a PR with 10K additions and have it impossible to review. So this PR is generally a step toward breaking things down. Almost no logic in staking is changed here, so I see it is nicely isolated.

A follow up will further revamp npos-elections and add implementations for our new election algorithms.

Discussion

• Perhaps the name normalizable is not idea. I couldn't find a better one from the math context.
• 📢 Ideally, I want to implement Normalizable for all Vec<T> where T is some unsigned number, and and Vec<P> where P is some PerThing. But we can't do this. So I've moved the impl for PerThing to the macro and implement it individually for each one, i.e. Vec<Perbill>. But this is pretty useless, since npos-elections always works with P: PerThing, not directly a Perbill.

[kianenigma]

@thiolliere @drahnr Thanks for the reviews. All reviews either resolved or written down why otherwise. Please resolve the comments if you agree, else elaborate why.

[gui1117]

looks good to me

[kianenigma]

bot merge

[ghost]

Waiting for commit status...

[ghost]

Merge failed - String("2 of 8 required status checks have not succeeded: 1 expected and 1 pending.")

[sjeohp-zz]

bot merge

[ghost]

Trying merge.