Questions/Discussion on the Emergency Shutdown

Hello,

yesterday’s “Micah attack” description:

https://medium.com/coinmonks/how-to-turn-20m-into-340m-in-15-seconds-48d161a42311?

resulted in large amount of discussion in the Chat. I am sure the devs, the Foundation, the community and the governance are now handling this situation is the best possible way.

What I would like to start, with this thread, is an organised/transparent/public discussion on the mechanics of the Emergency Shutdown. I chose this forum and not reddit to keep the discussion polite and clean. There is no hurry to answer, no emergency to be addressed, so we can have a relaxed discussion. But I hope it will bring some light to one of the few aspects of MakerDAO that is, as of today, basically untested.

Emergency Shutdown (ES): The ES is a procedure which anybody having >50k MKR can trigger. It causes the halt of the MakerDAO system. Please read here for details: https://community-development.makerdao.com/makerdao-mcd-faqs/faqs/emergency-shutdown

The number 50k was chosen to allow small (relatively speaking, of course, this is still 5% of all MKR) players in the system to fight against bad actors having a majority of voters. Main examples include:

  1. An attacker (as in Micah attack) gets the majority of MKR and votes for something negative (e.g., steal all the CDPs)

  2. A very serious bug is discovered, it can’t be fixed easily. The system is shut down to avoid losses.

  3. A majority (55%, say) of MKR votes on something controversial, like donating 50% of the DSR to wikipedia.org. A smaller party (5% = 50k MKR) decides to block this by shutting down the system.

  4. A stupid whale (with 50k) decides to harm the system by shutting it down.

Now I would like to understand exactly what would happen AFTER the shutdown has happened in these situations. In particular:

A) How are the attackers (cases 1,4) punished?
As micah pointed out in chat, it’s not so obvious that the system can be restarted by “burning away” the MKR of the attacker. Somebody in chat said that one would have to consider a timestamp of the blockchain (of MKR addresses) and basically backtrack it. Of course this would create problems with people trading MKR in the meanwhile, etc. Big problems potentially.

B) What happens in case of (3)?
An obvious answer is: well, the MakerDAO system is opensource, so it will be forked between those who wants to donate to wikipedia and those who don’t. Again, probably the MKR tokens of the “adversaries” will be burned in the newly deployed system.

Is it that simple? Again, restarting the new system by cloning MKR is hard. But aren’t there other considerations? This would weaken the MakerDAO system overall.

One could say “it’s game theory man, if it has bad consequences for everybody, it will not happen”. But I suggest this is a bit naive in the real world. There are plenty of examples of companies bought just to remove competition. Some rich group of people could get to 55% of MakerDAO with the purpose of weakening it.

To cut the question short… I think this scenario has to be discussed. We need to prepare to such events in order to not act on panic when they happen.


TLDR: Micah attack has led me to realise that governance attack and/or voting-majority fights will happen eventually, almost surely. The ES is the tool that MakerDAO has to fight against those. However this tool has never been tested and is not as well described as it should (at least, to me). Let’s discuss about it :slight_smile:


EDIT: Just to show that this might not just be paranoia, please read the very nice post:

There are huge token holders (ETH and MKR) around. Some (see, e.g., CDP 15336) are sophisticated players who managed to keep their identity hidden while making a fortune (and tax evasion). Why wouldn’t they attack the DAO if it was so profitable?

2 Likes

Thanks for bringing this up. I totally agree that the ES is not something that has been talked about nearly enough. I am one of the the developers on the Smart Contracts team at the foundation so I will do my best to shed some light on the technical details and limitations of ES.

How are the attackers (cases 1,4) punished?
As micah pointed out in chat, it’s not so obvious that the system can be restarted by “burning away” the MKR of the attacker. Somebody in chat said that one would have to consider a timestamp of the blockchain (of MKR addresses) and basically backtrack it. Of course this would create problems with people trading MKR in the meanwhile, etc. Big problems potentially.

This would have to be done with an off chain redeploy. With the upgrade of MKR ownership to the MKR Authority calling the stop() function will then not be possible through that authority contract. As far as the ramifications of a snapshot and how that would affect people who trade it afterwards, I won’t speak to that as I don’t do community relations/comms, but technically it is 100% feasible and something I have tested and have code written for if it needed to happen.

