Dfinity系列解讀之：四個角度全面解讀Canister（上）
Canister作為Dfinity中的一個重要概念，通常被理解為智能合約。為了將并行計算帶入到區(qū)塊鏈，解決可擴(kuò)展性的難題，引入了Actor的概念。
此外，為了實現(xiàn)Canister的內(nèi)存管理和互操作性，將Canister作為IC系統(tǒng)中的進(jìn)程進(jìn)行更新、移除等操作。最后，為了打破區(qū)塊鏈中虛擬機(jī)的瓶頸，引入WebAssembly來支持多種語言的高效編譯。
可以說Dfinity中的Canister是繼承、吸納并優(yōu)化了以上這四個概念中的元素，滿足了它大規(guī)模網(wǎng)絡(luò)服務(wù)的可擴(kuò)展、可互操作的需求。
本文將會通過比較這四種理解與Canister的異同，來全面闡釋Dfinity中Canister的概念。
網(wǎng)絡(luò)計算機(jī)（Dfinity——Internet Computer）是由運(yùn)行著去中心化協(xié)議（ICP）的各個獨(dú)立的數(shù)據(jù)中心節(jié)點(diǎn)組成的區(qū)塊鏈網(wǎng)絡(luò)。
不同的應(yīng)用和程序之間能夠進(jìn)行通信，調(diào)用對方的API接口，由此打造了一個無縫的軟件生態(tài)。
Canister中文是容器、罐子。它由代碼和數(shù)據(jù)組成，Dfinity應(yīng)用中的各個功能、組件的實現(xiàn)都要通過Canister——這個Dfinity中的計算單元來完成。
Dfinity如此定義Canister：它作為Dfinity上的智能合約，被部署在網(wǎng)絡(luò)計算機(jī)（IC）的數(shù)據(jù)中心上，是為大規(guī)模網(wǎng)絡(luò)服務(wù)設(shè)計的，可擴(kuò)展、可互操作的計算單元。
不同技術(shù)背景的人對Canisters都有自己的理解：
以太坊開發(fā)人員：這就是智能合約
計算機(jī)科學(xué)：Canister類似于Actor Model中的Actor
系統(tǒng)工程師：它就像操作系統(tǒng)中的進(jìn)程（Process）
虛擬機(jī)專家：讓我想到了WebAssembly modules
這些理解都沒有錯，相對不那么完整。但如果把它們湊到一起，就可拼出了Dfinity中Canister的完整概念。
智能合約
Canister非常像一個智能合約，合約都要在Dfinity的安全協(xié)議（ICP）管控下執(zhí)行。注意，這里ICP不是指ICP的治理代幣，而是Internet Computer Protocol的縮寫，也就是Dfinity的區(qū)塊鏈協(xié)議。就像以太坊中的智能合約一樣，Canister狀態(tài)的改變必須也只能通過區(qū)塊鏈中達(dá)成共識的消息觸發(fā)。因此，Canister是防篡改的。
另外，由于Canister代碼的執(zhí)行機(jī)制是確定性的（Deterministic），通過檢查鏈上的消息，可以以一種安全加密的方式對Canister的狀態(tài)進(jìn)行審查。
Canister不僅擁有傳統(tǒng)智能合約的全部功能特性，更重要的是它能為軟件服務(wù)提供更好的可擴(kuò)展性。這就帶出了Canister背后的另一個概念：Actor。
Actor
Dfinity引入Actor的概念主要是為了將并行計算引入?yún)^(qū)塊鏈，解決可擴(kuò)展性的難題。
如果我們退一步，從一個更抽象的角度去看Canister，它就類似Actor Model中的Actor（某個行動的發(fā)起、實施的人）。就像面向?qū)ο蟮恼Z言中“一切皆是對象”的理念一樣。在Actor模型中，一切都是Actor。這里簡單解釋一下，Actor Model是并行計算領(lǐng)域一個數(shù)學(xué)模型，而Actor就是模型中不可再分的計算單元。
Canister和傳統(tǒng)Actor很重要的一點(diǎn)不同可以進(jìn)行雙向信息傳遞。消息分為請求和響應(yīng)，在請求得到應(yīng)答后，IC會跟蹤響應(yīng)的回調(diào)。當(dāng)Actor接收到一條消息，它可以做出這樣幾種響應(yīng)：
做出本地決策
創(chuàng)建更多的Actor
給其它Actor發(fā)送消息（來改變其它actor的狀態(tài)）
決定如何響應(yīng)下一條收到的消息
注：上述操作均沒有一個假定的順序，它們可以并行執(zhí)行。
Canister對消息的響應(yīng)也大致如此。另外，Canister也繼承了Actor的一些特性：
Canister的私有狀態(tài)只能由該Canister自己更改
每個Canister的執(zhí)行都是單線程的，因此不需要基于鎖的同步性
可以通過異步消息與其他Canister通信
在Actor模型中，一條消息的接收者是由地址（有時也被稱為郵寄地址）識別的。因此，Actor只能在知道對方地址的情況下和其它Actor進(jìn)行通信。
例如，電子郵件可以被建模為一個Actor系統(tǒng)。用戶的帳戶被建模為Actor，電子郵件地址被建模為Actor地址。而Canister也有一個類似于IPv6地址的郵寄地址。
單個Canister在更新狀態(tài)時只擁有一個執(zhí)行線程，但I(xiàn)C可以同時并行執(zhí)行大量的Canister。這就是IC如何克服智能合約的一些早期平臺的性能限制。
此外，IC還將請求分為兩類：一類是需要更新Canister狀態(tài)的請求，另一類是查詢，不能改變Canister狀態(tài)。
這樣一來，雖然單個Canister更新請求的吞吐量受到單線程和區(qū)塊鏈性能的限制，但查詢請求卻可以達(dá)到每秒上千的吞吐量和毫秒級延遲。也就是說，更新是需要上鏈的消息（請求），而查詢的消息是不需要經(jīng)過區(qū)塊鏈的。
為了讓瀏覽器和移動端App能夠直接在Canister進(jìn)行更新和查詢，終端用戶也必須作為一個Actor參與到模型中來。
補(bǔ)充一點(diǎn)，Dfinity特有的Motoko語言正是受到了Actor模型的啟發(fā)設(shè)計出來的。
小結(jié)
Canister是互聯(lián)網(wǎng)計算機(jī)的基石，也是組成網(wǎng)絡(luò)服務(wù)的原子——大規(guī)模的互聯(lián)網(wǎng)服務(wù)需要由眾多Canister互相協(xié)作完成。
關(guān)于進(jìn)程和WebAssembly的解讀會放在文章的下半篇：
ICP是如何作為一個操作系統(tǒng)如何管理其中的進(jìn)程-Canister的？
Canister實際在IC上又是如何執(zhí)行？
引用參考：
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
end
點(diǎn)個在看，讓更多人看到原力區(qū)~