Multisig control should allow signer set update by vega token holder vote

[davidsiska-vega]

At the moment we may end up in the following extreme situation:

1. we have n vega chain validators who are also the n multisig signers controlling the ethereum bridge funds.
2. all n (or a bit more than 1/3) of the vega chain validators choose to switch off their machines and delete all keys.
3. the remaining 2/3 (a bit less than 2/3 depending on rounding) validators cannot produce a valid multisig signers update bundle to remove the pub-keys of the validators who switched off.

Ignore below; @C0deMunk33 will write a different proposed solution.
Proposed solution: it is possible to submit (at most one) proposal on Ethereum that will replace the signers on the multisig with the proposed public keys. Vega token holders can vote on the proposal; after a configurable period of time (can be e.g. a future ethereum block number) the fraction of total vega tokens that voted for the proposal will be counted and labelled fraction_for. If fraction_for >= get_current_threshhold/1000 then the public keys are immediately replaced by the proposed public keys.

[C0deMunk33]

Proposal:
create an "emergency recovery" smart contract that allows VEGA holders to lock their tokens into a vote which, if passed, would change the signer set data hash.

Since every user can pull their stake from the staking bridge, if things go wrong everyone pulls from stake and votes on the emergency recovery by locking those tokens for the duration of the vote

[davidsiska-vega]

and votes on the emergency recovery by locking those tokens for the duration of the vote

How will the new signer hash be fixed on the "emergency recovery smart contract" for the duration of the vote?

[Vegaklaus]

Alternative/Additional way we could do that:
Create two new functions in the bridge

• vote (hash) locks a particular key to a new set of validators (defined by hash). This can be done/changed/withdrawn at any time
• evaluate (hash) counts the votes of all locked keys to that hash and checks if it exceeds a threshold. If so, the votes are deleted and that hash is installed as the new set of validators. If hash=0, then the threshold is lower than for any other hash (to make it cheaper to lock the bridge than to reset it.

Open questions: Can people vote for both locking the bridge and for a new set ?
How do we set the thresholds, especially as they're hard to change and custodians might get a lot of voting powers; we could have some anti-whaling in there so they don't accidentally dominate the show, but that's easy to circumvent
Do we want a voting period, or do it fully asynchronous
How do we handle unissued tokens ?
Do we want vote delegation (i.e., delegate (key), which means I vote as 'key' does; this might help the more passive token owners

[Vegaklaus]

Since an ersatz validator with insufficient ownstake can't be promoted to validator, they'd lose their whole purpose if we'd allow them in, so I'd say they should be demoted and then we have fewer ersatz; this

• makes it more visible that we need more validators
• immediately solves the payment thing (no ownstake, no reward)
• probably saves some checks when a new (and better qualified) pending validator comes in.

There is then the whole issue on what to do if there's generally too few qualified validators, but if that's triggered by ownstake it just means that parameter is too high and needs to be reduced. There is one scenario here that is a bit worrisome, if Vega goes to the moon very rapidly, governance might not be able to reduce ownstake to make it more reasonable fast enough to allow new validators to join at a decent price (need to think that through a bit more carefully)

[Vegaklaus]

Two additional options:

• Decaying thresholds - the voting threshold is set comparatively high (e.g., 51%), but decreases a bit for every block in which no bridge transaction is performed (i.e., if we have no validators, it gets cheaper over time to define a new set)
• 'All-is-good' votes - it is possible to issue a vote saying 'I'm totally happy'; if the threshold to replace the validators is x, and the fraction of happy voters is y, then it requires x+y votes to replace the validator set. This allows for lower thresholds, as an adverse takeover can countered (this would require to have some minimum voting period to work)

[Vegaklaus]

One more thing: If we're not careful, all unissued tokens have voting power here, so the decentralisation would be not very decentralised. We can block the vesting contract (though this would also block vested, but issued tokens), or do something more complex blocking an individual tier (@C0deMunk33 can judge that)

[Vegaklaus]

Decisions so far:

• vested tokens can't vote, so we don't have to take the unissued tokens into account to ingrate the vesting contract or worry about unissued tokens voting.
• The decrease of thresholds will be implemented, with three parameters max, min and decay rate to be defined. Decay is linear.
• Preference is for locking the tokens in a separate voting contract to prevent a double vote through voting, selling, and voting again @C0deMunk33 . This automatically causes unstaking, as from a Vega point of view, this looks as if the voters sell their tokens. The alternative would be to register an Ethereal key for a vote, and count the weights at evaluation - that'd mean the evaluation is expensive though, as it needs to go through all the votes.
• Every voter can at any time 'unvite', for example if they stop believing and want to sell their tokens
• The voting-contract will be a completely separate one for audibility (which also means minimal changes at the bridge, as all it needs in addition is accepting a new hash from the voting contract).

Open:

• Should we allow to vote for multiple proposals (say there's two good ones, and I just want something to happen ans support both) - [ probably we want multiple]
• Is there a minimum/maximum voting time ? [I'd say not necessary]
• Are votes automatically removed (after timeout/after successful change/...) ? [Not necessary, let's keep it simple]
• Legal question - does voting cause a taxable event in some countries (as it moves the tokens)?

[gordsport]

closing as this is to be covered in

• Multisig improvements for scaling #1503

Ive linked this issue in the above so not to lose track of the information