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
