Skip to content

Commit

Permalink
Merge pull request #2232 from dfinity/jmongeon-updates
Browse files Browse the repository at this point in the history
Refinement: IC -> ICP cleanup & clarification
  • Loading branch information
jessiemongeon1 authored Dec 4, 2023
2 parents 051bae1 + 2b7dbf4 commit 2b36cc3
Show file tree
Hide file tree
Showing 31 changed files with 67 additions and 68 deletions.
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -172,7 +172,7 @@ it does not always exist.

> More information about document creation on [Docusaurus's docs](https://docusaurus.io/docs/create-doc).
### Deployed Previews
### Deployed previews

Whenever a Pull Request is created on the repository, a CI job will appear and deploy a Preview on Netlify so that
reviewers can easily check the changes made the way the end users will.
Expand All @@ -191,9 +191,9 @@ Here is a description of how a contribution should be made to the developer port
1. The contributor creates a fork/branch where the changes are made.
2. A pull request (PR) is created from this branch to `master`. the preview is generated and the reviewers can directly check
the preview website.
3. After the pull request is merged into master, CI/CD will deploy the contents to the ICP. The changes made will appear
3. After the pull request is merged into master, CI/CD will deploy the contents to ICP. The changes made will appear
on the webpage under the version in the dropdown named "Current".
4. Optional: When a repo maintainer tags a commit on master as $TAG, then CI/CD deploys the contents to the ICP. The
4. Optional: When a repo maintainer tags a commit on master as $TAG, then CI/CD deploys the contents to ICP. The
webpage will default to the new "$TAG" version, visible in the versions dropdown, and allow users to view the
contents pinned at that tag.

Expand Down
2 changes: 1 addition & 1 deletion blog/features/vetkey-primer.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# VETKeys Primer

The **VETKeys** feature is in ongoing development on the Internet Computer (ICP). It stands for ‘**V**erifiable **E**ncrypted **T**hreshold Keys’ and enables a number of cryptographic functionalities on ICP. The primary motivation for VETKeys is to facilitate onchain encryption, as such we focus this primer with that example in mind.
The **VETKeys** feature is in ongoing development on the Internet Computer Protocol (ICP). It stands for ‘**V**erifiable **E**ncrypted **T**hreshold Keys’ and enables a number of cryptographic functionalities on ICP. The primary motivation for VETKeys is to facilitate onchain encryption, as such we focus this primer with that example in mind.

One thing less discussed about the VETKeys feature is how we got here in terms of cryptography. The goal of this post is to lay some crypto background so that you can better understand the VETKeys talks, paper, and future posts. Note that understanding these foundations of VETkeys will *not* be necessary to use them for building applications, but we explain for those who are interested to dive deeper and want to understand the background. Let’s start at the start.

Expand Down
2 changes: 1 addition & 1 deletion blog/news-and-updates/2022-12-19-update.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ post [here](https://forum.dfinity.org/t/generational-gc-on-playground-and-new-as
We are excited to announce a new collaboration which brings
runnable [Motoko code snippets](https://embed.smartcontracts.org/) directly into the [Medium](https://medium.com/)
social publishing platform.
As a part of an ongoing effort to overhaul Motoko’s documentation, we wanted to make it easy for anyone in ICP
As a part of an ongoing effort to overhaul Motoko’s documentation, we wanted to make it easy for anyone in the ICP
community to create interactive tutorials and code examples across the Internet.
You can see the full
post [here](https://forum.dfinity.org/t/embed-motoko-interactive-code-snippets-directly-in-your-medium-story-or-blog-post/17433).
Expand Down
8 changes: 4 additions & 4 deletions blog/news-and-updates/team-spotlight-node.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -21,19 +21,19 @@ We build and maintain the software used in the decentralized onboarding process,

*The team consists of 4 engineers, 2 researchers, and 1 engineering manager, spread across the United States, Canada, Switzerland and Germany!*

**Could you give us a brief overview of what IC-OS is?**
**Could you give us a brief overview of what the IC-OS is?**

*IC-OS is an umbrella term for all [of] the operating systems within ICP, including:*

- *SetupOS (AKA IC-OS installer), which deploys a new replica node (by installing HostOS and GuestOS).*
- *SetupOS (AKA the IC-OS installer), which deploys a new replica node (by installing HostOS and GuestOS).*

- *HostOS, which runs on the bare metal of a replica node machine. HostOS runs GuestOS in a virtual machine.*

- *GuestOS, which runs inside a virtual machine. The replica is executed within the GuestOS.*

- *BoundaryOSes, which includes Boundary-GuestOS, Boundary-Api-GuestOS.*

*Readers should view IC-OS folder in IC repo where our operating systems reside: https://github.com/dfinity/ic/tree/master/ic-os*
*Readers should view the IC-OS folder in the IC repo where our operating systems reside: https://github.com/dfinity/ic/tree/master/ic-os*

*Here is a high-level overview of all the services running on a replica node:*

Expand All @@ -51,7 +51,7 @@ We build and maintain the software used in the decentralized onboarding process,

*Keeping up with dozens of new features that require our assistance while managing our normal workload. There’s always more work to be done!*

**With consistent upgrades and changes to IC-OS software, how does the Node team contribute to the lifecycle of nodes?**
**With consistent upgrades and changes to the IC-OS software, how does the Node team contribute to the lifecycle of nodes?**

*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).*

Expand Down
2 changes: 1 addition & 1 deletion docs/developer-docs/backend/choosing-language.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ To create [canister smart contracts](https://internetcomputer.org/how-it-works/a

Because the Internet Computer blockchain supports dapps compiled to standard WebAssembly modules, one can use many different programming languages to create ICP canister smart contracts. To build a canister with a particular programming language, one needs a [canister development kit (CDK)](../setup/install/index.mdx#sdk-vs-cdk-vs-dfx) for their particular language. A CDK is an adapter used by the IC SDK that provides a programming language with the features necessary to create and manage canisters. To make starting easier, the IC SDK already comes with CDK for multiple languages.

In theory, any language that can be compiled into a WebAssembly module, can produce modules [tailored for the ICP](../../references/ic-interface-spec.md) deployable as an ICP smart contract.
In theory, any language that can be compiled into a WebAssembly module, can produce modules [tailored for deploying on ICP](../../references/ic-interface-spec.md) as an ICP smart contract.

In practice, the amount of CDK and library support for different languages varies across the ICP developer ecosystem, so this article lays out common paths for entering developers.

Expand Down
2 changes: 1 addition & 1 deletion docs/developer-docs/backend/rust/8-optimizing.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ This guide assumes you have an existing canister that you'd like to optimize. To
## Reducing cycle consumption
The first step towards an optimized system is profiling. Start by measuring the number of instructions your endpoints consume.

The `instruction_counter` API will tell you the number of instructions your code has consumed since the last entry point. Instructions are the internal currency of ICP runtime; one ICP instruction is the quantum of work that the protocol can do, such as loading a 32-bit integer from a memory address. The protocol assigns an instruction cost equivalent to each Wasm instruction and system call. It also defines all its limits in terms of instructions. For a detailed breakdown of the current instruction and Wasm limitations on ICP, please review [this page](../../production/resource-limits.md).
The `instruction_counter` API will tell you the number of instructions your code has consumed since the last entry point. Instructions are the internal currency of the runtime; one ICP instruction is the quantum of work that the protocol can do, such as loading a 32-bit integer from a memory address. The protocol assigns an instruction cost equivalent to each Wasm instruction and system call. It also defines all its limits in terms of instructions. For a detailed breakdown of the current instruction and Wasm limitations on ICP, please review [this page](../../production/resource-limits.md).


The following is an example method that can be used to measures the number of instructions:
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Composite queries
## Overview
The Internet Computer (ICP) supports two types of messages: updates and queries. An update message is executed on all nodes and persists canister state changes. A query message discards state changes and typically executes on a single node. It is possible to execute a query message as an update. In such a case, the query still discards the state changes, but the execution happens on all nodes and the result of execution goes through consensus. This “query-as-update” execution mode is also known as replicated query.
The Internet Computer Protocol supports two types of messages: updates and queries. An update message is executed on all nodes and persists canister state changes. A query message discards state changes and typically executes on a single node. It is possible to execute a query message as an update. In such a case, the query still discards the state changes, but the execution happens on all nodes and the result of execution goes through consensus. This “query-as-update” execution mode is also known as replicated query.

An update can call other updates and queries. However a query cannot make any calls, which can hinder development of scalable decentralized applications (dapps), especially those that shard data across multiple canisters.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ The API response looks like this:
5.718, <-- highest price during range
5.714, <-- price at open
5.714, <-- price at close
243.5678 <-- volume of ICP traded
243.5678 <-- volume of traded
],
]
```
Expand All @@ -53,7 +53,7 @@ actor {
//0. method that uses the HTTP outcalls feature and returns a string
public func foo() : async Text {
//1. DECLARE ICP MANAGEMENT CANISTER
//1. DECLARE MANAGEMENT CANISTER
let ic : Types.IC = actor ("aaaaa-aa");
//2. SETUP ARGUMENTS FOR HTTP GET request
Expand Down Expand Up @@ -87,7 +87,7 @@ You will also create some custom types in `Types.mo`. It will look like this:
```motoko
module Types {
//type declarations for HTTP requests, HTTP responses, ICP management canister, etc...
//type declarations for HTTP requests, HTTP responses, management canister, etc...
}
```
Expand Down Expand Up @@ -140,7 +140,7 @@ actor {
public func get_icp_usd_exchange() : async Text {
//1. DECLARE ICP MANAGEMENT CANISTER
//1. DECLARE MANAGEMENT CANISTER
//You need this so you can use it to make the HTTP request
let ic : Types.IC = actor ("aaaaa-aa");
Expand Down Expand Up @@ -178,7 +178,7 @@ actor {
//3. ADD CYCLES TO PAY FOR HTTP REQUEST
//The IC specification spec says, "Cycles to pay for the call must be explicitly transferred with the call"
//ICP management canister will make the HTTP request so it needs cycles
//The management canister will make the HTTP request so it needs cycles
//See: https://internetcomputer.org/docs/current/motoko/main/cycles
//The way Cycles.add() works is that it adds those cycles to the next asynchronous call
Expand Down Expand Up @@ -387,7 +387,7 @@ URLs:
Here is how the management canister is declared in a Rust canister (e.g. `lib.rs`):

```rust
//1. DECLARE ICP MANAGEMENT CANISTER
//1. DECLARE MANAGEMENT CANISTER
use ic_cdk::api::management_canister::http_request::{
http_request, CanisterHttpRequestArgument, HttpHeader, HttpMethod, HttpResponse, TransformArgs,
TransformContext,
Expand Down Expand Up @@ -437,7 +437,7 @@ rustup target add wasm32-unknown-unknown
- #### Step 2: Open the `/src/send_http_get_rust_backend/src/lib.rs` file in a text editor and replace content with:

```rust
//1. IMPORT ICP MANAGEMENT CANISTER
//1. IMPORT MANAGEMENT CANISTER
//This includes all methods and types needed
use ic_cdk::api::management_canister::http_request::{
http_request, CanisterHttpRequestArgument, HttpHeader, HttpMethod, HttpResponse, TransformArgs,
Expand Down Expand Up @@ -694,4 +694,4 @@ You can see play with the dapp's `get_icp_usd_exchange` method on-chain here: [h
## Additional resources

- Sample code of [HTTP GET requests in Rust.](https://github.com/dfinity/examples/tree/master/rust/send_http_get)
- Sample code of [HTTP GET requests in Motoko.](https://github.com/dfinity/examples/tree/master/motoko/send_http_get)
- Sample code of [HTTP GET requests in Motoko.](https://github.com/dfinity/examples/tree/master/motoko/send_http_get)
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ The above figure shows a high-level view of how a canister interacts with the fe

To summarize, to perform an HTTP request, each replica pushes an (optionally-transformed) instance of the received HTTP response from the external web server through the Internet Computer's consensus layer, so that the replicas of the subnet can agree on the response provided to the canister, based on all server responses received by the replicas. The optional transformation ensures that, if responses received on different replicas from the server are different in some parts, those differences are eliminated and the same transformed response is provided to consensus on every (honest) replica. This guarantees that on every replica the exact same response (or none at all) is used for canister execution, thereby ensuring that divergence does not happen when using this feature and the replicated state machine properties of the subnet are preserved.

As you can see, the transformation function and ICP consensus play a crucial role for this feature: The transformation function ensures that differences in the responses received by the replicas are removed and transformed responses on different replicas will be exactly the same, thus enabling consensus to provide the agreed-upon response to the calling canister. By running the responses received by the replicas through consensus, the Internet Computer ensures that every replica provides the same response to the smart contract Wasm execution environment.
As you can see, the transformation function and the Internet Computer Protocol's consensus play a crucial role for this feature: The transformation function ensures that differences in the responses received by the replicas are removed and transformed responses on different replicas will be exactly the same, thus enabling consensus to provide the agreed-upon response to the calling canister. By running the responses received by the replicas through consensus, the Internet Computer ensures that every replica provides the same response to the smart contract Wasm execution environment.

### Trust model and programming Model

Expand All @@ -61,7 +61,7 @@ Overall, the canister HTTP outcalls feature allows us to achieve what oracles or

## Benefits for developers

For developers, the canister HTTP requests feature has the benefit that they do not need to make a decision on which party (oracle) they want to trust in addition to ICP that they already need to trust anyway. They don't need to decide on whether they want to use a single oracle or multiple oracles to reduce trust assumptions and get better decentralization, but rather they get this out of the box with HTTP outcalls.
For developers, the canister HTTP requests feature has the benefit that they do not need to make a decision on which party (oracle) they want to trust in addition to the Internet Computer Protocol that they already need to trust anyway. They don't need to decide on whether they want to use a single oracle or multiple oracles to reduce trust assumptions and get better decentralization, but rather they get this out of the box with HTTP outcalls.

The cost of the HTTP outcall is likely much lower than paying an established oracle provider for their services and the associated ingress cost, thus the Internet Computer has a clear economic advantage to use HTTP calls. Freed from making all those non-trivial trust decisions, a developer can focus on their business logic and simply make the HTTP call they need (and write a corresponding transform function), which is more natural.

Expand Down Expand Up @@ -134,7 +134,7 @@ Both the body and the headers are important to be considered here. Alternatively
- #### Step 4: Determine the maximum response size of the server's response for this type of request to populate the `max_response_bytes` parameter with it.
This often works well for API calls and is important to not overcharge the requesting canister in terms of cycles. The `HEAD` request type can be used to do this if responses change dynamically in response size considerably. If the `max_response_bytes` parameters is not set, the default response size of 2MB is charged, which is extremely expensive.
- #### Step 5: Implement the request and try it out in the local SDK environment.
However, note that the behaviour of the local environment does not reflect that of ICP as there is only one replica in the local environment and $n$, e.g., $n=13$, replicas on an ICP subnet.
However, note that the behaviour of the local replica environment does not reflect that of the mainnet, as there is only one replica in the local environment and $n$, e.g., $n=13$, replicas on an ICP subnet.

:::info
Do not forget to consider response headers when identifying the variable parts of your response because headers sometimes contain variable items such as timestamps which may prevent the responses from passing through consensus.
Expand All @@ -146,7 +146,7 @@ If you do not set the optional `max_response_bytes` parameter, a response size o

### Transformation function

The purpose of the transformation function is to transform each response $r_i$ received by a replica $i$, where the $r_i$ s received by different replicas may be different. The transformation function transforms a response $r_i$ to a transformed response $r'_i$ with the intention that all $r'_i$ s of honest replicas be equal in order to be able to agree on the response as part of ICP consensus. The transformation function must be provided by the canister programmer and is exposed by the canister as a query. An arbitrary number of transformation functions can be defined by a canister. When making an `http_request` call to the management canister, a transformation function can be optionally provided as input.
The purpose of the transformation function is to transform each response $r_i$ received by a replica $i$, where the $r_i$ s received by different replicas may be different. The transformation function transforms a response $r_i$ to a transformed response $r'_i$ with the intention that all $r'_i$ s of honest replicas be equal in order to be able to agree on the response as part of the Internet Computer Protcol's consensus. The transformation function must be provided by the canister programmer and is exposed by the canister as a query. An arbitrary number of transformation functions can be defined by a canister. When making an `http_request` call to the management canister, a transformation function can be optionally provided as input.

Depending on the purpose of the HTTP request being made, there are different approaches to writing the transformation function:
* **Extract only the information item(s) of interest:** this can, e.g., be a list of pairs each comprising a date and an asset price to be forwarded to the canister, or a single asset price. This approach makes sense if the full HTTP response is not required in the canister, but only specific information items are.
Expand Down
Loading

0 comments on commit 2b36cc3

Please sign in to comment.