This article introduces a number of terms that must be understood to program on IC, including Node, Replica, WebAssembly, Canister, Actor, Ledger, Wallet, Principal, and Controller.
This article should be the best article to introduce these terms.
Node is the physical or virtual machine node that hosts the IC, which is well understood and needs no introduction.
In IC, a replica is an IC protocol process running on a node.
WebAssembly ( Wasm) is a binary instruction format that provides a virtual machine level abstract runtime environment that is secure, portable, efficient, lightweight, and can easily achieve millisecond cold start times and extremely low resource consumption.
WebAssembly was first applied to the browser, but now it is gradually developed to the back-end, which can compile C/C++, Rust, Motoko and other language code into WebAssembly bytecode and run in the sandbox environment.
Currently, all mainstream public chains are supporting WebAssembly, and IC is a typical public chain supporting WebAssembly, which can write DApps by Motoko or Rust and then deploy them in IC.
In addition to IC, there are also public chains such as Dot and Near that support WebAssembly.
Canister can be thought of as a special kind of container, analogous to a Container in Kubernetes.
Canister has WebAssembly code running in it, which is called a smart contract.
Canister has the following features.
- Canister is based on the Actor programming model, currently each Canister contains only one Actor (other programming models in the industry include Golang’s CSP model, Java and Python’s multi-process model)
- Canister is based on the Actor programming model, which allows you to write general-purpose DApps on IC (only financial applications can be written on ethereum)
- Canister has a globally unique ID
- Canister encapsulates all programming logic, public entry methods, interface descriptions of the provided message types, and state information of the DApps it describes
Actor is a very early concept in programming languages, for example in Erlang.
Actor is a special object, the data in each Actor is isolated from other Actors, and the data inside the Actor can only be changed by passing messages (functions) between Actors.
Moreover, message processing between Actors is asynchronous, with a built-in Future mechanism, so if you want to wait for the return result, use await.
An Actor can only process one message at a time, and it is executed sequentially, without locking problems.
Currently an Actor is a Canister.
On IC, you can use IC’s own Motoko programming language for Actor programming, or you can use Rust.
IC records all transactions involving ICP tokens in a dedicated management container smart contract called the ledger container, Ledger Canister.
Ledger Canister implements a smart contract that maintains accounts and balances, and keeps a history of transactions affecting them.
It provides the following capabilities.
- Mint ICP tokens for an account
- Transfer ICP tokens from one account to another
- Burn ICP tokens to eliminate their existence
Ledger Canister to be attributed to an identity.
Wallet is a dedicated smart contract (Canister) that allows storing and managing Cycles.
The Cycle is used to pay for the computation and resource consumption of the IC.
Cycles can be obtained through ICP conversion.
Wallet is to be attributed to an identity.
Principal is essentially an identifier that can be used to identify identities and Canister (and possibly others in the future).
For example, you can use the Principal ID to identify an identity. When you first use the Dfinity Canister SDK, the dfx command line tool creates the default developer identity (and a pair of public-private keys) for you, and the default developer identity is identified by the Principal ID.
Note that the developer identity can also be used to derive an Account ID (similar to an ethereum address) to represent the “identity” of the ICP tokens stored in Ledger Canister.
Similarly, a Canister ID is also a Principal.
So when speaking of a Principal, it may represent both an identity or a Canister, such as a Wallet Canister.
A Controller is a Principal with the authority to install, upgrade, and delete Canisters.
In general, a Canister’s Controller can be specified as a certain identity, or a Wallet Canister corresponding to a certain identity.
After dfx 0.9, the default “identity” is now the Controller of Canister, and Wallet Canister is no longer the default Controller (equivalent to dfx specifying –no-wallet).