Canister, as an important concept in Dfinity, is usually understood as a smart contract. But at the same time, it is mainly to bring parallel computing to the blockchain and solve the problem of scalability, and introduce the concept of Actor .
In addition, in order to realize Canister’s memory management and interoperability, Canister is used as a process in the IC system to perform operations such as updating and removing. Finally, in order to break the bottleneck of virtual machines in the blockchain, WebAssembly is introduced to support efficient compilation of multiple languages.
It can be said that Canister in Dfinity inherits, absorbs and optimizes the elements of the above four concepts, and achieves the scalability and interoperability requirements of its commitment to large-scale network services .
This article will comprehensively explain the concept of Canister in Dfinity by comparing the similarities and differences between these four understandings and Canister.
Dfinity-Internet Computer is a blockchain network composed of independent data center nodes running Decentralized Protocol (ICP) .
Different applications and programs can communicate and call each other’s API interface, thus creating a seamless software ecology.
Canister Chinese means container and jar. It is composed of code and data. The implementation of various functions and components in the Dfinity application must be completed by Canister, the computing unit in Dfinity.
Dfinity defines Canister as follows: It is a smart contract on Dfinity, deployed in the data center of a network computer (IC), and is a scalable and interoperable computing unit designed for large-scale network services .
People with different technical backgrounds have their own understanding of Canisters:
- Ethereum developers: this is smart contract
- Computer Science: Canister is similar to Actor in Actor Model
- System Engineer: It’s like the process in the operating system (Process)
- Virtual machine expert: reminds me of WebAssembly modules
There is nothing wrong with these understandings, and they are relatively incomplete. But if you put them together, you can put together the complete concept of Canister in Dfinity.
Canister is very much like a smart contract, and the contract must be executed under the control of Dfinity’s Security Protocol (ICP) . Note that ICP here does not refer to the governance token of ICP, but the abbreviation of Internet Computer Protocol, which is the blockchain protocol of Dfinity. Just like the smart contract in Ethereum, the change of Canister’s state must and can only be triggered by a consensus message in the blockchain. Therefore, Canister is tamper-proof.
In addition, because the execution mechanism of the Canister code is deterministic , by checking the messages on the chain, the status of Canister can be reviewed in a secure and encrypted manner.
Canister not only has all the features of traditional smart contracts, but more importantly, it can provide better scalability for software services. This brings out another concept behind Canister: Actor.
Dfinity introduced the concept of Actor to introduce parallel computing to the blockchain and solve the scalability problem.
If we take a step back and look at Canister from a more abstract perspective, it is similar to the Actor (the person who initiates and implements an action) in the Actor Model. Just like the idea of ”everything is an object” in object-oriented languages. In the Actor model, everything is an Actor. Here is a brief explanation, Actor Model is a mathematical model in the field of parallel computing , and Actor is an indivisible computing unit in the model.
A very important difference between Canister and traditional Actors can be two-way information transfer. The message is divided into a request and a response. After the request is answered, the IC will track the callback of the response. When an actor receives a message, it can respond in several ways:
- Make local decisions
- Create more actors
- Send messages to other actors (to change the state of other actors)
- Decide how to respond to the next received message
Note: None of the above operations have an assumed sequence, and they can be executed in parallel.
Canister’s response to the message is roughly the same. In addition, Canister also inherits some characteristics of Actor:
- Canister’s private status can only be changed by the Canister himself
- The execution of each Canister is single-threaded, so lock-based synchronization is not required
- Can communicate with other Canisters through asynchronous messages
In the Actor model, the recipient of a message is identified by an address (sometimes called a mailing address). Therefore, Actors can only communicate with other Actors when they know the address of the other party.
For example, email can be modeled as an Actor system. The user’s account is modeled as an Actor, and the email address is modeled as an Actor address. Canister also has a mailing address similar to an IPv6 address.
A single Canister has only one execution thread when updating the state, but the IC can execute a large number of Canisters in parallel at the same time. This is how IC overcomes the performance limitations of some early platforms for smart contracts.
In addition, IC divides requests into two categories: one is a request that needs to update the Canister status, and the other is a query that cannot change the Canister status.
In this way, although the throughput of a single Canister update request is limited by single thread and blockchain performance, the query request can reach thousands of throughput per second and millisecond latency. In other words, the update is a message (request) that needs to be on the chain, and the query message does not need to go through the blockchain.
In order for browsers and mobile apps to be able to update and query directly in Canister, end users must also participate in the model as an Actor.
To add, Dfinity’s unique Motoko language was inspired by the Actor model.
Canister is the cornerstone of Internet computers and the atoms that make up network services-large-scale Internet services need to be completed by the cooperation of many Canisters.
The interpretation of the process and WebAssembly will be placed in the second half of the article:
How does ICP manage its processes as an operating system-Canister?
How does Canister actually perform on IC?