Multisig handles changes to group membership

[ethanfrey]

Builds on #80, #139 and #140

Let's build a properly flexible multisig that is robust to changes in the underlying group at any time. I will propose some approaches here, all of them require some sort of event notification on group changes - #140

---

Simple but limited: (please implement one of these two first to ensure the system works)

• If an "update group" event comes in while there is an open proposal, return error - this will block the group changes until there are no open proposals
• If an "update group" event comes in while there is an open proposal, force close all open proposals (aborting them). This ensures the new proposal will have a stable voting group (maybe close them and auto-reopen?)

Note that these (as well as the ones below) need a quick way to find all currently open proposals - maybe a secondary index? or clever use of the primary index

---

Complex: (Let's discuss these in the comments to decide)

Count all votes with state at beginning of voting period

• The total weight needed to pass is fixed at the beginning and never changes
• If a member is updated and they haven't voted yet, record the previous weight (the value at the beginning of the proposal) in some local cache inside cw3-flex-multisig. When the member votes, the weight there overrides the current weight in the group.

Count all votes with state at end of voting period

• If a member is updated and they already voted, update the weight, both in their vote and the sum inside the proposal
• The total weight needed to pass will update with each change to the group
• If a member is updated and they haven't voted yet, no need to do anything special

[ethanfrey]

@alpe Also asking for your feedback here. Not about code, but about the design choice. I know you implemented this for the governance/voting contracts in weave. And it kept multiple versions of the voting set.

Of the two complex solutions proposed:

• Count all votes with state at beginning of voting period
• Count all votes with state at end of voting period

Which one do you prefer and why? (I forget what thinking we ended up with before, and maybe you preferences have changed).

Also in reference to the other requested review: #140 (comment) we see how the first "simple" solution depends on this being a hook (not a listener) and explicitly altering the behavior of the group contract based on our business logic.

[alpe]

When using the state at "beginning of voting" it has the benefit that all numbers are set and transparent. You may possibly end an election early when a threshold is reached or can not be reached anymore. This is not an option though if votes can be changed within the voting period.
"Beginning of voting" is also closer to what I consider "fair". The outcome of the election can only be influenced by votes and not by buying more weight during the voting period.
A UI/ communication strategy should be considered as well. How are the votes, thresholds displayed? If the total number staked could be modified then the threshold amount would change, too. This can become very confusing and hard to communicate. It would also affect social engagement like: we need x stake more to succeed this proposal....

[maurolacy]

• If a member is updated and they already voted, update the weight, both in their vote and the sum inside the proposal

• If a member is updated and they haven't voted yet, record the previous weight (the value at the beginning of the proposal) in some local cache inside cw3-flex-multisig. When the member votes, the weight there overrides the current weight in the group.

Aren't these two behaviours inconsistent / contradictory? I mean, why update when they already voted, but refrain to do so when they haven't voted yet?

[ethanfrey]

You are right. The first of those two should be removed (it belongs to the section belong, seems to be there twice)

[ethanfrey]

The simple solution was completed in #157 which demonstrates proper usage of hooks.

Working on the more advanced "lazy snapshot" of beginning of vote

[ethanfrey]

This should close it entirely #160

And I think I got this down very efficiently: one read/write per diff on update, one extra read on voting, not O(proposals) at all.