What happens in case of (3)?
An obvious answer is: well, the MakerDAO system is opensource, so it will be forked between those who wants to donate to wikipedia and those who don’t. Again, probably the MKR tokens of the “adversaries” will be burned in the newly deployed system.

I am certainly not an expert in all of the game theory that is required to know how this would all play out. From my conversations with others, some people are more confident in this playing out nicely than others.

I am happy to answer any other smart contract related questions about how the ES will work in this thread.

3 Likes

Please someone with more technical knowledge correct any of this…

Imo (3) Would play out as follows: The 50+% of all MKR pretty much can do whatever they want. This has always been true btw. The 5% that ES’d the system based on the majority vote of the other MKR would remain slashed (the ES MKR automatically goes into the burner). While that 5% could fork against the 50% as far as I know there is no defence to majority rule doing what they want other than a minority ES pause. Maker can be forked AT ANY TIME. So the whole ‘fork’ argument is a red herring.

There is no true defense to a 51% governance attack other than maybe Maker foundation minting more MKR to counter this threat. (as far as I know it is still possible for the foundation to mint MKR but I know this was planned on being removed at some point- someone correct me if I’m wrong).

As to (4) The whale gets slashed by the ES and is not made whole by community governance vote. there is nothing to stop this that i am aware of…

With respect to (1). Again it has always been the case that anyone with sufficient MKR can alter the system. Nothing new there and changing this 'security hole, or ‘governance feature’ would require changes to governance and code to change. Remember 1 MKR = 1 Vote and as long as this is true with respect to governance decisions there will always be an exposure to various forms of attack from financially powerful actors. A government could easily pull off this attack and face little to no reprocussions btw.

If you look at the entire swath of defi projects virtually all of them suffer the admin attack in one form or another. And if you believe someone just tore up their keys - well isn’t that just going back to blind trust vs. verify/test? In the loosest sense as far as I can tell the structure of Maker governance is such that large financial players could always attack governance. Is there a way to secure this better? Lets hear the ideas and then discuss what else is sacrificed.

While I do think a serious discussion regarding security as well as system adaptability should be undertaken I honestly want to hear from the people who built this system as all of these questions should have been hashed out long ago and I suspect tough compromise decisions had to be made for practical reasons. If this was just black and white and clear cut we would not be having these discussions now.

Also I want to point out something. It is very easy to find a problem and bash it. Much harder to find that problem and find not one, but two or more possible solutions to propose simultaneously.

I read your article Micah and no-where in your breadth of knowledge make a proposed solution to the issues you saw.

Anyway I see there was a call. I have a baby in my arms, daughter in front of me and wife out taking a break away from the house. I can’t stress enough until I dig into the code I don’t know this system and as an expert in my fields would be looking towards the experts in Maker to speak out on this.

Anthing above consider speculative at best as a reply. Mostly to counter that no-one is trying to talk about this. In the end, while I think this could have been addressed in a better fashion, it is with some hope that perhaps some good discussion and community engagement will happen in positive ways. The idea this will be solved overnight with a single vote as being anything other than a pr pancea is an ignorant idea at best. I think Maker will struggle with this for months if not years down the road until we figure out better governance systems to make Maker more robust against various forms of governane attack while also improving response.

1 Like

The solution to this problem is the governance delay + emergency shutdown. As much as I generally despise on-chain governance, the governance delay + emergency shutdown is something that Maker built that addresses most problems associated with governance attacks. It allows the system to effectively fork away from bad governance decisions.

2 Likes

As to the topic of this thread, one way to burn malicious governors is to lock voting MKR from the time of becoming the hat until the governance delay has passed. If a shutdown occurs during that window of time, the MKR is permanently locked. Upon system restart, if the governance poll was not malicious then MKR would be minted during restart to make voters whole.

For usability and security reasons, MKR in this “locked” state should still be transferable as a colored coin so users can still manage their accounts and roll their keys if necessary, but this colored MKR would not be fungible with regular MKR.

2 Likes

They have better things to do right now. There is other race i think but this subject also is very interesting.

Thanks for this technical answer.

Could somebody in relations/comms please comment on how the snapshot would affect people who trade MKR afterwards? I mean this is one critical aspect of the system, there will be panic in the air after a ES and having a clear, well-documented in advanced and pre-explained procedure is quite important I think.

