Final Governance Issues about cosmos HOT 16 OPEN

So I HODL my vote.

from cosmos.

Software upgrade process could be solved if each block also needs to submit which software version is being used, requires changes to sdk (maybe tendermint too for tendermint upgrades?)

from cosmos.

Addressed some of bucky's comments here: #83

from cosmos.

I will just recap the state of the discussion so that everyone can catch up.

Parameter values

We need to decide on values for:

• MinDeposit: minimum amount of Atoms that need to be deposited on a proposal for it to enter voting period
• MaxDepositPeriod: Maximum period for users to deposit Atoms on a submitted proposal
• GovernancePenalty: %of Atoms that will be slashed from validators' stake if the don't vote on a proposal
• How many validators need to signal new version before switch (see Software upgrade process below)

Use urgent or not

The question here is whether we have one process or two processes.

Option 1: One process

If we choose this option, all proposals will follow the same process. The rule is that the proposal is accepted if:

• At the end of the voting period, more than 50% of votes are Yes votes (excluding Abstain votes) and less than 33% of votes are NoWithVeto votes.
• OR if more the ratio of Yes votes to Total voting power is superior than 2:3.

Option 2: Two processes

In this option, there are two processes. The submitter of the proposal can choose to submit it as regular or urgent.

• Regular process: Proposals cannot close before the end of the voting period. At the end of the voting period, proposals are accepted if more than 50% of votes are Yes votes (excluding Abstain votes) and less than 33% of votes are NoWithVeto votes.
• Urgent process: Proposals are accepted if at the end of the voting period, more than 50% of votes are Yes votes (excluding Abstain votes) and less than 33% of votes are NoWithVeto votes OR if more the ratio of Yes votes to Total voting power is superior than 2:3.

Edit: we have 3 options now, see comment below

Discussion

This was discussed at length here: #80 (review).

I'm in favour of two processes for two reasons:

• Better balance of power: Delegators have a process where they know for sure validator won't be able to close the proposal before the end of the voting period. Validators have to actually become byzantine and censor votes if they want to prevent that, or re-submit the proposal as urgent, which would be immediately seen (re: clarity). Even in the latter scenario, the two proposals (one in regular, one in urgent) would each follow their designated process. If the proposal gets accepted as urgent but rejected as regular, then it will clearly show a divergence of opinion between delegators and validators. Delegators will thus be able to identify which validator diverge in opinion by looking at how they voted on the urgent proposal, and move away from them. The only stable state of the network is when validators and delegators are aligned.
• Less timing issues: If there is only one process, validators could close the vote early (intentionally or not). I think many proposals will benefit from having the full voting period. It's good to have a process where delegators know they can take their time to vote and validators do not fear to vote early. You could say that if we have only one process validators would have an implicit agreement to let delegators vote, but we don't know that for sure. I prefer to have it explicitly implemented.
• Better clarity overall. With two processes we can clearly see what delegators think if needed, which is not the case if we have only one process. Just submit the proposal as regular.

Deposit recovery

We need to decide whether users that deposited on proposals that never reached MinDeposit can be reimbursed or not.

Software upgrade process

Current idea is to follow a two steps "signal and switch" process. When a SoftwareUpgradeProposal is accepted, validators have to install the new version while still running the previous one. Once they have, they start signalling that they're ready to switch. Once 2/3+ of validators have signalled the new version, they automatically switch. It has been suggested to include the version in the block, so that validators will only sign blocks of the version they're running. Questions that remain are:

