Closed ethanfrey closed 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.
@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)
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.
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.
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
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.
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 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)
To make use of the weighted multisig contract the following examples describe some use cases which are inspired by the Stellar doc.
A backup master key + Signing key
Any of 3 people can authorize a Tx but only all of them together change the contract
Any 3 of 6 employees need to agree for a Tx
The contract is controlled by 1 admin but Diyuan or Emil can authorize TX, too. Only the Admin can modify the contract, though.
A signing key can authorize TX but the contract is locked and can not be modified anymore
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.
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
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 aPOST
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 toPATCH
andUpdate
will only overwrite the fields defined. This means: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) andPatchContractMsg
(ony apply diff.(Read below in comments to see some example usages from @alpe 's doc)