The Internet Computer for Ethereum Developers （日本語訳）

Published in

DfinityJP

19 min readJun 4, 2022

Internet Computer のブロックチェーンを Ethereum と比較して独自機能を解説した資料ガイドです。

多くの開発者にとって、スマートコントラクトプラットフォームとの最初の接点は Ethereum です。そのため開発者が後に Internet Computer（IC）に出会ったとき、どう動作するかについて多くの先入観を持ってしまい、それが Internet Computer の実際の動作と必ずしも一致するとは限りません。

今回は、多くの開発者が遭遇する違いを説明し、 Internet Computer の独自機能を紹介します。EthereumとInternet Computer の用語は若干異なるため、基本的にEthereum 開発者の共通用語で説明し、独自の専門用語について下記で説明します：

contract → Canister
gas → Cycles
shard → Subnet （Ethereum は現在、データシャードのみを考慮しているため完全にマッチするわけではありません。）
(validator) nodes → Replicas

Internet Computer のごく簡単な紹介

具体的な違いのリストに入る前に、IC 全体について簡単に説明します。IC は、ほぼ独立した Subnet のブロックチェーンのネットワークですが、コントラクトは Subnet 間でオープンな形で相互に対話することができます。これにより、Subnet を継続的に追加することで、IC の水平スケーリングが可能になります。Subnet はネットワーク・ナーバス・システム（NNS）によって管理されますが、これは基本的に、（システム）の Subnet （NNSとも呼ばれます）自体で稼働する分散型自律組織（DAO）です。IC には、NNS にステークしてガバナンスに参加することができて IC 上のリソース消費に対する支払いを行うために Cycles に変換するメインユーティリティトークンである ICP があります。IC 上のコントラクトは Canister と呼ばれ、WebAssembly（Wasm）のバイトコードを含んでいます。これにより開発者は様々なプログラミング言語でコントラクトを作成することができます。さらに、IC 用のアクターモデルで Canister を書くために作られたプログラミング言語 “Motoko” があります。

Internet Computer の仕組みをもっと深く掘り下げたい方は、以下の資料を見てください。

The Internet Computer for Geeks
The Internet Computer “How It Works” series, with many in depth articles and videos
The official Developer Documentation
The Internet Computer Interface Specification
The Developer Forum and Discord

Ethereum と Internet Computer の違い

さっそく、Ethereum と IC の顕著な違いについて説明します。これらの違いを以下のカテゴリーに分類して整理します。

ユーザーエクスペリエンス（UX）
デベロッパーエクスペリエンス
スケールとコスト
プライバシー
能力差

ユーザーエクスペリエンス（UX）

外部アカウントはガス代がかからない

IC は逆ガスモデルを実装しており、コントラクトはリソースの対価を Cycles で支払わなければならない。そのため、アプリケーションのユーザーはアプリケーションとやり取りするためにウォレットやトークンを必要としません。そうであっても、Web Authentication 規格に基づく暗号認証システムである Internet Identity を利用することが出来て、ユーザーは Dapps に認証することも出来ます。

Canister はどのようにリソースを支払うのかというと、すべての Canister は Cycles バランスを持ち、そのバランスは他の Canister から補充することができます。もちろん、ユーザーに ICP で料金を支払ってもらい、Canister で ICP を Cycles に変換させる Ethereum のガスモデルを模倣した方法も可能です。したがって、この点では IC の方がはるかに柔軟性があります。

ユーザーはブラウザから安全に IC を操作することができる

Ethereum 上のユーザーとアプリケーションのやりとりは、通常次のようなものです。

ユーザーがブラウザでアプリケーションのドメインを指定します。
アプリケーションのフロントエンドは、従来のホスティングプロバイダーによって提供されます。
ブロックチェーンからの（ダイナミックな）データは、通常、アプリケーションプロバイダーが提供する集中型バックエンドか、Infuraのようなサービスプロバイダーによってプロキシされます。
ユーザーは自分のウォレットを使ってアプリケーションに接続します。
フロントエンドはトランザクションを作成し、ウォレットに署名とトランザクションの送信を依頼する。非金融系アプリケーションの場合でも、ユーザーはガス代を支払うためにウォレットにETHを所持している必要がある。
ユーザーはウォレットの使用を承認し、ウォレットは署名されたトランザクションを送信する。
ユーザーは、取引が確認されるまで、ネットワークの現在の使用状況や提供される料金に応じて、数十秒から数分間待ちます。（現在のコストと待ち時間については、ETH Gas Stationを参照してください）

