Society v2

[gavofyork]

Closes #10465
Polkadot companion: paritytech/polkadot#7356

Substantial changes to Society:

• The number of members are no longer limited technically (Members is no longer a Vec item).
• Proper use of BoundedVec.
• Max members and intake size can be altered by founder without runtime upgrade.
• Members are ranked. Voting weight is determined as a rank-plus-one-squared.
• Right now there's only two ranks, with all members starting as rank zero (vote weight 1) and all members eligible to become rank one (vote weight 4) if they return any funds they received from the society back into its treasury and give up the possibility of getting future funds.
• The concept of a suspended candidate is removed: Candidates can remain a candidate indefinitely, however unless there is persistent indecision among the membership and inaction by the founder, then all candidates will be either approved as a member or rejected entirely after a full additional intake round.

Candiate voting:

• The process for moving from candidate to member is no longer automatic and requires a call into one of a number of free dispatchables.
• The voting/reward/punishment scheme for candidates and challenged members is completely different.
• The candidate voting round is two phase, initially a voting phase and then a period afterwards where membership may be claimed based on those votes before the next candidate(s) are selected.
• There is now only one Skeptic and their duty is changed.
• No members are rewarded for voting.
• Only the Skeptic is punished for invalid/missing votes.
• Unlike the original voting scheme, the new scheme involves no random input.
• The Skeptic is selected at random from the members, but no vote is attributed to them.
• Members may vote on any candidate at any time.
• The "clear result" of voting is when there are twice as many votes for either approval or rejection as there are for the alternative.
• There is no "clear result" of voting if neither the votes for approval nor the votes for rejection are more than twice as great as the other.
• A candidate may always resign their candidacy at any time, but this incurs the loss of their deposit.
• If they do not, then their candidacy may not end until the voting period is elapsed.
• Once the voting period is elapsed, they may elevate themselves to become a member if the clear result of voting is in approval.
• Once the following intake round is ended, then anyone may cancel the candidate's candidacy if there is a clear rejection of the candidate among voters.
• Once the voting period is elapsed, the founder may elevate them to member if there is not a clear rejection of the candidate among voters.
• Similarly, once the voting period is elapsed, the founder may cancel their candidacy if there is not a clear approval of the candidate among voters.
• At any point once the voting period is over, the Skeptic can be forced by anyone to receive a strike for any candidate on which they either did not vote or did vote but voted against the clear result (if there was one). The Skeptic may only be punished once for any candidate.

Member challenges:

• At every Challenge Period, a member is selected to become the new Defender and another member is selected at random to become the Challenge Skeptic.
  • The Defender is generally selected at random from the members.
  • However, if the previous Challenge Skeptic received a strike for missing or invalid voting, then they become the Defender.
• Prior to the commencement of the next Challenge Period, any member may vote on the continued validity of the member's membership.
• The Challenge Skeptic receives a strike and becomes the next Defender if they did not vote or if their vote is against the clear result of the voters (if any).
• A random member is selected as the next Defender if the Challenge Skeptic's vote is present and valid.
• If the clear result of the voters is to reject the Defender's evidence of continued eligibility for membership, then the Defender is removed as a member and placed in the SuspendedMembers list. The founder may restore their membership or remove them as before.

New dispatchables to be integrated in the UI (CC @jacogr):

• waive_repay: Attempt to clear any payouts and promote the member to rank 1. This transfers the given amount of the sender's balance back into the Society. This will only work if the given amount is at least as great as the member's debt to the society.
• punish_skeptic: Callable by a candidate after the voting period has ended to ensure that the Skeptic is punished for inaction or invalid voting.
• claim_membership: Callable by a candidate to claim their membership after the voting period has ended and when there is a clear result of approval.
• bestow_membership: Callable by the Founder to elevate a candidate to member after the voting period has ended and when there is not a clear result of rejection.
• kick_candidate: Callable by the Founder to reject a candidate after the voting period has ended and when there is not a clear result of approval. The candidate loses their deposit.
• resign_candidacy: Callable by a candidate to end their candidacy. The candidate loses their deposit.
• drop_candidate: Callable by anyone to end a candidate's candidacy after the intake period following the one in which the candidate applied and only when there is a clear result of rejection. The candidate loses their deposit.

TODO:

• Repay / Waive
• Rank rules
• Old tests
• New test(s)?
• Migration
• Prove that the remove_all(None) calls are bounded.
• Tidy any old rank/group stuff.

[paritytech-processbot]

Rebased

[sam0x17]

LGTM, though wondering why the later call indexes don't have complexity notation like the earlier ones do? I find that sort of thing really helpful when reviewing an unfamiliar function/algorithm/procedure so would be cool if every call had complexity notation IMO

[sam0x17]

Could we get complexity notation for this one and later ones as well since we have it on the earlier calls?

[kianenigma]

Or the other way, I find most of these complexity/weight comments pretty useless. Even if they should exist, it should be in the benchmarking code, not in the call documentation (where end users will see it through metadata).

[gavofyork]

Indeed - they're actually mostly old and incorrect. As can be seen from the weight calls, they're all O(1) now. The only caveat to that is that BoundedVecs in storage items must generally be full to ensure the maximum possible weight is determined. But I don't think that's especially useful to have in the function docs since it's a) fairly obvious; and b) as closely related to the storage item itself as it is the function.

[gavofyork]

bot merge

[paritytech-processbot]

Error: "Check reviews" status is not passing for paritytech/polkadot#7356