[DO NOT MERGE] Kill switch: Proof of concept

[facuspagnuolo]

⚠️UPDATE: This PR is only to show the different alternatives we've been exploring. However, we already decided to move forward with one of them you can check out in #518. Although, feel free to review this PR to follow the way of thinking we went through if you want.

---

This PR shows some of the implementations I carried out as a proof of concept to test different cases of how the kill switch could interact with aragonOS.

Intro

Currently, smart contracts applications are upgradeable, which means we can extend their functionality or provide bug-fixes if we want. However, upgrades take time, and time could be critical in some scenarios, especially those where we are dealing with serious bugs in production. For now, there is no way to freeze the lifecycle of the instances of an application if there is a critical issue in any of the contracts being involved. That's where the kill switch comes in, we are trying to provide a way to make those upgrades safer and less error prone. A kill switch would allow any DAO to have full control of these critical situations, where an upgrade is required, preventing them from being exposed to severe exploits or attacks.

Concerns

There are some concerns under discussion about how the kill switch should interact with the application:

• Who is responsible for turning the switch on?
• Under which circumstances a kill switch is allowed to be turned off? Who is allowed to do that?
• What would happen if there is an on-going process of that application? (e.g. a voting on course)
• Is the kill switch actually a binary thing?

Assumptions

The following list describes a set of assumptions that were made in order to limit the boundaries of the possible solutions under discussion:

• Off-chain consensus
• Executed as fast as possible
• Prevent users from performing irreversible actions
• Handle frozen scenarios for on-going processes
• Allow reading actions

Approach

The main idea is to have a single source of truth to tell whether there is an issues with a smart contract or not. This source should be able to be updated by trusted third parties, e.g. a security partner. Then every DAO will have their own settings to decide how they want to trust said source. This way, we can ensure that every DAO can automatically freeze the execution of an application in case of an issue. But note that this should also allow DAOs to ignore, deny, or provide a custom behavior upon delicate scenarios.

Components

Binary vs Severity

I explored two patterns to show different ways of how the status of a smart contract could be informed and consumed. One of them is just binary, where we simply tell what to do if there is bug. The other is an extension of the last one, being able to specify levels of severity to do so.

Issues Registry

All the examples listed below are based on a registry of issues, called IssuesRegistry, that is supposed to provide up-to-date information about the status of an application. This registry should be managed with permissions in order to tell who can update the status of the different applications.

Kernel kill switch

The idea here was to override the Kernel#getApp method to control all the calls for a specific app.

Application kill switch

The idea here was to provide a custom modifier that developers could use to tag specific functions of an app.

---

The following graph shows the interactions between the different kill-switch flavors as the result of implementing both Kernel and Application level switches mixed with booth binary (boolean) and severity-driven decisions:

Note that all combinations can coexist together.

[coveralls]

Coverage decreased (-0.5%) to 99.042% when pulling 341c6c8 on kill_switch_poc into 635dd96 on dev.

[sohkai]

Closing as it's been superseded by #518 :).