IC では、いくつかの重要なイノベーションの相乗効果により、ユーザーはウォレットを設定することなく、暗号通貨を購入することもなく、仲介者に頼ることなく、IC 上のアプリケーションと安全にやりとりすることができます。

チェーンキー技術と Subnet により、軽量な検証とレプリケーションの低減や水平スケーリングでコスト削減が可能です。
逆ガスモデルにより、コントラクトにあらかじめガスを充填しておくことでユーザーの利用を簡素化することができます。
Internet Identity では、WebAuthenticationと委任メカニズムを使用して、IC 上のサービスに対してプライバシーを維持した認証が可能です。暗号化された秘密は安全なハードウェアで管理されます。
バウンダリーノードと認証済みアセットコントラクトにより、コントラクトから直接フロントエンドにサービスを提供することができます。

では、IC上の Dapps との対話はどのようなものなのでしょうか。

ユーザーはブラウザをアプリケーションのドメインに向けるように指示します。このドメインは、 ic0.app ドメインに直接またはブラウザが ic0.app ドメインにリダイレクトされるかのいずれかです。
サービスワーカーがインストールされ、Java Script エージェントを使用して、IC 上のコントラクトから発生する認証済みアセットを確認することができます。サービスワーカーの仕組みはブラウザが IC をネイティブに、あるいは拡張機能を使ってサポートするまでの一時的な回避です。
ユーザーは、Internet Identity や他の認証方式でログインするよう求められます。
ユーザーは料金を支払うことなく、Dapps と対話することができます。ステート変化の更新は簡潔なUIパターンを利用してほとんどユーザーには見えることがなく、数秒で完了します。

自分でやってみましょう。例えば icApps に行って IC で人気のある Dapps をいくつか試してみてください。

Developer Experience

コントラクトはデフォルトでアップグレード可能

Ethereum では、コントラクトはイミュータブル（不変）です。コントラクトにバグがあった場合、開発者ができることはほとんどありません。そのため、プロキシコントラクトのような巧妙な回避策がとられ、ユーザーにとってさらなる複雑さとリスクをもたらすことになりました。IC ではコントラクトはデフォルトでミュータブルです。各コントラクトには、コントラクトをアップグレードする権限を持つコントローラのリストが関連付けられています。コントローラを空のリストや Block hole コントラクトに設定することで、コントラクトを変更できないようにすることはできます。しかし、IC コミュニティでは、ほとんどのコントラクトは IC 自身と同様に、分散型自律組織（DAOs）によって管理されるようになるというビジョンがあります。そこで、DFINITY ファウンデーションは、IC を統治する Network Nervous System にヒントを得て、IC 上のサービスを統治するためのカスタマイズ可能なターンキー・ソリューションである Service Nervous System に取り組んでいます。

コントラクト間呼び出しは非同期でありアトミックではない

Ethereum Virtual Machine（EVM）は同期型であり、トランザクションはアトミックである。これは、ユーザーがトランザクションを送信した場合、トランザクションは完全に実行されるか、またはトランザクションで発生したガスを消費する以外、何の影響もなくステートが完全にロールバックされることを意味します。これはトランザクションに関与するコントラクトの数に関係なく言えることです。この特性はフラッシュローンのような興味深いイノベーションにつながりましたが、Ethereum のネットワーク全体が単一のプロセスとして機能するため、スケーラビリティを著しく制限しています。IC 上では、コントラクト間の呼び出しは非同期です。コントラクトで await を使うたびに、ステートがコミットされます。関数がトラップした場合、ステートは await が最後に発生したところまでしかロールバックされない。これについてはこちらのドキュメントで詳しく説明されています。また、DeFiに関する様々なモデルについて、素晴らしいフォーラムへの投稿があります。

コントラクトはガス不足になると削除されます

Ethereum ではコントラクトは永続的です。これにはメリット（開発者やユーザーの安心感）もあるが、デメリット（スケーラビリティの制限）もかなりあります。Ethereum のステートは際限なく拡大しており、開発者が空きスペースを確保するインセンティブはほとんどなりません。それゆえ、多くのプロジェクトがとっくに放棄されているにもかかわらず、Ethereum のステートには2017年の ICO トークンがすべて残っているのです。IC 上はコントラクトが実際のリソース消費量に応じて Cycles を消費します。コントラクトが呼び出されない場合でも、ごくわずかではありますが、ある程度の Cycles を消費します。これは、プラットフォームの持続可能性にとって重要なことです。Ethereum から IC に移行する際、開発者はしばしば Cycles の消費について、また自分のコントラクトが突然削除されるのではないかと不安になる。しかし、IC には2つの効果的なセーフガードが組み込まれています。

