Add threshold to cw3 flex

[ethanfrey]

Closes #139

This allows us to set any of the 3 defined threshold types for passing proposals.
Handler code is working and tested for the original case (AbsoluteCount).
Low level code (calculate passing, etc) is tested for all cases I could think of.

TODO:

• unit test all helper functions in msg for the other threshold types
• unit test all helper functions in state for the other threshold types
• revisit rules for passing with quorum (hard to pass early)
• provide high-level scenario tests with other threshold types (esp with changing groups)
• test coverage for proposal lists, vote details

[ethanfrey]

This should be ready to review. Covered with lots of unit tests. I will provide a few high-level scenario tests for the more dynamic variants, but the logic should all be covered with tests now.

[ethanfrey]

Finished added all tests

[maurolacy]

Incomplete review. Posting anyway for your consideration.

I propose we have a chat tomorrow to discuss some details I'm certainly missing.

[ethanfrey]

Please review #188 and give feedback there, then we can see what discussion points are still open.

[ethanfrey]

Also I addressed the edge case on hitting absolute threshold, but not quorum that you pointed out. Good catch there.

[maurolacy]

Looks good.

Only remaining (minor) concern I have is about Abstain subtraction when compute passing weight in AbsoluteThreshold.

[ethanfrey]

I just added a few smaller commits for some of the last outstanding points.

If you can unify the docs a bit more, that would be great. Then feel free to merge when done with docs update.

[maurolacy]

I just added a few smaller commits for some of the last outstanding points.

This is looking great.

If you can unify the docs a bit more, that would be great. Then feel free to merge when done with docs update.

OK.

One more thing:
I think the different checks between expired and not expired voting must be applied to AbsolutePercentage too. I mean, after the voting has ended, you would want the passing percentage to be computed over the weights of the ones who effectively voted (minus Abstain), not over the total weight.

Or is it called Absolute because of that? Then we could have a fourth version: RelativePercentage (or plain Percentage).

[maurolacy]

I'll add an issue to consider implementing RelativePercentage in another PR.

Merging now.

[ethanfrey]

I think the different checks between expired and not expired voting must be applied to AbsolutePercentage too. I mean, after the voting has ended, you would want the passing percentage to be computed over the weights of the ones who effectively voted (minus Abstain), not over the total weight.

Or is it called Absolute because of that? Then we could have a fourth version: RelativePercentage (or plain Percentage).

AbsolutePercentage is basically a way of a dynamic M of N multisig. 51% automatically shifts from "3 of 5" to "5 of 9" to "6 of 10". It doesn't matter show does or does not vote, just how many sigs they are. This, like AbsoluteCount, behave very much like off-chain signature aggregation, but allow the signing group to evolve.

Your idea of RelativePercentage is like ThresholdQuorum without a quorum. That means if only one person voted on a quick election, they could get it passed. I would prefer to use a ThresholdQuorum with a low (eg. 10-20% quorum) instead of one with no checks at all there.

Anyway, feel free to add an issue for RelativePercentage and we can discuss it there. I am also happy for other types that do something not covered by these three. (note these are just binary elections, so most of the cool findings, like "ranked choice" do not apply here... we can work on multiple choice elections in another spec)

[ethanfrey]

I'd love hyperlinks or other way to connect these two descriptions better

[ethanfrey]

It would be cool to see these as hyperlinks.

These seem to be possible in RustDoc, and even better supported since 1.48
Also see the RFC for more details

(Side-note, we really need to review the RustDoc output once we push 0.4.0)

[maurolacy]

Yes, they are possible, and are used extensively in the crates documentation. Here in particular, I first added and afterwards then removed the hyperlink formatting, because these comments go to the json files.

We definitely should start using these links, and confirm that they are working correctly in the crates docs.

[maurolacy]

(Side-note, we really need to review the RustDoc output once we push 0.4.0)

I propose we create an issue in cosmwasm for that, and consider / mention all the projects.

[ethanfrey]

Oh, there are issues... for quite some time:

CosmWasm/cosmwasm#436

CosmWasm/cosmwasm#196

Just seems that all of us prefer to code than tidy up RustDoc