Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Motion Proposal to Allow Emergency Upgrades of the Internet Computer’s Governance Canister Is Adopted
The solution will create an “emergency fallback” mechanism to update the NNS’s governance canister in case it is ever down.
The Internet Computer community is actively shaping the blockchain’s feature and upgrade roadmap, with robust discussion taking place within the Developer Forum. The DFINITY Foundation is committing R&D resources to the Internet Computer ecosystem in the form of technical contributions. Technical upgrades are subject to community discussion, voting, and adoption via motion proposals to the Network Nervous System (NNS).
A proposal (#24807) to “add capabilities for emergency upgrades of the governance canister via node owner/provider proposals” was submitted to the NNS on Oct. 11, 2021 at 15:00 UTC. Voting by neuron holders ended 48 hours later on Oct. 13, with 99.997% approval logged at a voting power of 314,358,478.
The DFINITY Foundation and Internet Computer Association, and by extension their corresponding neuron followers, abstained from early voting until the broader community of ICP neuron holders had a chance to vote on the proposal.
At each stage of a proposal’s life cycle, neuron holders will have the ability to direct the Foundation’s effort in making the Internet Computer more efficient, faster, and easier to use for developers. The community decides what upgrades are initiated and what code is adopted, allowing the Internet Computer to evolve in real time.
There are many types of NNS proposals. This one is a Motion proposal that does not actively change the code of the Internet Computer, but it does provide an on-chain mechanism for the community to vote on its direction and design. This particular proposal was to approve the design and plan of an alternative proposal submission, voting, and execution mechanism that is solely for updating the governance canister in the event that it is down or has a bug.
Summary
All blockchains work on consensus. In most blockchains, the typical protocol-upgrade mechanism is that a project’s community convinces node providers (aka “miners”) to agree to perform a certain protocol upgrade at a certain point in time. This is typically done through many conversations and off-chain agreement.
One of the things that makes the Internet Computer the world’s only adaptive blockchain is its ability to upgrade itself on-chain by allowing neuron holders to submit and vote on proposals submitted to the governance canister, which resides in the NNS subnet. This means that changes to the Internet Computer happen via proposals submitted and automatically executed via the governance canister, which requires over 50% of neuron voting power from ICP token holders.
This is completely on-chain consensus. But what happens if the governance canister is broken or has a bug? How can it be upgraded to fix itself if it cannot accept or execute proposals?
In this case, the Internet Computer would have to fall back to the typical legacy blockchain mechanism for upgrades: the community has to agree on a new binary and convince a supermajority of node providers to deploy it. In order to avoid the pitfalls of this out-dated approach, the proposed solution is to create an “emergency fallback” mechanism in case the governance canister is ever down, but not fall back all the way to “asking a supermajority of node providers to deploy a new version of the binary manually.” The proposed solution is a mechanism to have an alternative proposal submission, voting, and execution exclusively to update just the Wasm code of the governance canister in case it is ever down, which collects votes from node providers instead of neurons (the latter being impossible since the governance canister is down) and requires ⅔ + 1 of nodes to agree.
You can find details, updates, and answers to questions on the proposal’s Developer Forum thread.
Documentation
Timeline
- 1-pager posted on the Developer Forum for review: September 20, 2021
- Community Conversation with David Ribeiro Alves, NNS Team Lead: October 7, 2021
- NNS motion proposal (#24807) to approve design + project submission: October 11, 2021, 15:00 UTC
- NNS motion proposal (#24807) to approve design + project expiration: October 13, 2021, 15:00 UTC
- If this NNS motion proposal passes, implementation, and deployment will take days: October 15–30, 2021.
Pros and Cons of the Proposed Feature
Pros:
- There would be an auditable on-chain trail of emergency proposals that use this mechanism.
- This solution would affect the upgrading of the governance canister only, not any other parts of the Internet Computer network.
- This solution would require the same Byzantine Fault Tolerance (BFT) security assumptions: at least ⅔ of nodes in the NNS subnet need to agree. This is a higher bar than the simple majority of regular proposals and the same BFT assumptions the Internet Computer holds for consensus.
- This solution is meant to be used in case of emergencies so that the Internet Computer community does not have to fall back all the way to the more basic method of convincing nodes and manual upgrading of nodes. This is an easier, safer, and faster safety net than what currently exists.
Cons
- This design solution would reduce the friction for node providers to update the governance canister. One could see the current pain of having node providers agree to update binaries as beneficial.
Basic Questions
1. Has the governance canister ever been down so that nodes needed to manually agree to update the governance canister (⅔ node providers agreeing)?
a. Yes, only once. The first week after Genesis, there was a bug where NNS had reached a max number of outstanding proposals, and was not clearing the backlog. This led to an incident report and various bugs reported in the forums and socials. The NNS was ultimately updated by asking node providers to manually upgrade the software running. Because the Internet Computer is a decentralized blockchain, the Foundation could only ask node providers to do it for the sake and health of the network.
b. Because it would require at least ⅔ of the nodes in the NNS subnet to agree (which is the security assumption of the entire network), this manual upgrade fell within the existing security parameters.
2. Can nodes collude to take my ICP utility tokens?
a. This change would update the Wasm of the root canister, not any other canister (such as Ledger Canister) or part of the network.
b. The harsh truth about all consensus protocols is that all blockchains — from Bitcoin to Ethereum and including the Internet Computer — have the property that if a supermajority of nodes agree on the state of the network, then that is the state of the network. In practice, both game theory and the increasing number of independent parties make this extremely improbable. Though the Ethereum blockchain’s state was famously rolled back after the DAO hack, this has only happened once, and at a high cost. In this case, it would be a supermajority of nodes in the NNS subnet.
c. The Internet Computer minimizes this risk by maximizing the number of independent node providers. The Internet Computer is still young and will continue to add new independent node providers over time; thus, further minimizing risk.
3. Why does the Internet Computer community need this now?
a. Recently, several blockchain networks have experienced significant outages, so it’s imperative to be proactive to continue to safeguard the Internet Computer network. Plus, this is a relatively easy change to make and an action item from our lesson at Genesis, where it was very hard to update the network. This change will make the network even more resilient. The governance canister is too important to risk making it difficult to upgrade. If it is down, all other proposals and upgrades stop.
4. Will this feature take a lot of time better spent elsewhere?
No, it is fairly simple, and as part of the lesson from 3.5 months ago, DFINITY Foundation engineers already have the implementation done, but not deployed yet, which requires approval from the community.
5. Has this feature been security vetted?
a. This feature has been vetted by the NNS team and the Security team at DFINITY.
6. What canisters live in the NNS?
The NNS subnet currently hosts the following canisters:
- Root canister: The controller of all the other canisters, which upgrades them.
- Lifeline canister: The controller of the root canister, which upgrades it.
- Registry canister: The canister that serves configuration to the Internet Computer.
- Governance canister: The canister that implements governance.
- Ledger canister: The canister that receives messages from users to send transactions.
- Ledger archive canister: The canister that archives old ledger transaction blocks.
- Cycles minting canister: The canister that mints cycles and sends them to canister on creation/top up.
- Internet identity canister: The canister serving the Internet Identity dapp.
- NNS front-end dapp canister: The canister serving the NNS front-end dapp.
Canisters are also visible here.
7. What constitutes an emergency?
An “emergency” in this case has a very strict definition: The governance canister is unavailable for receiving/voting/executing proposals due to some factor (bug, DOS attack etc) and thus we can’t rely on the normal, neuron based, upgrade procedure to solve the problem. It shouldn’t be used in any other case.
8. Since not all node providers are created equally (different node providers have different numbers of nodes). What if certain malevolent node providers hold the votes so that the governance canister cannot be updated without “paying for update”?
The underlying security assumption for most BFT consensus protocols is that at most 1/3 of the nodes are malicious (and malicious has a broad definition, can mean buggy, unavailable, incorrect implementations or actively trying to subvert the protocol). This mechanism leverages the same exact assumptions: It will require 2/3 of the votes for a proposal before pushing it through. The alternative of having each node manually upgraded by its node provider to run a new binary, which would be an off-chain event, has precisely the same security constraints: 2/3s of nodes would have to be upgraded.
9. How does the voting (even with node providers) actually occur? What do they need to know in order to vote?
One of the node providers that participates in the NNS subnet can submit a special proposal to upgrade the governance canister. Other providers can vote on that proposal. Both of these things are done through the command line.
10. How would this mechanism actually work? If the governance canister is down then what canister is providing this fallback mechanism?
There is a root canister that controls all the other canisters, thus only this canister can upgrade them. However, currently, this canister does not accept proposals. NNS canister upgrade proposals are submitted to the governance canister which, upon acceptance through neuron voting, tells the root canister to upgrade the given canister. This poses a problem as the governance canister is a single point of failure, if it breaks nothing can be upgraded.
This proposal is to add a special type of proposal with a very limited scope (only to upgrade the governance canister and only submittable by a node provider running a node on the NNS subnet), that can be submitted directly to the root canister. Since governance is broken in this scenario, we can’t rely on neurons to vote, so node providers would vote instead, with the exact same parameters that would be required if they were to force upgrade the ic replica binary instead, but with much less risk and much higher speed. Additionally this is completely auditable because there would be an on-chain record of the proposal and any community member can monitor these proposals since there will be a method to return the current set of pending ones that is open to all.
11. Why do only node providers that participate in the NNS subnet can submit these emergency proposals?
Because this way the security assumptions are the exact same as the underlying system (they are not getting more power than it already exists, just making it more explicit and auditable)
12. What happens when the root canister goes down?
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.
Next Steps
Now that the motion has passed, the research team behind the design will continue to update the community on the project process and timeline.
_____
Start building at smartcontracts.org and join the developer community at forum.dfinity.org.
Motion Proposal to Allow Emergency Upgrades of the Internet Computer’s Governance Canister Is… was originally published in The Internet Computer Review on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.