[Protocol3] Support DEX upgradability be default

[dong77]

OwnedUpgradeabilityProxy is very convenient to make sure a DEX is upgradable. The issue is that user assets are at risk -- the owner of the proxy can always upgrade the proxy to point to another contract that may move user fund.

My idea is to disable instant proxy upgrade to arbitrary contract and only allow the proxy owner to schedule an upgrade to a declared address in advance, for example, 30 days. When a scheduled upgrade is still pending, the owner can cancel it or schedule a new one to replace it, and the waiting period shall restart.

@letsgoustc @Brechtpd @hosschao please let me know what you think.

[dong77]

BTW, we are of course assuming DAOs are not ready. The objective is not to prevent DEX owners from upgrading to a malicious contract, but allows users of a DEX to have enough time to respond during the waiting period.

[dong77]

After talking to @Brechtpd and @letsgoustc, a better way to offer transparent upgradability is to create a VersionManager that always maintain the latest version and force each DEX's proxy to point to the lastest version.

[dong77]

Here is the basic idea.

Right now we have ILoopring3, but in the future, we may have ILoopring4, ILoopring5. And we have to assume they are not compatible. For Loopring3, the current design allows the creation of multiple exchange instances (each with its own id), but if we use a proxy instead for each DEX, we only need to have one single exchange instance behind all the proxies.

First, we can ask ILoopring3/4/5 to implement a new interface called ILoopring, which has the following methods:

interface ILoopring {
   function getProtocolInfo() returns (uint16 version, address dexInstanceAddress);
   function registerProxy(address proxy) returns (uint dexId); // this will also initialize the proxy's exchange ID
}

When ILoopring3 is deployed, its constructor will automatically calls the createInstance function -- currently public but should be private -- to initialize the address _dexInstanceAddress field that will be retuned by the getProtocolInfo function. But the dexInstance's id will be 0.

We then create anIVersionManager instance which implements the following:

contract IVersionManager {
  struct Protocol {
     address loopring;
     address instance;
  }
  mapping (uint16 => Protocol) protocols;

  function getProtocol(uint16 version) returns (address loopring, address instance) {
    Protocol protocol = protocols[version];
    loopring = protocol.loopring;
    instance = protocol.instance;
  }

  function registerProtocol(address loopring) {
    ILoopring loopring = ILoopring(loopring);
    (ver, instance) = loopring.getProtocolInfo();
    protocols[ver] = Protocol(loopring, instance);
  }

  function createExchange(uint16 ver) {
      Protocol protocol = protocols[ver];
      ILoopring loopring = ILoopring(protocol.loopring);
      ExchangeProxy proxy = new ExchangeProxy(ver, address(this));
      loopring.registerProxy(proxy);
  }
}

The ExchangeProxy will be aware of the IVersionManager:

contract ExchangeProxy {
  constructor(uint16 _version, address _versionManager) public {
     setVersion(_version);
     setVersionManager(_versionManager);
  }

  function implementation() view public returns (address impl) {
    IVersionManager vm = IVersionManager(versionManager());
    (_, impl) = vm.getProtocol(version());
    assert(impl != address(0));
  }
}

@Brechtpd please comment.

[Brechtpd]

Looks good. How would we do small backwards compatible changes to the Exchange implementation? It seems like currently it's a single Exchange implementation / Loopring version (a single call to createInstance in the Loopring contract to create the implementation contract). Because all the staking is done on the Loopring level for these exchanges the Loopring contract cannot be easily swapped for another (so doing registerProtocol on the same version somehow cannot work easily). Will it be possible to update the implementation contract address for an existing Loopring contract (when, of course, we are sure it's backward compatible)? Or maybe this is possible on some other way (a similar proxy design pattern on the Loopring contract)?