1. 原力区首页
  2. Web 3.0

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

Canister,岂止于智能合约

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如此定义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上又是如何执行?

引用参考:

end

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

声明:本文系原力区原创稿件,版权属原力区所有,未经授权不得转载,违者将依法追究责任。

提示:投资有风险,入市须谨慎。本文不作为投资理财的建议。

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

原创文章,作者:Mabrary,如若转载,请注明出处:https://ipfser.org/2021/04/29/canisterjiedu/

提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。

发表评论

登录后才能评论

联系我们

在线咨询:点击这里给我发消息

邮件:ipfsforce@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code