Hi Tom — all good ideas there.

We’re already working on a form of limited sandboxing, sufficient in order to do some sanity checks on versioning in #4548. In principle, this could be extended further.

The idea of auto-rolling back a runtime upgrade is also pretty decent; there’s a few ways it can be done, but wherever validator oracles are concerned (“arbitrary amount of time passes”), we need to be careful to ensure that the sovereignty of the token holders reigns supreme.

Things are complicated slightly by a) finality; b) set_code not taking effect until the block afterwards; and c) the possibility of 50% of validators colluding to prevent an upgrade ever happening.

We are planning to temporarily and automatically halt suspend the finality gadget around upgrade time, which would alleviate (a).

While we can currently adapt to environmental changes through offchain workers, inherent data and their extrinsics, these mechanisms only work for altering the composition of the block that we would build as the child of the chain head. We currently have no logic to govern the possibility of replacing the chain head (or an ancestor of it) with some alternative. That said, we can measure time passing after a block in terms of the number of Babe slots that have gone by with no block (as would happen in a borked upgrade attempt), and could perhaps institute a special block production rule whereby block production happens not on the chain head as is typical but on its parent, replacing the problematic transition. If this were combined with logic that postponed the set_code instruction (or the proposal in general — changing the code isn’t the only way of bricking a chain; it’s just the easiest) then it would be a fairly solid failsafe.

By postponing and not cancelling altogether, we also have a way of ensuring that errant validators could not collude to prevent an upgrade from happening, only to delay the inevitable.