Thoughts about governance security and logic

Hello everyone.

I come here to post a reflexion I originally posted as a response in the Maker subreddit, because I think it has its place here. The discussion was about the Governance Security Module vote being removed from the voting page, and the fact that Executive votes are hidden after a week to avoid vote dispersion, to ensure governance security.

The system of “governing proposals” is designed for sequential voting (one after the other, the votes from proposal A switching to proposal B up to the point where B has more MKR votes than A).
This leads me to the two following points:

1- If I’m not mistaken this means that during a vote for a new proposal, the governance security is lowered since the votes are split between the governing proposal and the one being voted in. This might be part of the attack vector that the GSM was supposed to prevent, I don’t remember.
The consequence is that voting might augment overall governance risk temporarily, which creates an incentive to stay on the governing proposal and for big holders to stake a lot on it. This leads to the voting system potentially being stuck on a proposal.
Since I originally posted this a new vote has been proposed and it is far from overtaking the governing proposal that has been heavily voted after the potential exploit was disclosed. This leads me to believe that my intuition was right. I don’t see an obvious solution to this issue without a deep change in the voting system, maybe the team has already discussed this, I’m curious to know what you think about it.

2- This means that 2 votes can’t happen in parallel, as it would compromise security because of vote dispersion and could be confusing to voters that would have to choose which proposal is the most important to vote for. (or not understanding why they can’t vote for both, I didn’t understand the fact that votes are “transferred” from one proposal to the other until recently)
For this, I think that splitting the voting mechanism between
1. constants setting (DSR, stability fees, debt ceilings)
2. other governance votes (like the Governance security module vote)
would improve the issue of concurrency voting.
It would be possible for an MKR holder to vote in both voting branches, and the transfer of MKR allocated to proposals would only be inside the same branch. This would not (theoretically) lower security, except if it lowered engagement even more.
While it makes sense to have sequential votes and a unique governing proposal for the system constants, It is less clear why other proposals would fit in the same “proposal pipe”.

Also the UI could gather both proposal branches in the same page with some kind of color code and differentiate in the text at the top of the page like

Currently voting for Activate DSR, Dai Stability Fee, and Sai Stability Fee Adjustments (constants voting)
Currently voting for Governance Security Module Delay (operations voting)

It seems to me that this would avoid lowering the votes and security while improving governability.

I hope this helps somehow or sparks some discussions, I might be totally wrong in my analysis of the system, in that case please let me know.

1 Like

HI @silto ,

Welcome to MakerDAO, You can have a look here

Fill up a presentation of yourself and have a look at Forum Guidelines

Forum Index : https://forum.makerdao.com/t/648

Feedback : https://forum.makerdao.com/c/site-feedback


To answer your post, is it something that would need further talk. They still debate around the gouvernance and management, options.

This could be a great layer of security to add.

Il7v2AY2223new

My bad, I didn’t see the welcome thread.

You are not the only one… :slight_smile:

No worries my friend, and you are more than Welcome !

Il7v2AY2223new

Well it seems like the last vote has passed and proved me wrong about my first point. I suppose big holders and the maker team all jumped from prop A to B at the same time to avoid dispersion, and didn’t stay on the previous proposal like I imagined they would.

1 Like

Hey @silto, welcome to the forum. Glad to have you here.

To your first point, I pretty much agree with you completely. I also don’t think there is a solution other than a deep change to the voting system. That said, I think we will be stuck with continuous approval for some time yet.

To your second point: Yes and no. I actually think that the dispersion problem isn’t too severe of an issue (at least for perhaps 3-4 votes.) It’s difficult to judge of course, and it’s true that it reduces security whenever MKR is split, but in practice I don’t think the dispersion will be reliable enough to exploited in practice. I agree the messaging around the ‘transfer’ of votes could be clearer. The whole system could be clearer to be honest.

The split into different branches is an interesting idea and I quite like it.

Thank you for sharing your thoughts!

2 Likes

Some thought I have:

Maker Governance has been sold as
“Continous voting on state of a system”
But it is not actually true.
Current voting system is more about voting on “State transitions” rather that state itself.

I Guess It had been made this way, to be more flexible, but it has it’s problems what we can see here.

I think a solution is to build voting as a staking system.

First we need define a datastructure that represent valid state of a system.

Then there need to be mechanics to register new instance of datastructure with new proposed values by literally anyone.

Then any MKR holder should be able to stake it’s MKR tokens on any configuration. If leading (with most MKR’s staken) configuration changes because of this action it becomes new configuration of a system with all consequences.

Sure there might be some delay between certain configuration being voted in and it being used, but at this point it is just implementation detail.

The core concept is that insead of voting on state transitions there need to be staking on state of a system

BTW if You change voting with staking MKR tokens are securing a system in much more obvious way.

2 Likes

It could be thought of as being both “state transitions” (like DSR, SF) and “the state itself” (like GSM, OSM). To some degree we’ve been stuck in the risk-parameter voting cycle which has sometimes made it difficult to introduce infrastructure-type improvements like the GSM.

We undoubtedly need to support both. Perhaps by redefining the voting cycle where risk parameters have the ability to be quickly implemented on a weekly basis (like they are today), become coupled with infrastructure changes made on a monthly basis could help highlight e.g. “ah in 4 weeks, we’re voting on this new shiny change, cool”…meaning we could plan for it better. Your idea of the different branches of voting may be a way to do this within the constraints of the current system - interesting idea.

2 Likes

By Saying that we are voting on state transitions not a state I mean, that there is no place currently where i can stake my tokens (independly on using them for let say SF vote) so they build up on GSM Vote up to the point where there will be enaugh to consider GSM accepted,

If that was voting on state @rich.brown consideration about how often we can repeat vote would not have sense at all because vote would be continous. You put thing under voting and wait for support to build up, voting for SF/DSR goes in parallel

maybe YES/NO vote is a good idea? With minimum participation as a parameter (so sum of YES and NO is no smoller than)

For sure there need to be categorisation of votes so any two votes from two different categories do not contradict them selves and user need to be entitle for giving one vote in each category

2 Likes

One of ways It can be done in current infrastructure (without changes in existing voting contracts) Is with use of polling

Let’s have for infrastructure changes nonexpiring Yes/No Polls with some minimum quorum (for example not less than 10000 MKR on a wining side) and add infrastructure change in next executive vote ater both conditions are met

  1. “Yes” vote will be winning
  2. Quorum requirement will be fulfilled

I think also that upgrades should be created in such a way that they can be reverted anytime if community changes it’s mind (By that I mean that “No” is winning when quorum requirement is met). In case of such event, next executive vote should revert a change.

That way we allow every single MKR holder to change his mind anytime (continous voting) and there is no problem with “pushing change untill it pass” that @rich.brown was afraid of.

1 Like