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