one way to burn malicious governors is to lock voting MKR from the time of becoming the hat until the governance delay has passed. If a shutdown occurs during that window of time, the MKR is permanently locked.

I think you are right that the MKR is locked for the time between the hat and the end of the delay.

So you are agreeing that there is no technical problem in punishing attackers as long as the ES is performed between the hat and the end of the delay?

Thanks for any further explanation.

1 Like

I don’t believe MKR is locked in the hat during emergency shutdown? I haven’t actually dug into this though.

A cursory check supports my belief that MKR is not locked during emergency shutdown. DSChief.free can be called at the least, which is what turns your locked MKR into regular MKR, which presumably can still be transferred during emergency shutdown. Both the IOU and MKR contracts can be halted by their owner, and the chief is the owner of the IOU and multisig is the owner of MKR at the moment so in theory they could be paused. However, I don’t think ES currently triggers a pause on either? Someone else may be better able to verify this.

2 Likes

Circling back to the discussion of an Emergency Shutdown–any thoughts on when the Maker Foundation will address the Communities questions/concerns? @rich.brown @cyrus @iammeeoh @MakerMan @MicahZoltu @Davidutro @wouter @LongForWisdom @cmooney @andy8052

1 Like

I dont like the idea of not commenting because your not involved in “community relations/communications” just give your opinion on what would happen and make it clear its just your opinion. As a developer you are an expert (or very close to) on the question here so your opinion is worthwhile for the community to see. The more employees at the foundation hide behind the people who are “suppose” to communicate to the community, the farther away we get from a DAO independent of the foundation. Thanks for the response this info is super useful!

2 Likes

Thanks for your explanation here Andy, but I find myself agreeing with Mitote. If not you (which is fair enough), who would be willing to speak to the community relations / comms aspect of emergency shutdown?

@ElProgreso as frustrating as it is to ask questions and not receive prompt answers, I’m not sure that shotgunning notifications at people is the best way to go to get more engagement on the topic.

Leaving aside the fact it’s kind of annoying, even from a rational point of view there is a thing called diffusion of responsibility which basically states the more people you make responsible for a thing, the less likely a thing is going to get done.

Perhaps it would be good to clarify what specific concerns the community has that remain unaddressed?

It seems to me that the main question comes down to:

After a forced emergency shutdown due to governance attack, how do we ensure that the attackers MKR is burned while preventing damage to innocent users?

Feel free to add any additional concerns.

2 Likes

Thanks for the annswer LongForWisdom.

Yes, but not only that! The subject is very complex.

For example. Suppose somebody triggers an ES. Who is going to decide, after the ES, if this was an attacker or a just a user who thought it was important to “protect” the system?

What is the procedure to decide? A Governance vote? Does this work properly after the ES? A fork in the system? Do we have procedures/ GUIs/ etc to make this smooth and not just a mess (probably causing market panic, MKR selloffs, etc)?

In other words, it’s not just the technical “how to burn MKR” question, but also we want to know what are the procedures, the tools, the way the Community and the Foundation will react.

In public buildings, they often do “fire alarm tests” to check that the procedures for critical events are smooth and tested. When you go on a flight, there is a lady that explain to you in simple terms what you need to do and what will happen if the airplan has a problem/crashes. These will not make fires or airplane crashes less dangerous and expensive, but at least they will reduce the panic and allows to quickly do the right think after the disaster, possibly saving human lives.

We need to do/have the same here.

So i guess another more basic question is:

QUESTION: Have the Foundation prepared some procedures (if so, explain), did they think about corner cases (if so, which?), Did they have tools (smart contracts) ready to run to handle these situations? Etc…

3 Likes

@LongForWisdom Fair enough. My intentions were based on bringing attention to the subject, and not letting people skip-out/dodge the question. But I get your drift.

Circling back to what’s more important, with regards to @iammeeoh and question A., I believe we should get some further clarifications–so I’ll leave you with this from an interview in January 2019, as it’s the only guidance that I’ve been able to find with regards to such question:

Laura Shin:

And I’m sorry, in the case of a troll emergency shutdown, how is that person punished?

Rune Christensen:

