The Internet Computer (IC) is formed by standardized “node machines” from independent owners and installed within independent Data Centers (DCs). Compared with other blockchains, the IC has stronger requirements on the homogeneity of the nodes due to the fact that most of the node resources are dedicated to perform useful work (e.g. executing smart contracts, participating in threshold cryptography) that needs to be performed by all nodes of a given subnet blockchain.
The IC is designed to host mass market applications completely on chain. Thus the state of canister smart contracts on the IC can be much larger than on other blockchains. The nodes also need significant network capacity for managing and synchronizing that state. To meet the requirements of extremely high availability and high throughput, the IC nodes are hosted in DCs. To achieve decentralization, the nodes are owned and the DCs are operated by independent parties. Moreover, the DCs are spread across the globe. Due to this need for homogeneity and capacity, the Internet Computer Association (ICA) publishes specifications for hardware of IC nodes as well as the service levels of DCs.
The IC is designed for anyone to be able to become a node provider (NP). The governance system of the IC, the Network Nervous System (NNS), scales the IC’s capacity by adding more nodes. The requirement of additional nodes depends on the desired capacity (and location requirements) of the IC at a given point in time. The governance system is designed to remove nodes that provide sub-par performance, it is thereby recommended to follow the specifications published by the ICA. The IC constantly scales out its compute capacity by adding new nodes to the network such that it never runs out of capacity.
The network is expected to grow to millions of nodes running from thousands of DCs in the coming years. As decentralization is key to the mission of the IC, many new, independent node providers will be needed to support that growth.
The NNS is the on-chain governance system of the IC. Holders of the Internet Computer’s ICP utility tokens can stake their ICP tokens in neurons to participate in governance and contribute to decision-making, such as voting to determine whether or not a new collection of nodes (also called a subnet) should be added to the network. It has many functions, but the most relevant ones to node decentralization are:
- Maximize the decentralization of the node providership and control.
- Determine the number of nodes required to match the IC’s compute/storage demand while keeping the inflation in check (not minting too much ICP to pay for node provider rewards).
- Set the cost of compute and storage operations for developers.
- Remove faulty or slow nodes from the IC.
- Upgrade the replica software running in the network.
Here are the envisioned steps to become a node provider for the IC:
- Using the NNS frontend dapp, everybody can register to become a node provider. Registrations are approved by means of NNS proposals, voted on by the IC community.
- The ICA publishes hardware specifications for nodes. Node providers can order machines fulfilling these specifications from different hardware vendors.
- Node providers propose new data centers using the NNS frontend dapp. The NNS approves data center proposals depending on how they further improve the decentralization of the IC. For example, data centers in underrepresented geographical locations are preferred over those in locations with many existing nodes.
- Data center operators deploy node machines independently, using the opensourced node software and configuration data retrieved through the NNS frontend dapp.
- The remuneration for running a node starts as soon as the node has joined a subnet.
A node provider performs the following operations:
- Make proposals to become a node provider and to add new data centers.
- Purchase nodes that satisfy the ICA hardware specifications
- Rack and stack the node hardware and install the node software. This work may be outsourced to a 3rd party
- Ensure a guaranteed uptime of the nodes
Canister smart contracts running on the Internet Computer blockchain are fueled by “cycles” which in turn are generated by burning ICP thereby causing deflation. As the number of smart contracts on the Internet Computer grows, so does the need for adding additional nodes.
Each node receives a flat monthly reward calculated in fiat and paid in the form of ICP tokens. This model ensures that the cost that the network bears for running a node is always constant in fiat terms. By keeping a predictable cost the network is able to ensure that the developers pay a flat fee for each operation on the Internet Computer independent of the volatility of ICP. The reward varies slightly based on the geographical location of the node to ensure the IC is able to achieve a wider geographical distribution of nodes. Each node provider continues to receive rewards as long as they guarantee the right quality of service. The rewards are paid by minting new ICP tokens, causing inflation.
The NNS has an algorithmic way to react to the demand & supply needs of the IC to keep the community-desired inflation-deflation range in check. The community updates or interacts with the algorithm via NNS proposals.
- A node is the hardware that hosts and runs an instance of the IC software stack, known as the “replica.” In other blockchains, this may be referred to as a “client”.
- A node provider (NP) is a person or entity that owns nodes that are part of the IC. Each node provider can host nodes in different data centers, possibly in different countries. You can see examples of owners here: https://dashboard.internetcomputer.org/owners
In the NNS, node providers are referenced by a principal. A Principal corresponds to the person or entity who receives the rewards stemming from node participation. An example of a Principal is: 7k7b7-4pzhf-aivy6-y654t-uqyup-2auiz-ew2cm-4qkl4-nsl4v-bul5k-5qe.
- A data center (DC) is a physical location at which nodes reside. Everyware AG, Zurich is an example of a data center where IC nodes reside.
- A DC operator (DCOP) is a person or entity responsible for installing and maintaining nodes within a DC. If the NP owns nodes in multiple DCs, multiple DCOPs may be working for the NP. A NP can also act as a DCOP or outsource the DCOP work to a third party.
Above, we describe the vision for the onboarding of new node providers. In the following, we describe the status of the onboarding process. In the next section, we then provide a roadmap leading from the current to the envisioned state.
Prior to the Genesis of the network, the DFINITY foundation worked to build a baseline reserve capacity for the initial subnets. At Genesis, the IC was composed of 130 nodes.
Immediately after Genesis, the NNS ingested a substantial number of nodes to create a baseline of capacity. As of November 2021, the IC is composed of 451 nodes, some of which are spare capacity that is added continuously to the IC and a few are ready to be used in case of incidents.
Nodes are paid in ICP minted by the NNS as described in the vision.
The IC experienced a strong interest from node providers ahead of the network’s launch in May 2021. In anticipation of the new onboarding process and to avoid very long waiting times, the ICA paused further onboarding in Summer 2021. As of November 2021, there is a backlog of 890 nodes waiting to join the IC. These nodes are owned by node providers who have already been onboarded. This backlog guarantees a steady growth of the network while the onboarding process is further improved and finally opened to future node providers.
The following blockers must be addressed before the IC’s network growth can be further accelerated:
- (A) Reproducible builds: The community, including node providers, shall be able to build the replica software in a deterministic manner. This enables the community to verify that IC update proposals indeed correspond to the source code version specified in the NNS proposal.
- (B) Autonomous node deployment and operation: Empower node providers to install and maintain nodes without any support from the ICA.
- (C) Independent node provider registration: New node providers shall be able to register directly in the NNS frontend dapp.They will be able to submit a proposal to become a new node provider, without the support of the ICA.
- (D) NNS-driven DC allocation: Node providers can participate in NNS-controlled mechanism to elect new data centers. This process shall incentivise the addition of new DCs that further decentralize the IC’s network. Furthermore, it balances inflationary and deflationary forces.
- (E) Availability of node hardware: A new generation of ICA-specified node hardware is planned that shall guarantee global availability and provide a better choice between hardware providers. Furthermore, the next generation shall include the SEV-SNP technology to further improve the security of nodes.
The DFINITY Foundation is currently working together with the community and existing node providers to remove the blockers described above. We estimate to complete this process in Q3 2022 with visible progress during intermediate quarters. Based on community feedback or technical obstacles that we might encounter, the plan might be adjusted.
- (A) Reproducible builds: Reproducible replica software builds are planned to be available to the public in November 2021. This initiative has its own separate communication because it touches many parts.
- (B) Autonomous node deployment and operation: In early 2022, a new deployment process will be introduced based on the reproducible builds (A). Over the subsequent weeks, existing node providers will be asked to update their deployments using the new process.
- (C) Independent node provider registration: In early 2022, future node providers will be able to register via the NNS frontend dapp. In parallel with the onboarding of the currently backlogged nodes, a limited number of new DCs and nodes will be added to the network using the new deployment method (B).
- In order to get started with autonomous node deployments (B) before the NNS-driven DC allocation is in place (D), a small set of new node providers will be onboarded using (C).
- (D) NNS-driven DC allocation: The NNS-controlled DC allocation mechanism will be introduced and control all future node additions. With this step and a new node hardware, see (F), an accelerated network growth is unleashed.
- (E) Availability of node hardware: Different hardware options are currently being investigated. This blocker might be overcome in two steps
- Minor extensions to the Genesis hardware setup to overcome current availability limitations.
- Larger extensions that incorporate additional hardware technologies such as SEV-SNP.
From now on, updates to this timeline will be updated via technical blog, developer forums, and other social platforms.