コントラクトがイングレスメッセージ（IC 外から発信されたメッセージ）を参照して、そのメッセージを処理するかどうかを決定できる inspect_message 機能があります。このイントロスペクションは有料ではありません。
IC は、自動的にすべての呼び出しを拒否し、基本メンテナンスのみを支払う事で Canister を凍結することができます。各 Canister には秒単位で設定できる「凍結しきい値」があり、この期間のメンテナンス費用を支払う残高を持つことで IC が Canister を凍結できることが基本的に保証されています。デフォルトの凍結しきい値は約30日で、開発者やユーザーはガベージコレクション（完全削除）される前に Canister を補充するのに十分な時間があると思われます。

それでも、IC で自律的なサービスを実現しようと思ったら、その経済性を考えなければなりません。そうしないと、Cycles が不足してしまい、削除されてしまうからです。

ガス料金は予測可能

EVM では、特定の操作（Opcode）にはガスで測定されるコストが定義されていますが、ETH とガスの間の為替レートはすべて市場によって定義されています。ユーザーは取引で支払うことを望む maxFeePerGas を定義でき、個々のマイナーはこのオファーを受け入れられると判断するかどうかを決定します。Ethereum の処理能力は非常に限られているため、ガスの価格は需要によって乱高下する可能性があります。また、米ドルやユーロでの実際の価格は現在のETHの市場価格によってさらに予測不可能になります。

Ethereum のガスと同様（ただし、それよりも広範囲）、IC には様々なリソースに対して Cycles での固定価格が設定されています。しかし、主な違いは、Cycles の価格が世界の主要通貨のバスケットに基づくSDR に固定されていることです。

1 SDR = 1 Trillion cycles

SDR と ICP の交換レートは、NNS が管理しています。従って Canister の実際の運用コストは、ICP の現在の市場価格に左右されず、比較的安定して予測可能です。

ICP トークンはシステムの一部ではなく、コントラクトとして実装されます

ICP トークンは、IC の中で2つの重要な役割を担っています。

IC のリソースを支払うために必要な Cycles を作成するためにバーンすることができます。
IC のガバナンスに参加するために、NNS のニューロンにロックすることができます。

ただし、ICP はシステムステートには現れず、NNS の Subnet 上で動作するコントラクトとして構築されています。Ledger Canister については、こちらとこちらで紹介しています。

Scalability and Costs

48バイトで IC のステートを確認することができる

EVM ステートの検証はノードがブロックチェーン全体を生成から検証する必要があるため、リソース集約的なプロセスです。現在のステートの関連部分に加え、ヘッダーチェーンのみを検証するライトノードを持つことは可能ですが（それでも永遠に成長し続けます）、そのインフラはまだ構築されていません。したがって、ほとんどのユーザーは Ethereum のステートにアクセスするために中央集権的な API、特に Infura に依存しています。これに対して Internet Computer では、クライアントが48バイトの公開鍵でステートを確認することができます。この公開鍵はブラウザなどのソフトウェア、あるいは Internet of Things デバイスなどのハードウェアにハードコードされ、IC 上のコントラクトと安全にやり取りできるようにすることができます。

Internet Computer は水平方向に拡張可能

IC は Subnet のネットワークであり、コントラクトは Subnet 間でオープンに相互作用することができます。Internet Computer の需要の増加に伴い、Subnet を追加することが NNS への提案にすることで可能です。

コントラクトのストレージは桁違いに安い

Ethereum はまだシャーディングを実装しておらず、ネットワーク内のすべてのノードがすべてのコントラクトとすべてのトランザクションを保存し、実行する必要があります。IC では、特定の Subnet にあるノードのみが実行とステートをレプリケートします。これは Ethereum とは対照的にセキュリティを低下させるかもしれませんが、それでも同等のコストを持つ従来のウェブサービスよりもはるかに安全です。Ethereum では1GBの保存が数億円単位であるのに対し、IC では年間数円程度で済みます。このため、剥き出しのバックエンドロジックだけでなく、Webアプリケーション全体や音楽、動画までもIC上でホスティングすることが可能です。ICにかかる一般的なコストの概要については、Computation and Storage Cost のドキュメントを参照してください。

一般的に古いブロックを追跡する必要はない

