Skip to content

Commit

Permalink
Merge branch 'master' into dev-journey-patch
Browse files Browse the repository at this point in the history
  • Loading branch information
jessiemongeon1 authored Nov 1, 2023
2 parents 8b7f787 + 41daca6 commit 1a4d58a
Show file tree
Hide file tree
Showing 20 changed files with 113 additions and 106 deletions.
12 changes: 8 additions & 4 deletions blog/news-and-updates/team-spotlight-node.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,15 @@ image: /img/blog/dev-update-blog-node.jpg

![Node Team spotlight](../../static/img/blog/dev-update-blog-node.jpg)

Hello everyone! It's time for another issue of team spotlight. For this edition, we interviewed the Node team to learn more about the core technology of the Internet Computer. The node team is an extremely vital component of the Internet Computer, since they are responsible for the very foundation of the IC: nodes. I hope you're as excited as we are to learn more!
Hello everyone! It's time for another issue of team spotlight.
For this edition, we interviewed the Node team to learn more about the core technology of the Internet Computer.
The Node team is an extremely vital contributor to the Internet Computer, since they are responsible for the very foundation of the IC: nodes. I hope you're as excited as we are to learn more!

**To kick things off, let's start with our usual introduction. What is the mission of the Node team?**

*Our mission is to enable the Internet Computer protocol to run on distributed, private infrastructure, all over the world. We define the hardware standards for the hundreds of nodes that make up the Internet Computer network. We build and maintain the software used in the decentralized onboarding process, enabling node providers from all over the world to onboard nodes after gaining approval via the NNS DAO. We build and maintain the software running environment for the many IC services that run on node machines. We oversee the node lifecycle, from onboarding to self-upgrading to security.*
*Our mission is to enable the Internet Computer protocol to run on distributed, private infrastructure, all over the world.
We define the hardware standards for the hundreds of nodes that make up the Internet Computer network.
We build and maintain the software used in the decentralized onboarding process, enabling node providers from all over the world to onboard nodes after gaining approval via the NNS DAO. We build and maintain the software running environment for the many IC services that run on node machines. We oversee the node lifecycle, from onboarding to self-upgrading to security.*

**It sounds like the Node team has an enormous amount of responsibilities, essentially being the foundation of the IC. What is the composition of the Node team?**

Expand Down Expand Up @@ -51,7 +55,7 @@ Hello everyone! It's time for another issue of team spotlight. For this edition,

*GuestOS and HostOS are both self-upgrading. Each OS has a mechanism to write to a passive partition set and reboot into its passive partition set, thereby upgrading itself (and making the passive partition set its active partition set). “Replica upgrades” are really GuestOS upgrades, as not only the replica is upgraded, but also the entire GuestOS and GuestOS binaries (including the replica).*

*Since launch, we have completed over 100 GuestOS upgrades, and we are planning to release our first ever HostOS upgrade very soon.*
*Since launch, over 100 GuestOS upgrades we completed, and we are planning to submit a proposal for the first ever HostOS upgrade very soon.*

*To learn more about the upgrade procedure, see here: https://github.com/dfinity/ic/blob/master/ic-os/docs/Upgrades.adoc*

Expand All @@ -67,7 +71,7 @@ Hello everyone! It's time for another issue of team spotlight. For this edition,

**Have there been any improvements made as a direct result of node provider feedback?**

*Absolutely. The Node team is constantly receiving feedback from node providers about the onboarding procedure, and we use this feedback to improve our processes and documentation. All node providers are encouraged to join the Node Provider matrix channel to share any feedback or suggestions with DFINITY and the community: https://wiki.internetcomputer.org/wiki/Node_Provider_Matrix_channel*
*Absolutely. The Node team is constantly receiving feedback from node providers about the onboarding procedure, and we use this feedback to improve our processes and documentation. All Node Providers are encouraged to join the Node Provider matrix channel to share any feedback or suggestions with DFINITY and the community: https://wiki.internetcomputer.org/wiki/Node_Provider_Matrix_channel*

**That's incredible to hear that node providers frequently help provide meaningful feedback.**

Expand Down
6 changes: 3 additions & 3 deletions docs/concepts/nodes-subnets.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@

## Overview

Internet Computer **subnet blockchains** provide physical hardware and resources, like CPU and memory, for performing software operations. Each subnet is a blockchain that consists of some number of decentralized, independently owned and controlled machines, connected peer computers called **nodes**, that run the software components of the Internet Computer blockchain protocol.
Internet Computer **subnet blockchains** are formed by q some number of independently owned and controlled high-performance hardware devices called **node machines**, that run the Internet Computer Protocol (ICP).

