The Internet Computer is the world’s first web-speed, internet-scale public blockchain, which enables smart contracts to securely serve interactive web content directly into the browsers of end users. It extends the functionality of the global internet so that it can host smart contracts without any limitations on capacity, transforming it into a global computer that empowers developers and entrepreneurs worldwide. A key feature of the Internet Computer blockchain is the Network Nervous System (NNS), an open algorithmic governance system that oversees the network and the token economics that make it possible to build DeFi and dapps, open internet services, and enterprise systems that are capable of operating at hyperscale.
The purpose of the NNS is to allow the Internet Computer network to be governed in an open, decentralized, and secure manner — and it has complete control over all aspects of the network.
It can, for example, upgrade the protocol and software used by the node machines that host the network; it can create new subnets to increase network capacity; it can split subnets to divide their load; it can configure economic parameters that control how much must be paid by users for compute capacity; it can, in extreme situations, protect the network from malicious actors; and it fulfills many other functions as well. For an in-depth overview of the NNS, refer to “Understanding the Internet Computer’s Network Nervous System, Neurons, and ICP Utility Tokens.”
Below is a quick guide to getting started with the Network Nervous System dapp [linked here] and its key functions. The dapp currently provides functionality in four main areas:
- ICP token management (it’s a “wallet”)
- Staking ICP inside “voting neurons” to earn rewards
- Voting on proposals submitted to the NNS
- Creating canister smart contracts and “cycles”
We’ll explain each of these sections and offer details that users should consider when using the NNS dapp.
Note: To login to the NNS dapp, an Internet Identity is required. If you do not have an Internet Identity (or II, pronounced eye-eye), you will first have to create one. (This will only take a minute; see “How to use Internet Identity”.) Internet Identity is a revolutionary new blockchain authentication method, based on advanced cryptography, that allows users to sign-in and authenticate to dapps using devices from YubiKeys to the fingerprint sensor on a MacBook laptop. Whenever you sign in to two different dapps using an II, the dapps see different pseudonyms — i.e. it preserves your anonymity and prevents you being tracked across the dapps you use.
The Internet Computer | Documentation
As a decentralized platform, all changes to the configuration and behavior of the Internet Computer are controlled by…
Internet Identity & NNS App FAQs | DFINITY
The Internet Identity takes advantage of the Web Authentication (WebAuthn) API to provide secure cryptographic…
ICP Utility Tokens
The above interface is an example of a user’s primary ICP Wallet. Users can use this interface to create accounts and subaccounts as well as conduct basic transactions, such as sending or receiving ICP. The individual account addresses are derived from your principal ID but are different from the principal ID. At a later point, the use of special hardware wallets to authorize ICP transactions will also be supported from within this section.
ICP is a native utility token that play three key roles in the network:
- Facilitating Network Governance
ICP can be locked to create neurons that participate in network governance by voting, through which they can earn economic rewards.
- Production of Cycles for Compute
ICP provides a source store of value that can be converted into “cycles,” which power computation and are burned when it is used. The NNS converts ICP to cycles at a variable rate to ensure that users of the network can always create new cycles at an approximately constant cost in real terms, such that the cost of acquiring cycles is predictable.
- Rewarding Participants
The network mints new ICP to reward and incentivize those who are playing important roles that enable the network to function, including: a) the provision of “voting rewards” to those participating in governance, and b) the provision of “node provider rewards” to those operating the node machines hosting the network.
Using an account address, the majority of users will be able to transfer ICP to the NNS dapp from their exchange or wallet of choice by simply following the steps outlined further below in the Accounts section of this article. Users who choose to self-custody with Keysmith and aim to transfer ICP via the DFINITY Canister SDK are encouraged to read more about Integration with the DFINITY Canister SDK. If you’re using an air-gapped computer, consider your options for segregating signing from sending.
Accounts are identified by their account address. Users are also able to derive sub-accounts from the parent account.
Within the ICP section of the NNS dapp, users can arrange to send ICP to other accounts. Each transaction only takes a few seconds and goes through full consensus. (Note: A small transaction fee is required to send ICP. This amount is subtracted from the source account balance.)
To receive transactions, simply provide one of your addresses to whomever wishes to transact with you.
Finally, you can also stake neurons directly from your account. Doing so, will create a neuron with the specified ICP in it (currently the minimal ICP amount to stake a neuron is 1 ICP). This will also incur a small fee.
The above interface allows users to create and manage neurons in order to participate in network governance and play an active role in the stewardship of the open internet. Users create neurons by “locking up” their ICP for a designated period of time, enabling them to engage in governance by voting on proposals in exchange for ICP rewards.
Here is a list of common attributes that users can expect to interact with when configuring their neurons:
The general identity of the neuron object. When a neuron is configured to follow another neuron, this is the value that is used. This is a random value selected at neuron creation.
The ledger account where the locked ICP balance resides.
When the neuron was created.
The maturity of a neuron, which determines its ability to spawn a new neuron and corresponding locked balance of newly minted ICP. When new neurons are created, their maturity is zero. When neurons vote, over time the NNS increases their maturity to reward them.
- Recent Votes (public)
A record of recent votes is maintained. This can provide a guide for those wishing to evaluate whether to follow a neuron, or how their followees are voting.
- Age (seconds)
The period of time that has elapsed since the neuron was created or last stopped dissolving. Conceptually, whenever a neuron starts dissolving, then its age is reset to zero and remains zero while it is dissolving. If a dissolving neuron has the dissolving state turned off, the current time becomes the effective neuron creation date for the purposes of calculating the age.
- State (LOCKED or DISSOLVING or DISSOLVED) computed from DissolveState and the current time
- LOCKED: In this state, the neuron is locked with a specific DissolveDelay. It accrues age by the passage of time and it can vote if DissolveDelay is at least six months.
- DISSOLVING: In this state, the neuron’s effective dissolve delay decreases with the passage of time. While dissolving, the neuron’s age is considered zero. Eventually it will reach the DISSOLVED state.
- DISSOLVED: In the dissolved state, the neuron’s stake can be disbursed using the disburse method. It cannot vote as its dissolve delay is considered to be zero.
Users should familiarize themselves with the following commands to have a better understanding of how to operate their Neuron:
- Start Unlock
The dissolve delay is like a kitchen timer that can only be turned in one direction. It can be arbitrarily increased, but only reduced by turning on dissolve mode and counting down. The neuron can be instructed to start “dissolving.” When the neuron is dissolving, its dissolve delay falls over the passage of time until either it is stopped or it reaches zero. A neuron cannot vote (or earn rewards for voting) when its dissolve delay falls below six months. Once the dissolve delay reaches zero, it stops falling and the controlling principal can instruct the neuron to disburse.
- Stop Dissolving
A neuron that is dissolving can be instructed to stop, whereupon its dissolve delay stops falling with time.
When the dissolve delay of the neuron is 0, its controlling principal can instruct it to disburse the neuron’s stake. Its locked ICP balance is transferred to a specified new ledger account, and the neuron and its own ledger account disappear.
- Increase Dissolve Delay
The dissolve delay of a neuron can be increased up to a maximum of eight years.
When the maturity of a neuron has risen above a threshold, it can be instructed to spawn a new neuron. This creates a new neuron that locks a new balance of ICP on the ledger. The new neuron can remain controlled by the same principal as its parent, or be assigned to a new principal. When a neuron spawns a new neuron, its maturity falls to zero.
A note on dissolve delays
Users benefit the most if their neuron attains its maximum possible value. When considering the locked neuron, that moment is always “dissolve delay days” in the future, which comes closer every day that a neuron is dissolving. Meanwhile, the long-term success of the network will best be served if neuron owners vote with a long-term view toward maximizing the value of the network in the distant future. For such reasons, the NNS incentivizes neuron owners to make their dissolve periods as high as possible by disbursing greater rewards to neurons the greater their dissolve periods, which can be configured up to eight years.
Since votes made by neurons are more useful in decision-making when their owners have a long-term perspective, the NNS also applies more weight to votes from neurons the greater their dissolve delay, and neurons with dissolve delays of less than six months are prevented from voting altogether. Of course, this scheme would provide less benefits to the network if locked balances could be transferred, as this would give neuron owners the option of “selling their neuron” at any time, even if they had to be discounted relative to unlocked balances.
The above interface shows where users can set and configure their neurons as well as vote on proposals submitted to the NNS.
The following actions can be initiated using the NNS dapp:
Have the neuron vote to either adopt or reject a proposal with a specified ID.
Add a rule that enables the neuron to vote automatically on proposals that belong to a specific topic by specifying a group of followee neurons whose majority vote is followed. The configuration of such follow rules can be used to:
a) distribute control over voting power amongst multiple entities;
b) have a neuron vote automatically when its owner lacks time to evaluate newly submitted proposals;
c) have a neuron vote automatically when its own lacks the expertise to evaluate newly submitted proposals.
A follow rule specifies a set of followees. Once a majority of the followees vote to adopt or reject a proposal belonging to the specified topic, the neuron votes the same way. If it becomes impossible for a majority of the followees to adopt (for example, because they are split 50–50 between adopt and reject), then the neuron votes to reject. If a rule is specified where the proposal topic is null, then it becomes a catch-all follow rule, which will be used to vote automatically on proposals belonging to topics for which no specific rule has been specified. If the list of followees is empty, this effectively removes a follow rule.
A neuron can be configured to vote automatically by following other neurons on a topic-by-topic basis. For any topic, a list of followees can be specified, and the neuron will follow the vote of a majority of the followees on a proposal with a type belonging to that topic. If a null topic is specified, this acts as a catch-all that enables the neuron to follow the vote of followees where a rule has not been specified.
Each proposal submitted to the NNS has the following fields:
- ID: The identity of the proposal. The NNS assigns a unique identity to each proposal that it receives.
- Summary: Text providing a short description of the proposal, composed using a maximum of 280 bytes.
- URL: The web address of additional content required to evaluate the proposal, specified using HTTPS. For example, the address might describe content supporting the assignment of a DCID (data center ID) to a new data center.
- Proposer: The ID of the neuron that submitted the proposal. When a proposal is submitted, a “charge” is placed on its balance in case it is rejected. So the balance needs to be big enough to pay the charge on (all) rejection(s). We require a neuron to have a dissolve delay ≥ 6 months to vote, and this applies to submitting proposals too.
- Proposal Type: The type of the proposal. This infers what topic it belongs to (e.g., #NodeAdmin), the system function that will process the proposal if it is adopted, and the type and structure of the parameters that will be passed to that function.
- Parameters: The parameters that will be passed to the system function that will be invoked if the proposal is adopted, as determined by its type. When a proposal is submitted, the NNS checks the parameters.
The topic of a proposal, which is inferred from its type, determines how it will be processed. For example, the NNS may require voters to have a greater degree of agreement, or to try to process proposals faster, for some topics. Also, neurons follow other neurons on a per-topic basis. Some of the initial topics available in the NNS include:
- #NeuronManagement: A special topic by means of which a neuron can be managed by the followees for this topic (in this case, there is no fallback to default). Votes on this topic are not included in the voting history of the neuron. For proposals on this topic, only followees on this topic, of the neuron that the proposals pertains to, are allowed to vote. Because the set of eligible voters of proposals on this topic is restricted, proposals on this topic have a shorter than normal voting period.
- #ExchangeRate: All proposals provide information in “real time” about the market value of ICP, as measured by an International Monetary Fund (IMF) Special Drawing Right (SDR) , which allows the NNS to convert ICP to cycles (which power computation) at a rate that keeps their real-world cost constant. Because proposals on this topic are very frequent, they have a shorter voting period, and votes on this topic are not included in the voting history of the neuron.
- #NetworkEconomics: Proposals that administer network economics — for example, determining what rewards should be paid to node operators.
- #Governance: All proposals that administer governance — for example, motions and the configuration of certain parameters.
- #NodeAdmin: All proposals that administer node machines somehow, including but not limited to upgrading or configuring the OS, upgrading or configuring the virtual machine framework, and upgrading or configuring the node replica software.
- #ParticipantManagement: All proposals that administer network participants — for example, granting and revoking DCIDs (data center identities) or NOIDs (node operator identities).
- #SubnetManagement: All proposals that administer network subnets — for example, creating new subnets, adding and removing subnet nodes, and splitting subnets.
- #NetworkCanisterManagement: Installing and upgrading “system” canisters that belong to the network — for example, upgrading the NNS.
- #KYC: Proposals that update KYC information for regulatory purposes — for example, during the initial Genesis distribution of ICP in the form of neurons.
- #NodeProviderRewards: Topic for proposals to reward node providers.
Canister Smart Contracts
The above interface shows where users can create canisters that are pre-charged with cycles, the computational units used on the Internet Computer, as well as send cycles to existing canisters. Cycles are created by converting ICP tokens.
Software canisters, an evolution of smart contracts, are computational units that include both program and state. A canister is similar to a container in that both are deployed as a software unit that contains compiled code and dependencies for an application or service.
Cycles are the computational resource to execute actions on the Internet Computer. In general, all canisters consume resources in the form of CPU cycles for execution, bandwidth for routing messages, and memory for persisted data. Canisters maintain an account balance to pay for the cost of communication, computation, and the storage consumed by their applications. The cost of computation is expressed in units of cycles.
Using the NNS dapp, users can create a new canister or attach an existing canister and load it with cycles. The controller of the new canister will be your principal ID. The dapp also allows you to change the controller, e.g., to the principal ID that you had created with the developer command line tool dfx so that you can upload code into your canister.
Sending Cycles to a Canister
Cycles are a means of payment for the real costs of operations, including resources such physical hardware, rack space, energy, storage devices, and bandwidth. In simple terms, a cycle unit represents the cost of executing a single WebAssembly instruction. Other resources cost different amounts of cycles.
Cycles can be compared to “gas” for Ethereum and “credits” for AWS, but have wider uses with regard to data, computation, and execution. Their design also inherently accounts for technological pitfalls, such as rapidly rising costs of usage.
Cycles are obtained by converting ICP into cycles. The cost of cycles is fixed at 1 trillion cycles, or 1T for short, per SDR. sSDR (Special Drawing Right) is an international reserve asset created by the International Monetary Fund (IMF). The current market rate of ICP/SDR is fed into the NNS by means of #ExchangeRate proposals. For example, if the current exchange rate between ICP and SDR is 1 to 420, then converting 0.1 ICP into cycles yields 42T cycles.
Join our developer community and start building at forum.dfinity.org.