• How to handle the switch programatically
• What to signal and where. proposalID should be signalled imo so that everyone agrees on which proposal the new version is based. This information could be included in the precommit. Needs to be discussed.
• Include version in block yes/no
• How many validators need to signal for switch to happen. Initial value of 2/3 means that blockchain will halt if a single validator goes offline (see: #80 (comment)). We need to decide on a value between 2/3 and 3/4

Structures in storage

Proposals are identified by their proposalID. However, data storage structures have not been decided yet. I've used lists as placeholder to illustrate the logic in the spec, but this will likely not be the data structure we use. @sunnya97

from cosmos.

Ok so we are lacking consensus on urgent proposals. We have 3 options for now:

1- Only one process, process is urgent. This means that proposals are accepted if at the end of the voting period, more than 50% of votes are Yes votes (excluding Abstain votes) and less than 33% of votes are NoWithVeto votes OR if more the ratio of Yes votes to Total voting power is superior than 2:3. Supported by @jaekwon

2- Only one process, process is regular. This means that proposals always undergo the full voting period. Urgent proposals are handled off chain. Supported by @rigelrozanski, @adrianbrink and @ethanfrey

3- Two processes. One urgent and one regular. Type of proposal is chosen by submitter. Supported by @gamarin2, @jessysaurusrex, @sunnya97.

We need others to weigh in, @ebuchman

from cosmos.

Just talked with @sunnya97 and @adrianbrink - we're in agreement that urgent proposal should be handled off-chain for sensitive bug fixes. Validators should be able to send a switchchain transaction which indicates to everyone that they have upgraded the software after a certain block

from cosmos.

Just catching up on this.

Of all of the proposals outlined here, I prefer most the two-process model for the reasons shared by @gamarin2 . Every issue that comes up will not necessarily have an equal weight or urgency, and this process allows for some issues to be handled as “business as usual” while others can be expedited as necessary. This is especially important because at some point, we will be faced with an issue that does not give us as much time as we’d need to complete a full regular process. Having an ‘urgent’ path also gives us the ability to retain transparency and open communication even when we’re in a time-sensitive situation.

My second preference is for the ‘regular process’— the pre-determined amount of time makes for a resilient voting process, and it provides sufficient opportunity for validators to have a voice and be active on a specific vote. Though we wouldn’t have the ability to expedite an issue, we would have an incident process in place for urgencies and emergencies. While going off-chain is not ideal for transparency and communication, we can publicly commit to outlining incidents and issues that are handled off-chain so that our community knows what happened and how decisions were made.

From a security perspective, there are a few significant risks and exploitable vulnerabilities in having only an urgent-only model for voting in place. A couple of issues stand out to me:

• Because the ‘urgent’ process creates a race condition among validators, votes on a particular issue may have different weight and value at different times. Depending on when a vote is cast, a validator can have a disproportionate impact on the process that makes other validators feel as if their input is not being listened to. This is absolutely not an argument we want to see happen or be a part of, especially if it happens with a divisive or contentious issue.
• A group of validators could call for an urgent vote at times when others are not available (i.e. a Sunday evening after 11pm) and railroad an issue through the voting process with little to no notice. This presents an opportunity to shut down any kind of debate or discussion around an issue, which is a significant problem.

If the ‘urgent’ voting process were exploited or gamed enough times through either of these methods, there is a significant risk of validators losing trust in the process and feeling as if we do not practice the values around consensus that we preach. Depending on the issue at hand or number of times the process is gamed, this could have the potential to become a major issue within the community/industry, and an ‘urgent’ -only voting process that is used to shut down discussion could pose additional risks to our reputation and trustworthiness.

from cosmos.

If the validators act distrustfully towards the delegators then delegators can hold a non-urgent vote to regain an old protocol - validators will get slashed for not upgrading to the new protocol enforced by the non-urgent vote. Worst to worst the community can always fork out a crappy group of validators (doubt this would ever happen though). I wholeheartedly (and this was the conclusion reached through discussions) do not see any circumstance besides exploitable bug fixes (which effectively need to be resolved in secrecy) that would require the a proposal to be pushed through in less than a week... seems outrageous - as I see it the whole point of governance is to involve the community - not to act as a communication channel between validators, that can be done in a seperate channel (ideally encrypted and dynamic with current validators).. The vast majority of proposals will include opportunity for delegator involvement - I don't see this secret-urgent process as a replacement for governance, it's the emergency mechanism for the people who are actually running the network (aka. the validators exclusively)

from cosmos.

@rigelrozanski: we're in agreement that urgent proposal should be handled off-chain for sensitive bug fixes

I don't see any reason why we shouldn't also put that on-chain, since all of our tooling etc will be on-chain. If the chain has halted, then anyone can run a fork and all the logic etc would still work as long as it pointed to the right fork. All 1 implementation, 1 flow for discussion, which happens "on-chain", but the chain just might not be the "main chain".

I still hold the same position...

I think flagging a proposal as "urgent" is fine, because it can wake up validators, red flashing lights and sirens, paging on-call devops etc. If it wasn't actually urgent, then we'll maybe figure out some punishment for it later. The whitepaper specifies or hints at the ability to say "burn that deposit, this proposal is junk", and that would also work for "burn that deposit, this wasn't urgent".

Otherwise, proposals should work the same whether urgent or not. It's not considered having "passed" unless it receives >50% of the votes, accounting for delegation power and any delegator overrides (manual vote to override the default vote of the validator(s)). If the delegators are too late in showing up for their vote, then perhaps it was (actually) an urgent matter, and it passed despite the lack of delegators' support.

If we require a waiting period before a proposal is decided to have "passed" in order to let the delegators voice their opinions, then we lose the opportunity to respond to urgent matters. So there must be an implicit contract that for urgent matters (regardless of the "urgent" flag), the validators have to make a best-case judgement call. Perhaps, how to resolve the delegator-lag issue should be specified in the proposal, so that validators can judge for themselves what they're actually voting for. Until we see some options it seems to me that it's better to leave this open for now.

In any case, whether a proposal is marked "urgent" or not should be cosmetic, and have no effect on the process of actually voting or deciding.

For example, a Byzantine proposer can propose the vote for a really urgent matter, but not flag the proposal as "urgent". Now, should voters vote yes for that, or vote yes for the alternative (newer) proposal that is marked "urgent"? The solution to this conundrum/wrinkle-in-logic is to ignore the flag. But it could still be useful to wake up devops in the middle of the night.

from cosmos.

@jaekwon consider this: One year into operation, shopkeep tellers have cosmos integrated into their payment machines, we can't halt cosmos. It's midnight in north america, the sirens go on, there is a critical bug in the code which allows anyone to effectively steal money from somebody else's wallet... the bug is posted as an urgent proposal, even with the implementable fix code... it takes approximately 1 hour (idealistic) for all the validators to come online, vote on the proposal, and upgrade their code base. During this one hour period of time several malicious black become aware of the bug and are able to steal atoms galore.... How is this exact scenario dealt with in your proposed solution?

from cosmos.

I don't see any reason why we shouldn't also put that on-chain, since all of our tooling etc will be on-chain. If the chain has halted, then anyone can run a fork and all the logic etc would still work as long as it pointed to the right fork. All 1 implementation, 1 flow for discussion, which happens "on-chain", but the chain just might not be the "main chain".

Okay, maybe I can clarify a bit. By off chain, I think I just meant coordination through secret-communication channels - which can still be on chain need be. I'm not as concerned with the halted chain scenario - but more the above example ^ .
Note that with the secrecy mechanism - it can still just be one process flow / one chain - The idea was that if there was an urgent update agreed by the validators in secrecy, they would be able to make an update to the application logic in a single block effectively signalling to everyone else they must upgrade this is the "switchchain" described earlier. As soon as the this block would be sent then potentially malicious transactions would no longer get accepted. This mechanism is much like a hot-patch

If we require a waiting period before a proposal is decided to have "passed" in order to let the delegators voice their opinions, then we lose the opportunity to respond to urgent matters.

I can't think of any examples of urgent matters which wouldn't be sensitive critical matters which would require the use of secrecy - can you think of any examples?

from cosmos.

I agree that the only things that need to be done urgently are probably things like catastrophic bugs. These should be coordinated in private with the validators, otherwise people will exploit the bugs. The validators can prep a new chain to deploy and then send a "kill chain" block to the old chain which kills that chain and notifies all clients of this and how to connect to the new chain.

As for most normal processes, I think they should be non-urgent as not having that disenfranchises delegators. All stakers have a right to participate in governance, but if you allow validators to move forward with something without even giving delegators a chance to override their vote, that's very dangerous.

from cosmos.

I'm fine with going for only 1 process. I lean in favour of chosing the regular for the following reasons:

• No timing issue. Validators and delegators know they have the full voting period. Validators can vote without fearing to close the vote to early, and delegators won't fear being too late to vote
• I think delegators will be fine if hot fixes are handled by validators off-chain. The problem is when there is a contentious, non-urgent vote that needs everyone's attention. Let's take the hard spoon for example. People are currently having heated debates on which option is the best. I don't want to have to rely on the good will of validators to let delegators vote before they do.
• If we assume that validators will always vote before the end of the voting period (because otherwise they get punished), then votes will always close before the full voting period. Delegators won't be able to predict when votes close, and many of them will be left out. Some will be mad, but I suspect most will just stop participating in governance. Overall I fear the urgent process would create a system that favours validators too much, to the detriment of delegators.

from cosmos.

@jaekwon consider this: One year into operation, shopkeep tellers have cosmos integrated into their payment machines, we can't halt cosmos. It's midnight in north america, the sirens go on, there is a critical bug in the code which allows anyone to effectively steal money from somebody else's wallet... the bug is posted as an urgent proposal, even with the implementable fix code... it takes approximately 1 hour (idealistic) for all the validators to come online, vote on the proposal, and upgrade their code base. During this one hour period of time several malicious black become aware of the bug and are able to steal atoms galore.... How is this exact scenario dealt with in your proposed solution?

1. We write the hub so that we never have to urgently patch something. Make it super conservative in featureset, etc.
2. We can always roll back with a re-org. But there are 2 things that we can't roll back:
   a. If a peg contract is about to get wrongly drained
   b. If private keys are about to get exposed.

We mitigate 2.b. by making it a separate component that can be upgraded separately. We mitigate 2.a. by a variety of techniques, which really should be discussed separately. To prove that we can delay that discussion... well, we can always make peg withdrawals take X-hours longer than it would otherwise... so we can always make it into a "non-urgent" problem.

I see no reason for validators too coordinate in private for anything urgent, and for all potential issues I think we can come up with countermeasures to prevent them from happening. Any specific hypothetical cases for urgency?

@Jae: If we require a waiting period before a proposal is decided to have "passed" in order to let the delegators voice their opinions, then we lose the opportunity to respond to urgent matters.

@rigelrozanski: I can't think of any examples of urgent matters which wouldn't be sensitive critical matters which would require the use of secrecy - can you think of any examples?

For example, we could introduce a "circuit breaker" that halts any peg-withdrawals across all CosmosAlliance pegs. We can always figure out what went wrong (if anything went wrong) and fix it later with a circuit breaker. Better that people can't transact, than for money to be given to the wrong people, or the right people losing the money wrongly.

Or, how to coordinate a counter-measure against an attack that is happening to the network. Classic BFT scenario... only 68% of validators appear to be available.. what do we do?! Quick, reorg here! No there! Which one?

We don't need secret conventions. This isn't about recreating the illuminati social circle. It's more about radiating light outwards, and bringing accountability via transparency while preserving privacy.

from cosmos.

@jaekwon

We write the hub so that we never have to urgently patch something

That would be nice, but I think it will be difficult to guarantee (at least in golang - maybe in haskell we actually could) - seems like kind of an absurd premise to base software on

If we move forward as you've suggested - There may at some point need to be secret upgrades which will be slipped in to a governance approved updates such as the monero upgrade.

plainly put if you reveal a bug in a governance proposal (which would need to happen in this system) then you greatly danger the network to attacks before the network is upgraded.

As a new alternative, I would suggest that we allow for special parties (validators or party with large slashable stake) to submit special proposals which simultaneously create a normal proposal and halt all transactions which meet some arbitrary criteria - this would need to be some kind of extremely privileged proposal type with a decent slashable stake to prevent abuse - or maybe we just use the validators regular stake for slashing here. This way one could in fact submit a bugfix proposal which contains details of how malicious activity may occur, while also putting a halt to that activity until governance votes on the solution.

^^^ maybe this is really just an extension of your idea of the circuit breaker - I do however think it should be for more than just peg zone transactions. Right, if we can easily avoid re-orgs why wouldn't we?

This isn't about recreating the illuminati social circle. It's more about radiating light outwards, and bringing accountability via transparency while preserving privacy.

You really are a cypherhippy hahahahaha

from cosmos.

Ok we'll start implementation with @jaekwon's option and modify it later if we end up deciding for another.

I'll modify the spec accordingly.

from cosmos.