Yeah. So, that’s my favorite part. So, there’s actually a whole bunch of…like we also have a bunch of game theory around that, right, but I mean there’s basically two types of actors that can trigger an emergency shutdown, right. So, there are the centralized emergency oracles that are, I mean, in the long run they are basically going to be institutions of some sort that are chosen by MKR holders and given the power to trigger an emergency shutdown.

In the short run, they will be sort of multiple independent divisions within the foundation. So, the foundation will run, like, a very sophisticated security infrastructure that then also has the power to do the emergency shutdown and basically like the way to prevent trolling from, you know, centralized legal entities is pretty simple. It’s just using the legal system, right.

So, there will actually be, like, you know there will be legal agreements in place that ensure that someone who abuses that power can actually be, you know, like can be pursued legally and then the other…so, like that should serve as a deterrent but of course it’s not guaranteed to do so and ultimately…

Laura Shin:

But wait, when you say pursued legally, like what law would be broken and there’s different jurisdictions, so how do you…that just sounds…

Rune Christensen:

Yeah. Like let’s say, like…I mean this is actually different depending on which jurisdiction the emergency oracle operates in, right. So, but typically I mean it would basically it will be an agreement between, like, the emergency oracle and then something like well-known entities and institutions in that jurisdiction that are sort of that the community ultimately trusts that if we look at this entire network here and they all have agreements with this emergency oracle, you know, that if they abuse their emergency oracle powers, they can be…you know, there’s some sort of liability there.

Then, like that’s at some point, there is going to be enough guarantees in place that the community actually feels comfortable, you know, whitelisting that particular emergency oracle with the power to trigger an emergency shutdown, and then if like of course it’s still not guaranteed it really is for sure not going to be abused, but then again like the key is that if it is actually abused, it’s still like, you know, it’s not the end of the world.

It is just like a UX annoyance, basically, and the next time that…like once you then have a troll emergency shutdown from such a scenario and you do the redeployment after, then of course you just make sure to not make the same mistake, right, and exclude that emergency oracle and in general can add more, like, strict checks and balances on who gets to have that power."

2 Likes

What do you think the effect of a lock on MKR will be on voter turnout @MicahZoltu ? I think Maker’s approach of not optimising for high voter turnout is okay because of the checks and balances in place. Just wondering this may be too much of a risk even for holders who are keen to vote.

Unclear. I don’t know how many people participate in governance right now only because they can withdraw and sell at any time.

It does seem that having a short time-lock on MKR locked in the Chief resolves the issue of an entity escaping and laundering MKR in the event of a governance attack.

I’m not sure that it would have a huge affect on voting, but I could be wrong. On-chain analysis could help us figure out how often MKR enters and leaves the Chief.

Of course it doesn’t resolve the case where an attacker governance attacks with borrowed MKR, but I think it does improve things.

1 Like

Let me refresh/update.

1 Like

Based on the governance attack mechanisms (one of which was articulated by MicahZoltu) It sounds like a MKR lock is somewhat irrelevant to some of the attack mechanisms but may elimiate or reduce the chance of others.

I also think a lock will steer governance more towards larger players than smaller ones. IF one was to apply a lock on governance I would do it based on size of MKR being locked. Sure this will mean that any larger players will have increased costs if they want to break up their MKR to have less of a time lock to participate in governance based on below

My idea on this.

10K at least a 6 month lock
1K at least a 3 month lock
100 at least a 1 month lock
10 at least a 1 week lock
< 10 no lock.

I keep having this idea that it would be nice if Maker would re-imburse costs of voting for some class of voters (say by buying some of the liquidated ETH with the DAI interest during liquidations and paying it out say once a year in amounts no less than .01ETH/wallet)

Right now it is looking like there are lots of reasons not to vote, and few reasons to vote. The biggest one I can think of is that that the MKR whales pretty much dictate everything voting wise.

BTW: If you want to encourage voting. How about having people connect their user accounts here to wallet addresses used for voting and having this list be used to generate winners? The point is that only one user wallet connected here can participate. Also generate tickets based on the number of votes (i.e. an active wallet voting a lot gets more chances than a person voting once and someone who never connects or never votes gets no chance). This only works if Maker believes the growth of this portal for community interaction and users here owning MKR and voting in governance IS important. Winners either get ETH or MKR. And this is only done once/year.

4 Likes