The Internet Computer blockchain software components that run on each node are called a **replica** because they replicate state and computation across all of the nodes in a subnet blockchain.
The Internet Computer Protocol is implemented by a number of software components that as a bundle are a **replica** because they replicate state and computation across all of the nodes in a subnet blockchain.

## Replica architecture

Expand All @@ -28,7 +28,7 @@ As a developer, it isn’t necessary to know the details about how your dapps an

## Subnet blockchains

A so-called **subnet** is a collection of replicas that run a separate instance of the consensus mechanism in order to create their own blockchain on which a set of canisters can run. Each subnet can communicate with other subnets and is controlled by the **root subnet**, which uses [chain key](/references/glossary.md#chain-key) cryptography to delegate its authority to the various subnets.
A so-called **subnet** is a collection of interacting replicas that run a separate instance of the consensus mechanism in order to create their own blockchain on which a set of canisters can run. Each subnet can communicate with other subnets and is controlled by the **root subnet**, which uses [chain key](/references/glossary.md#chain-key) cryptography to delegate its authority to the various subnets.

The Internet Computer uses subnets to allow it to scale indefinitely. The problem with traditional blockchains (and individual subnets) is that they are limited by the computing power of a single node machine, because every node has to run everything that happens on the blockchain to participate in the [consensus](/references/glossary.md#consensus) algorithm. Running multiple independent subnets in parallel allows the Internet Computer to break through this single-machine barrier.

Expand Down
11 changes: 6 additions & 5 deletions docs/concepts/tokens-cycles.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,20 @@
# Tokens and cycles

## Overview
Within the Internet Computer ecosystem, Internet Computer Protocol tokens (ICP tokens) are a native utility token with a value determined on the open market. ICP tokens play a key role in both the governance and the economics of the Internet Computer.
Internet Computer Protocol tokens (ICP tokens) are a native utility token with a value determined on the open market. ICP tokens play a key role in both the governance and the economics of the Internet Computer.

## How to get ICP tokens

There are a few different ways you might acquire ICP tokens. For example, you might:

- Purchase ICP tokens directly through an exchange that lists ICP tokens available for trade.

- Receive tokens as rewards for participating in the governance of the Internet Computer
- Create tokens from rewards (maturity) obtained for participating in the governance of the Internet Computer.

- Receive a grant of tokens through the Internet Computer Association (ICA) or the DFINITY Foundation.
- Receive tokens from the protocol as remuneration for being a node provider and operating a Internet Computer node.

- Receive a grant of tokens by the DFINITY Foundation.

- Receive tokens as remuneration for providing computing capacity as a node provider.

## How to use ICP tokens

Expand Down Expand Up @@ -55,7 +56,7 @@ Tokens (ICP) reflect the value of the Internet Computer blockchain and can fluct

Tokens can be exchanged between token holders or locked up in **neurons** to secure voting rights as part of the governance system.

Tokens are used to reward node providers for providing compute capacity and neuron holders for participating in the governance of the Internet Computer by voting and submitting proposals.
Tokens are used to reward node providers for operating nodes (and thereby providing compute capacity) and indirectly to reward neuron holders for participating in the governance of the Internet Computer by voting and submitting proposals.

## Payment to node providers

Expand Down
4 changes: 2 additions & 2 deletions docs/developer-docs/integrations/t-ecdsa/index.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
# Threshold ECDSA: chain-key signatures

## Overview
The Internet Computer implements a novel threshold ECDSA protocol as part of its chain-key signatures toolbox. In this protocol, the private ECDSA key is held in a secret-shared manner by multiple parties, namely the replicas of a threshold-ECDSA-enabled subnet on the IC, and signatures are computed using those secret shares without the private key ever being reconstructed. Each replica of such subnet holds a key share that provides no information about the key on its own. At least one third of the replicas are required to generate a threshold signature using their respective key shares. Besides the actual threshold signing protocol, chain-key ECDSA also comprises protocols for secure key distributed key generation and periodic key resharing, which are crucial parts of the protocol. This makes chain-key ECDSA signatures much more powerful than any off-the-shelf threshold ECDSA protocol.
The Internet Computer implements a novel threshold ECDSA protocol as part of its chain-key signatures toolbox. In this protocol, the private ECDSA key exists only as secret shares held by designated parties, namely the replicas of a threshold-ECDSA-enabled subnet on the IC, and signatures are computed using those secret shares without the private key ever being reconstructed. Each replica of such subnet holds a key share that provides no information on its own (in fact, any set of shares up to a threshold of one third cannot be distinguished from a set of random strings). At least one third of the replicas are required to generate a threshold signature using their respective key shares. Besides the actual threshold signing protocol, chain-key ECDSA also comprises protocols for secure key distributed key generation and periodic key resharing, which are crucial parts of the protocol. This makes chain-key ECDSA signatures much more powerful than any off-the-shelf threshold ECDSA protocol.

Each canister on any subnet of the Internet Computer has control over a unique ECDSA key pair and can request signatures with the corresponding private key to be computed. A signature is only issued to the eligible canister, i.e., the legitimate holder of the ECDSA key. Each canister can obtain signatures only for its ECDSA keys. Note that canisters do not hold any private ECDSA keys or key shares themselves, but delegate this to specific threshold-ECDSA-enabled subnets of the IC. Threshold cryptography can help enable functionality in the trust model of a blockchain that would be impossible to achieve with conventional cryptography alone.
Each canister on any subnet of the Internet Computer has control over a unique ECDSA public key and can request signatures for this public key to be computed. A signature is only issued to the eligible canister, i.e., the legitimate holder of this ECDSA key. Each canister can obtain signatures only for its own ECDSA keys. Note that canisters do not hold any private ECDSA keys or key shares themselves. Threshold cryptography can help enable functionality in the trust model of a blockchain that would be impossible to achieve with conventional cryptography alone.

A threshold ECDSA implementation on a blockchain can be viewed as the on-chain counterpart to a hardware security module (HSM) that stores private keys securely and issues signatures on request of the eligible entities, and only to those.

Expand Down
2 changes: 1 addition & 1 deletion docs/developer-docs/integrations/vetkeys/using-vetkeys.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Overview

This demo provides a canister (`src/system_api`) that offers the vetKD system API proposed in https://github.com/dfinity/interface-spec/pull/158, implemented in an unsafe manner for demonstration purposes.
This demo provides a canister (`src/system_api`) that offers the vetKD system API proposed in https://github.com/dfinity/interface-spec/pull/158, implemented demonstration, testing, and initial devlopment purposes. We stress that it does not offer security yet as no threshold cryptography is used yet to secure the key.

This demo uses files found in [this repository](https://github.com/dfinity/examples/tree/master/rust/vetkd).

Expand Down
10 changes: 5 additions & 5 deletions docs/developer-docs/production/custom-domain/custom-domain.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,15 +3,15 @@
## Overview

By default all canisters on the Internet Computer are accessible through `icp0.io`
and their canister ID. In addition to that default domain, one can also host a
canister under a custom domain. This guide explains how to do that.
and their canister ID. In addition to that default domain, one can also make a
canister accessible under a custom domain. This guide explains how to do that.

There are, essentially, two approaches to host a canister under a custom domain:
There are, essentially, two approaches to make a canister accessible under a custom domain:

- [Register the domain with the boundary nodes](#custom-domains-on-the-boundary-nodes).
- [Hosting the domain on your own infrastructure](#custom-domains-using-your-own-infrastructure).

For both approaches, you need to acquire a domain through your favorite registrar.
For both approaches, you need to acquire a domain through any registrar (pick your favorite one).

The two approaches differ in the ease of use and the configurability. When registering
the domain with the boundary nodes, you simply have to configure the DNS records of
Expand Down Expand Up @@ -248,5 +248,5 @@ request for your domain and the boundary node will return the corresponding ID.
- #### Step 6: Test.

:::caution
For websites that use Internet Identity (II) to authenticate users: The principals provided by II depend on the domain from which the login request was started. So if you authenticate your users through the canister URL and want to switch over to a custom domain, users will not have the same principals anymore. You can prevent this by setting up [Alternative Origins](../../integrations/internet-identity/alternative-origins.md).
For front-ends that use Internet Identity (II) to authenticate users: the principals provided by II depend on the domain from which the login request was started. So if you authenticate your users through the canister URL and want to switch over to a custom domain, users will not have the same principals anymore. You can prevent this by setting up [Alternative Origins](../../integrations/internet-identity/alternative-origins.md).
:::
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Overview

Once deployed to the Internet Computer, developers need to pay in cycles for the compute and storage utilized by their canisters. The process of burning cycles and transferring them to a canister is referred to as "topping-up" a canister.
Once a canister is deployed to the Internet Computer, the compute and storage it utilizes must be pre-payed. The process of burning ICP to obtain cycles and transferring them to a canister is referred to as "topping-up" a canister.

Cycles management services provide canister monitoring and automated cycles top-ups to ensure canisters applications remain up and running and do not run out of cycles.

Expand Down
6 changes: 5 additions & 1 deletion docs/developer-docs/setup/install/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,11 @@ You can download and install the latest version of the [IC SDK](https://github.c

The **IC SDK** is natively supported on Linux or macOS 12.\* Monterey or later.

There is no native support for <code>dfx</code> on Windows. However, by installing the Windows Subsystem for Linux (WSL), you can run dfx also on a Windows system as described below.
There is no native support for <code>dfx</code> on Windows. However, by installing the Windows Subsystem for Linux (WSL 2), you can run dfx on a Windows system as described below.

:::caution
Not all features of dfx may be supported on WSL 2.
:::

<Tabs>
<TabItem value="apple" label="Install on Mac/Linux" default>
Expand Down
2 changes: 1 addition & 1 deletion docs/tokenomics/nns/neurons-fund.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ The Neurons' Fund (NF) facilitates bootstrapping the Internet Computer (IC) ecos

## Background and motivation

The success of the IC is dependent on the services built on the IC. Similar to Ethereum, we envisage that, in the long run, the value of services built on the IC will collectively be worth more than the IC itself.
The success of the IC is dependent on the dapps built on the IC. Similar to Ethereum, we envisage that, in the long run, the value of services built on the IC will collectively be worth more than the IC itself.
The NF introduces the concept of an NNS controlled treasury. This treasury aims to assist in the bootstrapping of the SNS DAO ecosystem. The NNS will decide how the treasury resources are allocated. The NNS treasury can be extended in the future to support additional community-developed governance and fundraising frameworks.

To build this treasury, NNS neurons flagged as NF, will expose their maturity to the risks the NF fund is taking when participating in SNSes. Maturity of NF neurons will be reduced when the NF decides to participate. At a later date NF neurons whose maturity was reduced will be rewarded with maturity increases, dependent on the success of the NF's participation.
Expand Down
14 changes: 6 additions & 8 deletions docs/tokenomics/nns/nns-staking-voting-rewards.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,13 +3,13 @@
## Overview
Stakeholders gain voting power and can earn voting rewards by staking their ICP tokens.

The Internet Computer is a decentralized platform whose evolution is decided by its stakeholders through voting. This means decision impacting the future of the Internet Computer are made by people vested in the outcome. In return for participation in governance, the Internet Computer gives out voting rewards. Voters can vote actively, or they can use the liquid democracy on the Internet Computer to automatically follow other voters.
The Internet Computer is a decentralized computer whose evolution is decided by its stakeholders through voting. This means decision impacting the future of the Internet Computer are made by people vested in the outcome. In return for participation in governance, the Internet Computer Procotol provides voting rewards. Voters can vote actively, or they can use a form liquid democracy to automatically follow other voters.

## Key concepts

### Neurons

In order to become vested and obtain voting power, ICP tokens must first
To become vested and obtain voting power, ICP tokens must first
be staked, and then locked up for a length of time greater than 6
months to, at most, 8 years.

Expand Down Expand Up @@ -45,16 +45,14 @@ voting power for the stake committed.

### Maturity

Maturity represents the voting rewards accumulated in a neuron. Each day
Maturity of a neuron increases as it collects voting rewards. Each day
the network rewards participants by allocating to every voting neuron a
portion of the total reward, based both on its voting power at the time
proposals were made, and the number of proposals it voted on.

Please note that different tax authorities may take different views on the taxation status of the voting rewards. Neuron owners who receive voting rewards and convert them to ICP should consult appropriate professionals.

For those who wish to compound the voting power in their neuron, the most
natural activity is to "stake maturity" on a regular basis. If you wish to liquidate rewards you earn from the
neuron and convert them to ICP, you can "spawn" maturity into a reward neuron.
For those who wish to compound gained maturity in their neuron, the most
natural activity is to "stake maturity" on a regular basis.
If you wish to liquidate maturity gained, you can use it to produce liquid ICP.

## Why staking matters

Expand Down
Loading

0 comments on commit 1a4d58a

Please sign in to comment.