dapphub / ds-pause

Any particular reason this code is copy/pasted instead of inheriting from DSProxy? We are going to give DSProxy some love soon and I see potential trouble if we make separate changes

ds-pause/src/pause.sol

Line 97 in 4f4086b

// delegatecall implementation from ds-proxy

Also this !! https://github.com/dapphub/ds-delay
We can just deprecate it but have a look first, never hurts to compare

Any particular reason this code is copy/pasted instead of inheriting from DSProxy?

I've also been thinking about doing this.

Originally this contract was using the newer rely/deny memes for auth so wasn't compatible with ds-proxy, but I've since switched back over to ds-auth to allow for easier integration with ds-chief, so that's no longer a consideration.

I think that I would probably prefer to use solidity delegatecall instead of pulling in all of ds-proxy (mostly for simplicity & readability), but hevm does not correctly implement the delegatecall gas semantics atm and there certainly isn't unanimous support for this approach anyway (discussion here).

Finally as a general point I think we are trying to avoid inheritance in our newer contracts (both for readability & ease of formal verification).

Also this !! https://github.com/dapphub/ds-delay
We can just deprecate it but have a look first, never hurts to compare

Yes, I've seen and read over both ds-delay (this was my first choice name 😁) and ds-clock.

After chatting about scope with rune and rain, I'm happy to call this version 1 and get this done as straightforwardly as possible. We can leave ds-delay for a future version when we solve Proxy and its family (including Async)

Ideally pause would be implemented with something like

function exec(bytes32 id) {
    require( now >= timers[id] );
    super.exec(id);
}

Old plan signature defaults to 0 timer argument (no pause - executable immediately). New plan overload gets +1 arg for timer.

The pause is intended as a component in the dss governance system. The delay is important in the scenario where a malicious governance action makes it through MKR voting, as it gives DAI / CDP holders time to exit the system, or honest MKR holders time to trigger emergency shutdown.

If we allow MKR holders to execute plans immediately we allow them to bypass this layer of defense.

Regarding inheriting from DSProxy, I'm not opposed to the idea but I'm actually leaning towards replacing delegatecall with call (it's weird to allow exec to modify internal storage).

Even if we stick with delegatecall I also worry that inheriting from DSProxy would make formal verification much harder.

@nmushegian I think that the changes in #21 mean that we cannot inherit from ds-proxy.

I would either replace this assembly block with the delegatecall from solidity, or pull this ds-proxy implementation out into it's own mixin if it is preferred.

Pls discuss further on #9 🙏 🙂

Code reuse