Ethereumは、今最もDapps開発で利用されているプラットフォームです。Dappsとは分散型アプリケーションの略称で、ブロックチェーン上にアプリケーションを配置する(デプロイする)ことで、中央管理者が不要なシステム構築を可能にしています。例えば、"トークン"と呼ばれる仮想通貨は、Ethereum上のDappsとして作成されているケースが多いです。
なぜEthereum上のDappsで多くの通貨が作成されているのでしょうか。それは、ERCと呼ばれる共通規格が他のプラットフォームに先んじて整備されていることが理由の１つでしょう。
ERCとはEthereum Request for Commentsの略称で、Ethereumに関連する技術仕様の提案書を指します。Ethereumのコミュニティは他のブロックチェーンコミュニティに比べ活発であるため、現在までに多くのERCが議論されています。
その中でも最も有名なERC20は、通貨としての機能を定義した規格です。いわゆる"地域通貨"や"〇〇コイン"と呼ばれる類の多くは、このERC20をベースとして作られています。そのため、ERC20の仕様さえ理解してしまえば誰でも簡単に通貨を作成することができます。
※ただし、その通貨が広く知られて使われるかは別の問題です。
ERC20に関する説明は多くの記事で詳しく紹介されているため本記事では割愛させていただきますが、ERC20をベースに開発者が通貨をつくる場合のフローは以下のようになります。
OpenZeppelinと呼ばれる、Ethereum開発を行う上で人気のライブラリには、IERC20.solという定義ファイルが提供されており、これを継承したコントラクト（ロジック）を自分でコーディングする必要があります。幸い、OpenZeppelinには見本となる実装例が既に存在しているため、適宜参考にしながら開発を進めることができます。
| No | 機能名 | 概要 |
|---|---|---|
| 1 | transfer | 所有しているトークンを指定した数量だけ宛先に送金します |
| ２ | balanceOf | 所有しているトークンの残高を確認します |
| 3 | totalSupply | トークンの全発行数量を確認します |
独自通貨の特徴となる機能を追加したい場合は、そのロジックも追加で記載することが可能です。例えば、いろんな人にトークンが分配されるよう、毎月ランダムにトークンを分配するといった独自ルールも組み込むことができます。多くの人に使ってもらえるような通貨を考える場合には、追加機能の設計が特に重要になります。
ブロックチェーン上に作成したコントラクトをデプロイします。デプロイ時に通貨名や通貨の発行量を定義することができるので、適切な命名・数値を定義します。
1~3のフローを行う場合、慣れた開発者にとっては簡単な作業ですが、一般のユーザが誰でも実行できるわけではありません。複数の通貨を作成したい場合は、その都度開発者が上記のフローでコントラクトをデプロイしていくことになります。そのため、一般の人が考えたアイディアが通貨として実現されるまでには必然的にタイムラグが発生してしまいます。
もう１つ有名なトークン規格に、ERC721と呼ばれるものがあります。ERC20が"お金"という位置づけならば、ERC721は"個性"となります。例えば人間を考えた場合、一人ひとりが異なるDNAを持っており、似ていることはあっても全く同じ人は存在しません。ERC721では、この個性をIDという一意な番号を振ることで実現しています。このIDはトークンIDと呼ばれ、トークンIDごとにどのアドレスが所有しているかをマッピング情報としてERC721コントラクトで管理しています。ERC721のような個性をもつものをNFT(ノンファンジブルトークン)、ERC20のような等しく交換可能なものをFT（ファンジブルトークン）と呼びます。
| No | 機能名 | 概要 |
|---|---|---|
| 1 | safeTransferFrom | tokenIDを適切なアドレスに譲渡します |
| ２ | balanceOf | 所有しているtokenIDの数を確認します |
| 3 | ownerOf | 指定したtokenIDの所有者を確認します |
この２つはそれぞれ別々のコントラクトとして作成・デプロイされるため、両者の橋渡しをするコントラクトを別途作成する必要があります。コントラクトの実行にはガスと呼ばれる手数料(Ether)が必要になりますが、複数のコントラクトを実行させることによって消費するガスの量も増加します。また、上図のようにコントラクトを最低でも3つ用意する必要があるため、設計や実装の難易度は上昇します。
上記の課題を一気に解決しようとしている規格がERC1155になります。ERC1155の特徴を端的に表すと、ERC20とERC721の特徴を同じ形式で管理することができるようになります。FT(ファンジブルトークン)とNFT(ノンファンジブルトークン)の交換も、アイテムIDに紐づいている所有者のアドレスを付け替えるだけで交換が可能です。
また、ERC1155はプラットフォーム型になっているため、複数のFT/NFTを共存させることができます。デプロイ時に定義を決定するERC20やERC721とは違い、ERC1155ではデプロイ後にトークンの特徴を定義するため、一般ユーザが自由にトークンを追加作成することもできます。
※ERC20/721でもアップデート用の追加機能を実装することで後から再定義することは可能ですが、複数の種類を共存させるには別々のコントラクトが必要になります。
ERC1155は2018.10.28現在もディスカッション中で、ERC20/721のように正式に仕様が固まった規格ではありません。直近では、2018.10.18にも「Crypto Items Token Standard」から「Multi Token Standard」へと名称が変更されました。 本記事では2018.10.28時点での最新情報を元に記載しています。
| No | 機能名 | 概要 |
|---|---|---|
| 1 | create | FT/NFTのアイテムタイプを定義します |
| ２ | mintFungible | FTとして定義されたアイテムタイプのトークンを指定数量分だけ発行します |
| 3 | mintNonFungible | NFTとして定義されたアイテムタイプをベースに指定数分IDを発行します |
ERC1155にてトークンがつくられる過程は以下のようになります。
ERC1155では「アイテムID」と呼ばれる単位でトークンを管理していきます。まずは、必須機能として実装されるcreate機能を実行することで、アイテムの型を定義することから始めます。createが実行される度に、nonceと呼ばれるカウンタが1増加します。createを実行するときに、NFTとして作成するかFTとして作成するかを指定する必要があります。ただし、この段階ではまだトークンを使用することができません。
FTを使用可能なものとして生成します。1.で生成したIDは、FTの場合トークンの種類を表します。つまり、新たな通貨を発行したい場合は、1.で型を定義するだけでよく、後からいくらでも通貨種類を増やすことが可能です。mintFungibleでは、定義済みのトークンに対して、新規発行量や追加発行量を指定して生成することができます。
上図では、定義済みのFTを10000新規発行した様子を表しており、指定したアドレスに対して所有権をマッピングした状態で発行されます。ERC1155にもtransfer機能が存在しますが、ERC20と異なりアイテムIDを指定する必要があり、どの通貨をいくら送るかを自由に指定することができます。
NFTを使用可能なものとして生成します。1.で生成したIDは、NFTでは「型」として利用され、追加で128ビットの配列を足し合わせたものが最終的なNFTのアイテムIDとなります。（256ビット固定） mintNonFungibleでアイテムを生成するとき、1.で生成されたIDを指定する必要があり、同じアイテムの型が指定された場合は1ずつインクリメントされた同じ型の新しいアイテムIDが生成されていきます。
ERC1155が誕生した背景に、ERC20とERC721を同一コントラクトで利用したいという目標があったため、上記に記載したものはERC1155の標準的な使用例になります。ここからは、少し解釈を拡大し、可能となる仕組みをいくつか見ていきます。
アイテムIDは0と1が並ぶビット配列です。FTとNFTを見分ける方法として、先頭のビットが「1」の場合NFT、「0」の場合はFTと定義されています。これを応用し、特定の位置が「1」であることに意味を持たせることができます。これにより、特定のユースケースでしか利用できないような制約の追加や、グループ化によるアイテムの整理が可能になります。
ERC1155は一度適切に設計されると、一般ユーザが好きなタイミングでトークンを定義・作成することができます。これを利用して、小さなトークンエコノミーをエリアごとに作成し、エリアを飛び越えたベース通貨をつくることで、マルチトークンエコノミーを作成することができます。
どのトークンエコノミーが発展して衰退するかの社会実験という位置付けにすることも可能ですし、会社などの特定組織でグループごとに独自通貨をつくり適切な競争を生み出すこともできるかもしれません。
ERC1155は今後も定義が変更となる可能性がありますが、ERC1155の考え方をベースにコントラクトを作成することで、あらゆる表現が単一コントラクトで簡単に表現できるようになります。また、ERC721xなど優れた規格が次々に発表されており、ブロックチェーン界隈の動向は非常に激しいものとなっておりますが、コントラクトの考え方自体が大きく変わるものではありません。まずはお手軽なERCトークンの規格を読んで、開発者であれば実際に動かしてみて、コントラクト開発のベースとなる考え方を身につけることが、新たな分散型システムのアイディアに繋がる近道かもしれません。
ERCトークンを使用した設計に関してご質問・ご相談などございましたらお気軽にご連絡ください。「トークンでこんなものつくりたい！」という相談にもお答えします。->Twitter
