Dfinity系列解读之:四个角度全面解读Canister(上)

IPFS原力区 view 66433 2021-4-30 11:30
share to
Scan QR code with WeChat

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

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

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

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

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

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

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

Dfinity系列解读之:四个角度全面解读Canister(上)

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进行通信。

Dfinity系列解读之:四个角度全面解读Canister(上)

例如,电子邮件可以被建模为一个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

btcfans公众号

Scan QR code with WeChat

Disclaimer:

Previous: 万事达卡将探索基于CBDC的应用程序 Next: 万物皆可挖矿?40年前的老爷机电脑破解挖矿

Related