Can these emergency proposals only be submitted when the governance canister is down? Will this be enforced in code?
We pondered this but found no viable way to enforce this that would retain an operational advantage.
I’m also curious why only node providers that participate in the NNS subnet can submit these emergency proposals. Is it totally random which node providers happen to run nodes assigned to the NNS subnet? Or is there some special requirement / privilege?
Because this way the security assumptions are the exact same as the underlying system. I.e. we’re not giving more power than it already exists, just making it more explicit and auditable.
Also, what happens when the root canister goes down?
Good question. The root canister itself is controlled by another canister, the lifeline canister, which can upgrade it (which in turn is controlled by the root canister, forming a cycle). So if the root canister is broken, it can be upgraded by the lifeline, and vice versa: if the lifeline canister is broken it can be upgraded by the root canister. The only single point of failure atm is the governance canister.
Would it be possible to maintain a backup governance canister that runs alongside the primary one? Perhaps the backup canister maintains a known good state so that if the primary fails the node providers can vote to switch control to the backup canister. Then we can use the normal voting process to bring the system back to where it needs to be.
The problem here is that the backup governance canister would have to 1) have the exact same state as the main canister so that no transactions would be lost, which would imply additional messages and delays in anything that the governance canister does 2) if the governance canister has a bug, it’s likely that the backup would also have the same bug, thus not solving the problem.
If we have to put faith in the node providers during this sort of emergency I’m okay with that; but, I’d like their options to be very limited. Giving them the ability to propose and implement a change to the governance canister seems extremely risky.
In a sense we already do, this mechanism is just about making that more explicit and operationally viable and, more importantly, fully auditable.
I understand. I trust that Dfinity has done their due diligence exploring failover solutions before proposing further dependence on a small number of node operators.
I accept the reality of what you’re telling me. That being said, this proposal doesn’t really seem like it is up for community discussion. Even if we reject it today, it doesn’t change the fact that control of the NNS (essentially the entire IC) ultimately resides in the hands of a few NNS node providers. For that reason I see no point in voting against this proposal.
That being said, I would like to echo everyone’s request that Dfinity be more transparent about their plans for node deployment and data center on-boarding. Especially with regard to the NNS subnet. The only way I see us being able to secure the network is to ensure that the number of NNS node providers is significantly high enough to avoid collusion.
There are methods and technologies being developed to prevent third-party tampering of hardware/software. I trust Dfinity is looking into these solutions as well.
This is not my department but I do know that the general intention is to keep increasing this number more and more as time goes by.
One thing is for sure though, even at the current levels, many more parties would have to collude to maliciously change the IC than would for say bitcoin, if you consider mining pools.
Today @dralves and @whizwang hosted a community conversation on this proposal. Thank you to all those who attended.
I will post the Youtube video as soon as it is live, but wanted to communicate the next steps:
1-pager posted on the forum for review: September 10, 2021
Community Conversation with David Alves: September 16 2021
NNS Motion Proposal submission to approve design + project (Foundation will wait until the very end to vote to consider the early voters): Monday, October 11, 2021. 15:00 UTC
NNS Motion Proposal submission expires Wednesday, October 13, 2021. 15:00 UTC
If NNS Motion Proposal passes, implementation + deploy would take a week or so. Rough range October 18 - 25, 2021.
Not strictly relates to the topic but are there more canisters in NNS?
I mean governance, ledger and registry canisters are well promoted due to their key role, but root and lifeline canisters are just mentioned on medium.
