This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Move sp-npos-elections-solution-type
to frame-election-provider-support
#10866
Labels
I7-refactor
Code needs refactoring.
Z1-easy
Can be fixed primarily by duplicating and adapting code by an intermediate coder
Z6-mentor
An easy task where a mentor is available. Please indicate in the issue who the mentor could be.
... and derive
MaxEncodedLen
for it. DerivingMaxEncodedLen
should be rather tricky. The final struct for which we want to derive it looks like this:And while the inner types (
T1
toT16
) are all bounded,Vec
is simply notMaxEncodedLen
.One option would be to try and move all of the
Vec
s toBoundedVec
. I strongly advice against that, mainly because I speculate that we want to re-thinkgenerate_npos_solution!
macro overall and not generate it at compile-time.What I recommend instead is to take a simpler approach, and accept that our
MaxEncodedLen
estimate for this type will be slightly pessimistic for now. We leverage the known fact thatT1 < T2 < ... < T16
. Also, we leverage the fact that we could knowsum{votes1.len(), votes2.len(), ..., votes16.len()}
at compile time (hint: this is essentially the same asVoterSnapshotPerBlock
;) ).So all in all, the macro will be given one bound, named
b
(either as an expression or a type that isGet<u32>
), which is essentially the total number of possible voters that this solution could represent. Then, theMaxEncodedLen
will assume thatvotes16
(or whatever is the maximum) hasb
items and all the rest are empty.Of course, this needs to be rethink-ed before this type is efficiently usable in a parachain, but for relay chains it is fine.
The text was updated successfully, but these errors were encountered: