Dfinity系列解读之：四个角度全面解读Canister（上）

Canister作为Dfinity中的一个重要概念，通常被理解为 智能合约。 但同时主要是为了将并行计算带入到区块链，解决可扩展性的难题，引入了 Actor 的概念。

此外，为了实现Canister的内存管理和互操作性，将Canister作为IC系统中的 进程 进行更新、移除等操作。最后，为了打破区块链中虚拟机的瓶颈，引入 WebAssembly 来支持多种语言的高效编译。

可以说Dfinity中的Canister是继承、吸纳并优化了以上这四个概念中的元素，达到了它致力于大规模网络服务的 可扩展、可互操作的需求。

本文将会通过比较这四种理解与Canister的异同，来全面阐释Dfinity中Canister的概念。

网络计算机（Dfinity——Internet Computer）是由运行着去中心化协议（ICP）的各个独立的数据中心节点组成的 区块链网络。

不同的应用和程序之间能够进行通信，调用对方的API接口，由此打造了一个无缝的软件生态。

Canister中文是容器、罐子。它由代码和数据组成，Dfinity应用中的各个功能、组件的实现都要通过Canister——这个Dfinity中的 计算单元 来完成。

Dfinity如此定义Canister：它作为Dfinity上的智能合约，被部署在网络计算机（IC）的数据中心上，是为大规模网络服务设计的，可扩展、可互操作的 计算单元。

不同技术背景的人对Canisters都有自己的理解：

• 以太坊开发人员：这就是智能合约
• 计算机科学：Canister类似于Actor Model中的Actor
• 系统工程师：它就像操作系统中的进程（Process）
• 虚拟机专家：让我想到了WebAssembly modules

这些理解都没有错，相对不那么完整。但如果把它们凑到一起，就可拼出了Dfinity中Canister的完整概念。

智能合约

Canister非常像一个智能合约，合约都要在Dfinity的 安全协议（ICP） 管控下执行。注意，这里ICP不是指ICP的治理代币，而是Internet Computer Protocol的缩写，也就是Dfinity的区块链协议。就像以太坊中的智能合约一样，Canister状态的改变必须也只能通过区块链中达成 共识 的消息触发。因此，Canister是 防篡改的。

另外，由于Canister代码的执行机制是 确定性的 （Deterministic），通过检查链上的消息，可以以一种安全加密的方式对Canister的状态进行审查。

Canister不仅拥有传统智能合约的全部功能特性，更重要的是它能为软件服务提供更好的可扩展性。这就带出了Canister背后的另一个概念：Actor。

Actor

Dfinity引入Actor的概念主要是为了将并行计算引入区块链，解决 可扩展性 的难题。

如果我们退一步，从一个更抽象的角度去看Canister，它就类似Actor Model中的 Actor （某个行动的发起、实施的人）。就像面向对象的语言中“一切皆是对象”的理念一样。在Actor模型中，一切都是Actor。这里简单解释一下，Actor Model是 并行计算 领域一个数学模型，而Actor就是模型中不可再分的 计算单元。

Canister和传统Actor很重要的一点不同可以进行 双向信息传递。 消息分为请求和响应，在请求得到应答后，IC会跟踪响应的回调。当Actor接收到一条消息，它可以做出这样几种响应：

• 做出本地决策
• 创建更多的Actor
• 给其它Actor发送消息（来改变其它actor的状态）
• 决定如何响应下一条收到的消息

注：上述操作均没有一个假定的顺序，它们可以并行执行。

Canister对消息的响应也大致如此。另外，Canister也继承了Actor的一些特性：

• Canister的私有状态只能由该Canister自己更改
• 每个Canister的执行都是单线程的，因此不需要基于锁的同步性
• 可以通过异步消息与其他Canister通信

在Actor模型中，一条消息的接收者是由 地址 （有时也被称为邮寄地址）识别的。因此，Actor只能在知道对方地址的情况下和其它Actor进行通信。

例如，电子邮件可以被建模为一个Actor系统。用户的帐户被建模为Actor，电子邮件地址被建模为Actor地址。而Canister也有一个类似于 IPv6地址 的邮寄地址。

单个Canister在更新状态时只拥有一个执行线程，但IC可以同时并行执行大量的Canister。这就是IC如何克服智能合约的一些早期平台的性能限制。

此外，IC还将请求分为两类：一类是需要 更新 Canister状态的请求，另一类是 查询 ，不能改变Canister状态。

这样一来，虽然单个Canister更新请求的吞吐量受到单线程和区块链性能的限制，但查询请求却可以达到每秒上千的吞吐量和毫秒级延迟。也就是说， 更新是需要上链的消息（请求），而查询的消息是不需要经过区块链的。

为了让浏览器和移动端App能够直接在Canister进行更新和查询，终端用户也必须作为一个Actor参与到模型中来。

补充一点，Dfinity特有的 Motoko 语言正是受到了Actor模型的启发设计出来的。

小结

Canister是互联网计算机的基石，也是组成网络服务的原子——大规模的互联网服务需要由众多Canister互相协作完成。

关于进程和WebAssembly的解读会放在文章的下半篇：

ICP是如何作为一个操作系统如何管理其中的进程-Canister的？

Canister实际在IC上又是如何执行？

引用参考：

• https://www.youtube.com/watch?v=LKpGuBOXxtQ&t=4s
• https://en.wikipedia.org/wiki/Actor_model
• https://webassembly.github.io/spec/core/intro/overview.html