New Subnet Creation

This Page is Still Work in Progress

Ever wondered about the meaning behind DFINITY? It’s Decentralized + Infinity. It’s named that way because the Internet Computer is designed to scale infinitely. It means that the Internet Computer can host an unlimited number of canisters (smart contracts), store an unlimited amount of memory, process an unlimited amount of transactions per second. In simple words, Internet Computer is designed to host even large scale social media platforms in a fully decentralized way.

There are two types of widely-used approaches to improve the scalability of a system. (1) Vertical Scaling, and (2) Horizontal Scaling. Vertical scaling means adding more CPU, RAM and disk to a single computer. Horizontal scaling means adding more computers to the system. There is a limit to vertical scaling. But with horizontal scaling, one can achieve unlimited scalability. Internet Computer is one of the first blockchains to successfully use horizontal scaling.

The nodes in the Internet Computer are divided into subnets, each containing a few dozen nodes. The set of nodes in a subnet together maintain one blockchain. Each subnet can host a few thousand canisters and process messages received by those canisters. Each subnet has a limited capacity in terms of the number of canisters (a few thousand), amount of storage (a few TB), and bandwidth (a few hundred transactions per second). But as more subnets are added to the Internet Computer, its overall capacity increases proportionately. There is no limit on the number of subnets that can be added, resulting in unlimited scalability.

We need to do 2 things to create a new subnet.

• Add/Register new nodes.
• Create a new subnet with the registered nodes that were not yet assigned to any subnet.

Adding/Registering New Nodes

We new describe a series of steps that need to be followed to add a new node to the Internet Computer.

• Node provider purchases a NitroKey (a Hardware Security Module), generates a public-key/secret-key pair, and submits an NNS proposal to add his public key to the NNS registry. The community votes on the proposal. If the majority accept the proposal, then the node provider's credentials are added to the NNS registry. From now on, the NNS canisters trust the messages signed by the node provider's secret key. The entire process is specified in the node provider onboarding article.
• Node provider purchases node hardware with the recommended specifications and places it in a data center rack that meets the recommended specifications.
• The node doesn't yet have any operating system. The node provider needs to install the IC-OS operating system on the node. The detailed procedure can be found in the IC-OS installation runbook articles (Installation for SuperMicro, Installation for Dell Poweredge).
• The node provider inserts the NitroKey usb stick into the node machine. The NitroKey contains the secret key of corresponding to the node provider's registered public key.
• The node provider then switches on the node to boot the IC-OS operation system, which starts a few processes including orchestrator, crypto and http adapter processes.
• The crypto process finds that it never generated any cryptographic key material before. The crypto process then generates new cryptographic keys. This includes node signing key, NIDKG key, ECDSA key, TLS key, etc.
• The cryptographic key material need to be registered with the NNS registry. For this, the crypto process sends the keys to the orchestrator, which then crafts a message containing the key material, signs the message with the node provider's signing key present in the NitroKey, and sends the message to the NNS registry canister.
• The NNS registry canister creates a record for the new node and stores its cryptographic key material.
• The node is now registered in the Internet Computer, but not yet assigned to any subnet.

Creating a New Subnet

We now describe the process of creating a new subnet. To create a new subnet, one just needs to submit an NNS proposal. The proposal specifies a type (create subnet) and a payload. A few sample proposals to create a new subnet can be found in the dashboard (Proposal 57048, Proposal 49018, Proposal 55730). Anyone who staked their ICP can vote on the proposal within a deadline. After the deadline, if the majority of the voters accept the proposal, then the subnet is created as described below.

Payload for 'Create Subnet' Proposal

The payload for the proposal contains the list of parameters to be used by the new subnet. Some of the fields in the payload are as follows.

• Subnet Type - The type of the subnet to be created. Subnets of different type might exhibit different behavior, e.g. being more restrictive in what operations are allowed or privileged compared to other subnet types. There are a few types of subnets.
  • Application subnet - A normal subnet where no restrictions are applied.
  • System subnet - A more privileged subnet where certain restrictions are applied, like not charging for cycles or restricting who can create and install canisters on it.
  • Verified application subnet - A subnet type that is like application subnets but can have some additional features.
• Node ids - List of node ids of unassigned nodes to be included in the subnet.
• Replica version id - The version id of the replica software to be installed in the nodes of the subnet.
  • A replica image has to be first uploaded to a publicly accessible server.
  • Then one needs to create an NNS proposal of type "Elect new binary replica revision" and specify the replica image url and version id in the payload. A sample proposal can be found in the dashboard (proposal 92338).
  • When the proposal is accepted by the majority of voters, the replica version is stored in the NNS registry.
  • This replica version id can now be specified in any other NNS proposals including "create subnet".
• Parameters for the P2P layer -
  • gossip_max_chunk_size : nat32;
  • gossip_retransmission_request_ms : nat32;
  • gossip_receive_check_cache_size : nat32;
  • gossip_registry_poll_period_ms : nat32;
  • gossip_max_duplicity : nat32;
  • gossip_max_chunk_wait_ms : nat32;
  • gossip_pfn_evaluation_period_ms : nat32;
  • gossip_max_artifact_streams_per_peer : nat32;
  • advert_best_effort_percentage : opt nat32;
• Parameters for the Consensus layer
  • max_block_payload_size - The maximum combined size of the ingress and xnet messages that fit into a block.
  • max_ingress_bytes_per_message - The maximum amount of bytes per message. This is a hard cap, which means ingress messages greater than the limit will be dropped.
  • max_ingress_messages_per_block - The maximum number of ingress messages allowed per block.
  • ingress_bytes_per_block_soft_cap
  • initial_notary_delay_millis - Initial delay for notary (in milliseconds), to give time to rank-0 block propagation.
  • unit_delay_millis - Unit delay for blockmaker (in milliseconds).
• Parameters for the execution layer
  • max_instructions_per_message - The maximum number of instructions a message can execute.
  • max_instructions_per_round - The maximum number of instructions a round can execute.
  • max_instructions_per_install_code - The maximum number of instructions an "install_code" message can execute.
  • max_number_of_canisters - The maximum number of canisters that may be present on the subnet at any given time. A value of 0 is equivalent to setting no limit. This also provides an easy way to maintain compatibility of different versions of replica and registry.
• Parameters related to cryptographic keys
  • dkg_dealings_per_block : nat64;
  • ecdsa_config : opt EcdsaInitialConfig;
  • dkg_interval_length : nat64;
• SSH Access to Subnet
  • ssh_readonly_access - The list of public keys whose owners have "readonly" SSH access to all replicas on this subnet, in case it is necessary to perform subnet recovery.
  • ssh_backup_access - The list of public keys whose owners have "backup" SSH access to nodes on the NNS subnet to make sure the NNS can be backed up.
• Subnet Features - The list of feature flags to be used for the subnet. This indicates the features that are to be enabled/disabled in the subnet. This includes the following features.
  • Canister sandboxing - This feature flag controls whether canister execution happens in sandboxed process or not. It is disabled by default.
  • Http requests - This feature flag controls whether canisters of this subnet are capable of performing http(s) requests to the web2.
  • Bitcoin testnet feature - Whether or not the subnet is capable of serving requests to the bitcoin testnet canister.
  • Bitcoin - Controls whether the bitcoin feature is enabled and which bitcoin network is supported.

 start_as_nns : bool;
 is_halted : bool;
 subnet_id_override : opt principal;