チェーンキー技術により、新しい（バリデータ）ノードは、ブロックチェーンを生成から同期および検証する代わりに、非対話型秘密分散 key re-sharing を使用してステートをすばやく同期し、バリデータセットに参加することができます。したがってノードは数分ごとに安全にチェーンを除去することができます。しかし、アプリケーションによってはすべてのステート遷移が少なくとも 2/3 のノードによって承認されていることを確認するだけでは不十分で、監査が必要な場合があります。例としては、ICP 台帳や NNS が挙げられます。この場合、監査はアプリケーション、すなわちコントラクト層で実装される。これにより、Ethereum とは対照的に、外部のオブザーバーだけでなく、コントラクトが監査にアクセスできます。

しかし、将来的には、プライベート Subnet とパブリック Subnet の2種類が存在することになります。パブリック Subnet では、オブザーバーが生のブロックデータを入手することが可能になるでしょう。最初のパブリック Subnet は Nervous Network System Subnet そのものになります。

プライバシー

外部アカウントは（直接的には）グローバルなステートの一部ではない

Ethereum のステートは、外部アカウント（ユーザー）と内部アカウント（コントラクト）で構成されています。各アカウントには、関連する ETH の残高があります。IC では、Canister のプリンシパルのみがステートの一部となります。各 Canister プリンシパルは関連する Cycles 残高を持っており、これはデフォルトでは公開されません。これはプライバシー上の利点があり、パブリックになっているステートにプリンシパルを開示することなく、認証された方法で IC 上の Canister と対話することができます。欠点はユーザープリンシパルが直接 Cycles を保持できず、Cycles ウォレットのような Canister を必要とすることです。

グローバルなステートは公開されず、部分的にしか公開されない

Ethereum では、誰もがフルノードを動かすことができるためすべてが公開されています。プライバシーはデータをオフチェーンに置くか、暗号を使うことでしか実現できません。IC では、ノードは NNS によって許可され、IC の一部のみが公開されます。コントラクト開発者が定義する API の他に、以下のデータが公開されます。

コントラクトのある Subnet
コントラクトの名前が表示されます。
コントラクトの WASM モジュールのハッシュ値
コントラクトのコントローラー

特に、実際のバイトコードやコントラクトの Cycles の残高は公開されません。しかし、先に述べたように、IC は将来的にパブリック Subnet をサポートする予定です。これらの Subnet では、IC ブロックの生データを利用できるようになります。

能力差

コントラクトは自ら起動することができる

Ethereum では、ステート変化のたびに外部アカウントからトリガーされる必要がある。しかし、IC では、Canister がハートビート機能を利用して、IC からトリガーさせることができます。これにより新しい可能性が大きく広がります。簡単な例では、他の Canister が自分自身を呼び出すように登録できるcron service などがあります。

コントラクトは暗号化されたランダム性にアクセスすることができる

IC のユニークなコンセンサスアルゴリズムなら暗号学的なランダム性のソースとして使用することができます。このランダム性はコントラクトにアクセス可能であり、宝くじやゲームなどのアプリケーションに利用することができます。

コントラクトは秘密鍵を保持しメッセージに署名することができる(Soon)

Ethereum では、すべてのコントラクトが公開されています。つまり、コントラクトは秘密情報を保持できず、したがって秘密鍵を安全に保存する方法がないため、メッセージに署名することができない。IC のコンセンサスメカニズムでは、バリデータノードが協力して秘密鍵全体を全く存在させずに（BLS）署名を作成する、閾値署名と呼ばれるメカニズムが使用されています。今後の機能として、コントラクトが IC に閾値 ECDSA 署名の生成を指示するための同様のメカニズムが利用できるようになる予定です。これらの署名は、通常の ECDSA 署名と同様に IC の外部で検証可能です。つまり、IC 上のコントラクトで Ethereum や Bitcoin のトランザクションに署名したり、JWT や検証可能なクレデンシャル、x.509証明書を作成したりすることができるようになるのです。

コントラクトで Web サービスを呼び出せる (Soon)

Ethereum 上で外部からのデータが必要な場合、Ethereum 上のコントラクトにその情報を送り込むオラクルが必要です。IC 上では、コントラクトの内部からWebサービスを呼び出すことが間もなく可能になります。この機能については、フォーラムで詳細を読んだり、コミュニティの会話を見たりすることができます。

この記事を読んだ後、IC のメンタルモデルをより良く理解することができたと思います。IC の長所をあなたの問題に適用することができ、限界のいくつかを認識し、なぜそれが存在するのかをよりよく理解していることでしょう。

理想的には、この記事はコミュニティ、つまりあなたによって時間をかけて更新され、IC を発見した新しい開発者に包括的なリファレンスを提供する生きた記事となります。そのため、この記事は Medium だけでなく、投稿を受け付けている Internet Computer Wik iにも掲載されています。