search

status-im / swarms

Swarm Home. New, completed and in-progress features for Status
92 stars 31 forks source link

Recoverable DApp #25

Closed 3esmit closed 6 years ago

3esmit commented 6 years ago

Preamble

Idea: <to be assigned>
Title: Recoverable System
Status: Draft
Created: 2017-11-18

Summary

Provide framework to emergency stop and upgrade dapps - specifically Status Network.

Vision

The RecoverableSystem contract is a delegate message forwarder to Application model address, or in case that address code is size zero, to Recoverer address. RecoverableSystem address will be storing the value and data storage of the application, but not storing the main business logic neither the recovery logic, but only the emergency stop logic, that is activated by address of Application model's code being empty. The only way of Application model logic being empty is if it was never deployed at that address, or if the code called selfdestruct.

address.extcodesize==0 to emergency stop advantages:

Application model

Application logic model owned by Watchdog, and that this watchdog can call a specific function only in model that triggers selfdestruct, causing the address code size become zero.

Watchdog

Watchdog address is defined in Application model constructor, because it contains volatile code (therefore impossible to recall), Recoverable System should safely reserve watchdog address variable to ensure that is impossible to call the model destructing method in Recoverable System, and if this requires a selfdestruct then it must be through it's own logic. If not reserved, a risk of unknown unknowns is risen. Watchdog contract may be:

  1. a list of curators in a proven-safe multi-signature permission contract.
  2. a proven-safe liquid democracy for electing a new main logic.

The watchdog in a ideal scenario should not share code with the application, as we might have a bug in the tokens and we used that for controlling the watchdog, that would make the watchdog useless. Because of this a InterDAO liquid democracy should be used, that other DAOs could trigger a emergency stop in other DAOs.

InterDAO shared DApp watchdog

A delegative democracy, as specified by https://github.com/status-im/ideas/issues/20, that uses tokens by democratically aggregated DAOs, starting with Status token, can vote for emergency stop a topic. The reach of a quorum on a certain topic would trigger the InterDAO watchdog to call a self-destruct in Application model address of that topic. When adding a new DAO to the InterDAO congress, the current participants must vote for it in the root topic.

Recoverer/Updater

When emergency stop is triggered, in place main logic, a recovering code (Recoverer) takes place that can only set new main code address. The recoverer contract must be extremly simple and NEVER write or read storage besides of changing the application model address. The usual recoverer contract will only change the application model address, but this call must only came from a democratic repair address, that may be:

  1. a list of curators in a proven-safe multi-signature permission contract.
  2. a proven-safe liquid democracy for electing a new main logic.

What type of Recoverer logic need to be defined as a per DApp case, as if the DApp is owned by tokenized stake-holders, then 2. should be the case. More complex cases can be build, but this two types would be the most cases for all DApps.

Swarm Participants

Requirements

Goals & Implementation Plan

Minimum Viable Product

Goal Date: Soon Description: RecoverableSystem Framework

Iteration 1

Goal Date: Later Description: Safe-Proven Democratic Upgrader

Iteration 2

Goal Date: Later Description: InterDAO Shared Watchdog

Supporting Role Communication

Copyright

Copyright and related rights waived via CC0.

3esmit commented 6 years ago

I've implemented this system and worked as expected. ENS based recoverer used: https://ropsten.etherscan.io/address/0x845f9895340c303f8bd6b33f3550e593ab8cee13#readContract (will be reused in case of new upgrade) Old Model Factory (permanently frozen due emergency stop): https://ropsten.etherscan.io/address/0xa81d4be90af686c67de34937a55da53204058dd2#code Old Model (automatically created at Factory constructor): https://ropsten.etherscan.io/address/0x9ff2fe858cf19a4e2ae9247cc99c52a808cdfe06 Emergency Stop triggered at: https://ropsten.etherscan.io/tx/0xf40b5c8269cbc8074b08a2b2a83523acea1c68ca74b1d355def7056f32f37363 Recoverable Forwarder deployed with Old Model: https://ropsten.etherscan.io/tx/0xa9ba6edaf6bc2ad77e8120f84db714ecee79129d9416cf36115deac548bdea4c New system model defined: https://ropsten.etherscan.io/tx/0x95823e505432de8b8a3bbee936cfb9bd2a54d52e1dec1031342e079509651de7

The consensus address used was an externally owned account, but in a production scenario this would be a specifically crafted contract for each case. In the case of a factory that deploy multiple instances that are controlled by different parties, this contract should allow for a controller (such as a DAO) place a new version, and then anyone should be able to request a update coming from the consensus.

The watchdog address used was also an externally owned account, but in a production scenario this would be a specifically crafted contract for each case. There is importance that watchdog action be taken with less bureaucracy for fast action, however this might lead loss of trust, so a InterDAO could be created for managing watchdog of several dapps, using the mixed intelligent influence of cooperation DAO participants, that might even include reward incentive for stopping a bad application or stake punishment for stopping a good application. Other features such as DelegationProxy might help faster action by volatile trusted members of community.

Code available at: https://github.com/status-im/contracts/tree/republic-status/contracts/deploy

naghdy commented 6 years ago

Closing as this seems to be stale now. Feel free to re-open :)