
Dfinity用語解説:キャニスター(キャニスター・スマートコントラクト)
元記事:https://support.dfinity.org/hc/en-us/articles/360057605571-Canister-Smart-Contracts
Canister Smart Contracts
概要:
・プログラムと状態をパッケージ化したもの(コンテナに似ている)
・キャニスタープログラムはWebAssembly(Wasm)でエンコードされるスタックベースの仮想マシン用のバイナリ命令フォーマット
・サブネット上にデプロイされる
➡大抵のDappは、異なるサブネット上の複数のキャニスターに分割して構成する(マルチキャニスター・アーキテクチャ)
➡IC側で勝手に選出されたサブネットにデプロイされて、クライアント側で選択や指定は出来ない。(将来的には選択と指定できるようにする予定)参考:https://forum.dfinity.org/t/could-we-deploy-a-canister-on-a-specified-subnet/7936/2?u=ueyamamasashi
・透過性
ユーザーやキャニスターは、(サブネット内でもサブネット間でも区別なく)キャニスターのIDを知るだけで、キャニスターが共有する機能を呼び出すことができる
・キャニスターが保持するすべてのメモリーが永続化される
➡メモリは4Gまで(WASM32bitの制限)
➡プラスwasmヒープが4Gあるが、キャニスターのアップグレードで消去される
➡イベントやユーザーとのインタラクションの記録、ソフトウェアの状態に関する情報を保持
➡アプリケーション機能が使用された結果、変化した状態を保持する
➡WASM32bitを採用しているからだが、WASM64bitに対応できるようになると巨大なデータを扱うことができる。
➡サブネットクラスBigMapでは、エクサバイト(ギガ→テラ→ペタ→エクサ)のデータを格納するクラスとのと。まだ対応していないが、たぶんWASM64bitに対応することで利用でるようになると思われる
・コントローラ(principal ID所有者)によりアップグレード可能
➡コントローラーのprincipal IDをNULLにすることにより(通常のスマートコントラクトのように)変更を禁止することができる

キャニスター・スマートコントラクトは、プログラムとステート(状態)の両方を含む計算ユニットです。ソフトウェアキャニスターはコンテナと似ており、どちらもダップ(Dapp)またはシステムのコンパイル済みコードと依存関係を含むソフトウェアユニットとしてデプロイされます。
※コンテナ:
Dockerなどで使われる用語。OSライブラリ、ミドルウェア、アプリケーションをパッケージ化したもの。他のOSにそのまま移動することができる。
※スマートコントラクト
ブロックチェーンシステム上の概念であり、あらかじめ設定されたルールに従って、ブロックチェーン上のトランザクション、もしくはブロックチェーン外から取り込まれた情報をトリガーにして実行されるプログラム
コンテナ化により、アプリケーションを環境から切り離すことができ、簡単かつ信頼性の高いデプロイメントが可能になります。しかし、キャニスターは、先行するイベントやユーザーとのインタラクションの記録とともに、現在のソフトウェアの状態に関する情報も保存するという点で、コンテナと異なっています。
コンテナ化されたアプリケーションには、アプリケーションを実行する環境の状態に関する情報が含まれることがありますが、ソフトウェアキャニスターは、アプリケーションの機能が使用された結果、状態が変化したという記録を持続させることができるのです。
このように、プログラムと状態の両方で構成されるキャニスターという概念は重要です。なぜなら、スマートコントラクトの関数のエントリポイントにメッセージを送信して呼び出す場合、コミットしないクエリーコールとコミットするアップデートコールの2種類しかないためです。
【Dfinity wiki、Whiteペーパーなどから補足】
・スケーラブルなスマートコントラクト
・インターネット・コンピュータ上に構築されたDappは、1つ以上のキャニスターで構成される
・後からアップグレード可能
- イーサリアムなどのスマートコントラクトでは、一旦デプロイすると書き換えできない
- Canister にはコントローラと呼ばれる ID(principal ID)を設定でき、その ID を有するユーザからの Canister のアップデートが可能
- principal ID所有者がCanisterをアップグレードできないよう設定することができる
・キャニスターは特定のサブネットタイプを指定する必要があり、能力を規定する
- NNS用
- システム・サブネット
- データ・サブネット
- フォーキャスト・サブネット、
Canister smart contracts are computational units that include both program and state. A software canister is similar to a container in that both are deployed as a software unit that contains compiled code and dependencies for a dapp or system.
Containerization allows for applications to be decoupled from the environment, allowing for easy and reliable deployment. The canister differs from a container, however, in that it also stores information about the current software state with a record of preceding events and user interactions.
While a containerized application might include information about the state of the environment in which the application runs, a software canister is able to persist a record of state changes that resulted from an application’s functions being used.
This concept of a canister consisting of both program and state is an important one because when a smart contract function is invoked by sending a message to one of its entry points, there are only two types of calls: non-committing query calls and committing update calls.