【ICP #1】ICP復習

2023-2-11

C3F の方とミーティングする機会があったので、この機に情報精査。

1. ICP 関連

imageAlt

1-1. 概要

2015 年にコンセプト考案
2016 年に Dfinity foundation の設立
2021 年にメインネットローンチ
従来のインターネットを拡張し、アプリケーションを実行するためのリソースをコンピュータのグローバルネットワークで提供するもの。
AWS、Microsoft Azure といった中央集権的なサーバー体制を完全にオンチェーン化を目指し、分散化されたアプリケーションの構築を実現する。

1-2.キャニスター

IC にホストされるスマートコントラクト。コンパイルされた実行プログラム、データを保存するためのメモリも持つ。

1-3. サイクル

サイクルとは、イーサリアムにおけるガスのようなもので、キャニスターが稼働するためのコストとして使われる。根本的な違いは、イーサリアムが「ユーザーペイ」、IC は「スマートコントラクトペイ」（リバースガス）モデルを活用している点。キャニスターにあらかじめ開発者がサイクルをチャージするため、エンドユーザーは自分が開始した計算の対価としてトークンを支払うことなく、サービスを利用可能。
ただし、送金手数料自体にはガス代がかかる。Sonic といった DEX で Swap する際にガス代の要求が出てくる。

なぜサイクルに変換する必要が？

ICP トークンは市場価格により変動しますが、サイクルの価格はキャニスターの運用コストが予測可能であることを保証するために固定。開発者が IC 上で開発を行いやすくするためにサイクルを用いる。

1-4. Dfinity とは

Dominic Williams 氏が創設した Dfinity 財団という非営利団体。
ブロックチェーンを活用して分散型のネットワークを構築し、IT 大手のような特定企業に依存している現状から脱却することを目指す。
カストディアルのデメリットとして、AWS 等に障害が発生した場合、銀行等のアプリが使えなくなり広範囲に影響を及ぼす。
そのため、分散型ネットワークを構築する。
まとめると世界中の独立したデータセンターから提供される計算リソースを、ICP というプロトコル（手順・ルール）でまとめることで、アプリケーションサービス等を実装できる分散型ネットワーク（＝インターネットコンピューター）を構築。

1-5. 他パブリックブロックチェーンとの相違

Dfinity 財団は、プロジェクトを「ブロックチェーンにおける第三の発明」と位置づけ。
ビットコインは「デジタルゴールド」、イーサリアムは「DeFi 革命の原動力」とし、その上で自らを「あらゆるものを再構築できるブロックチェーン」と表現。

imageAlt

2. ICP での開発モチベ(C3F の動画参照)

2-1. ユーザのガス負担が０（リバースガス機構）

開発者側で負担する。チャージして使っていくモデル。

2-2. アプリ丸ごと分散化（フロントエンド）

バックエンド含め、丸ごと載せることができるのは IC ならでは。デメリットは AWS のような利便性はない。楽に開発したい人にとっては向いてない。
一概にメリットとは言えないが、思想の問題。Amazon にデータ置きたくないなどあれば。

2-3. HTTP アウトコール（WEB2 データとの連携）

サブスクとか BTC 払いでするのが簡単にできるし、web2 の中に送金機能を組み込める。
ガスがリバースガスなので、NFT を統合することで、イーサリアムの NFT を IC にもってくると
転送がガスフリーになるといったユースケースが考えられる。
ここで、ガス代かからない利点活かせるのがすごそう

2-4. BTC 統合

BTCAPI を介して UTXO のトランザクションを直接参照して、扱える。
ckBTC キャニスターで、ビットコイン上の UTXO を IC 上で再現している。
ck とは chainkey を意味し、wrapped btc に近いが異なる。ブリッジではない。
カストディアルが管理してないので、理論上ペグが外れることがない。
何かしら差別化しないといけないので、名付けたよう。LN ライクな BTC。
IC の仕組みで署名するので、BTC でより安価に送金が可能になる。
BTC を扱った DEX の登場が期待される。

3. 現時点のデメリット

3-1. 負荷耐性/スケーリング

一番致命的な課題。ユーザーが増えた場合の懸念事項。Dfinity が解決してくれること期待。
NNS1 というガバナンストークン最近でたが、dfinity のダッシュボードにアクセス集中した際に落ちた。
web2 では大したことないレベルだったにもかかわらず。原因は負荷耐性といわれている。
スケーリングについては、キャニスターは 32GB、といった制限があるので、ストレージ扱う Dapp の場合、
でスケーリングの処理を書かないといけない。(簡単にできるものなのか？調べる必要あり)

3-2. データ書き込みが遅い(updcall/1-2sec)

querycall ははやい
データアップデート updcall に関しては 1,2 秒で遅い。
バックエンド側の更新遅いだけなので、フロントエンドで処理してしまって、裏側でその間処理すれば
多少カバーできるか。アトミック性がないと言われている。
データの書き込み 1 回 2MB。なので、動画か画像をチャンク化して送る（ex パピルスという note のような dapp）
方法など活用する。ただし現在はその必要もなくなったらしい。
負荷分散しないと、今はすぐ落ちるのでまだ課題といえる状況。

3-3. 開発ツールの少なさ

Firestore のような DB が欲しい。今は自身でデータ管理、アクセス制限といったセキュリティ周りもしないといけない。
DB については、3rdparty で出てくる。(ex. weaveDB)なくても自前実装。

3-4. webview から II 認証できない

スマホアプリに web サイトを埋め込むと II 認証できない仕様が確認されてる

3-5. コスト計算

サービス運用時、不確実な要素が多くコスト見積もりが難しい。
時間が解決してくれるはず。

3-6. データの永続化

コードをデプロイするときにその書き方しないといけない。
現時点では、データ型を変えるときにデータを引き継ぐような処理を書かないといけない。キャニスターごと変えてしまう仕様。

4. その他

solidity と違い、IC だとガス代気にしないので書きやすい。Motoko か Rust で書く。
とりあえず動くアプリなら motoko で直感的に書ける。ただし、ライブラリが揃っていないため Rust のが現時点応用効かせやすい。
motoko hello world アプリケーションから始めるといい。

5. 参考

web アプリ開発、主にバックエンド側の知見がないので、ピンとこない内容も多々あった。
キャッチアップしていこう。