search

iov-one / weave

Easy-to-use SDK to build Tendermint ABCI applications
https://weave.iov.one/docs/intro.html
Other
1.12k stars 46 forks source link

Extend multisig contract with weights #285

Closed ethanfrey closed 5 years ago

ethanfrey commented 5 years ago

We want to allow for election scenarios to happen off-chain. In many cases, different actors will have different voting power (just like validators).

We can do much of the vote aggregation off-chain, and use a multi-sig contract to control execution. However, it is missing the ability to provide different voting power to different keys.

Two proposal:

Decision

We will update the existing multisig to hold a weight per voter. However, there is no need for backwards compatibility if we can get this into a 0.12.x on zebranet, as so far we have no client code outside of this repo that uses the multi-sig feature.

Technical Spec

To think about...

Currently the multisig.UpdateContractMsg behaves like a POST and overwrites the existing contract with a new state. All fields must be set like the original Create. However, the zero-value is illegal for all fields. We could modify this to PATCH and Update will only overwrite the fields defined. This means:

  1. Admin and Activation Threshold of 0 means "don't change"
  2. No Sigs means "don't change"

If there are Sigs, we must clarify what that means... overwrite current set with that new set? or do a diff, like with validators... setting weight=0 to mark current members for removal, and positive weight to update or add a member.

We could also allow CreateContractMsg, UpdateContractMsg (POST) and PatchContractMsg (ony apply diff.

(Read below in comments to see some example usages from @alpe 's doc)

alpe commented 5 years ago

I am voting for option 1. :-)

I have seen the weight in multisig contracts at stellar before and it made sense for me as it enables more use cases than the equal weight contract. No need to restrict this to "voting" scenarios IMHO.

ethanfrey commented 5 years ago

@alpe please propose a clear spec for this...

eg. max weight

how to handle weight: 0 vs weight: missing (the second is the same as weight: 1, the first??) - this is both for protobuf and init file. how to detect this even???

ensure backwards compatibility for old clients

how to properly remove members from the mutlisig

maybe some ideas for test cases that should be covered (tricky conditions)

ethanfrey commented 5 years ago

Nice link to stellar by the way. I don't really understand why a transaction shoulf fail if it has too many signatures, but there are lots of good ideas there, seem like more thought out versions of much of what I have designed and built in weave. We can gladly incorporate some inspiration from that.

alpe commented 5 years ago

Q: How many members (individual signatures) do we need to support within the voting use case? Just to clarify: with the multisig, we won't catch the No votes nor can we enforce a timeout on the process. This needs to be handled off-chain in a transparent way.

ethanfrey commented 5 years ago

Yes for no votes and timeouts, we need a different contract. However, there is an implicit timeout if any of the signers use their account for anything else and thus invalidate the nonce.

I would say this only works for short-period voting for a relatively small group of people (eg. 30 for governance). For general voting, you are right, it is missing many features.

It may also be useful for some sort of social backup. Like using a 3 of 7 multisig to hold my balance... I have 3 votes, 4 of my friends each have one. If I cannot access my account, I need to get 3 of those 4 to update my key (multisig member).

Maybe we should be more explicit about possible uses before going deeper in the design

alpe commented 5 years ago

Signatures verification consume significant CPU resources. Of course, using a dozen of signitures for each submitted transaction won't result in the network congestion, however it can slow down ledger closing. Therefore, it's rather a protection from lazy developers which may tend to use as many signers as possible in multisig schemes in order to avoid coding elaborate algorithms and dealing with thresholds.

https://stellar.stackexchange.com/questions/2291/why-can-a-multisig-transaction-fail-on-too-many-signers/

ethanfrey commented 5 years ago

Nice, but you can also increase the gas cost / minimum fee for the signatures. Not to be put a hard limit, but rather charge for it.

ethanfrey commented 5 years ago

@ethanfrey will review @alpe spec document https://docs.google.com/document/d/1J3zUUKw06E6yLviwrRUlVMO_MMa_NDxgov3xlmLctrs/edit and integrate it into the above requirements.

Please pause work on this issue until requirements are clarified (before Wednesday)

ethanfrey commented 5 years ago

Scenario

To make use of the weighted multisig contract the following examples describe some use cases which are inspired by the Stellar doc.

Stellar Example 1: Anchors

A backup master key + Signing key

Stellar Example 2: Joint Accounts

Any of 3 people can authorize a Tx but only all of them together change the contract

Stellar Example 3: Company Accounts

Any 3 of 6 employees need to agree for a Tx

Stellar Example 4: Expense Accounts

The contract is controlled by 1 admin but Diyuan or Emil can authorize TX, too. Only the Admin can modify the contract, though.

Lock an account

A signing key can authorize TX but the contract is locked and can not be modified anymore

husio commented 5 years ago

For the last example Lock an account this was originally not possible as the validation was preventing from creation with such configuration. Maybe instead of using admin threshold greater than sum of weights it is better to add a random signature to bump the total weight value.

ethanfrey commented 5 years ago

We could also consider changing the validation. Activation threshold must always be reachable. Admin maybe not??

I just didn't want people to remove a member and accidentally render the contract un-usable