タグ: "ERC"

イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

2018/03/06 at 3:07 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。 本記事は盗難・凍結したETHを取り戻す方法を提案したEIP-867にまつわる連載記事の後半です。前半記事では、EIP-867で提案されたETH回収の仕組みについて解説しました。本記事ではこの提案に関する考察と、イーサリアムEIPコミュニティの編集者である平井氏が示した2つの懸念に焦点を当てて解説をします。 ハードフォークによる救済 当時最大級のハッキング被害が発生したThe DAO事件では、イーサリアムがハードフォークすることによってハッキングが無かったことになり、ETHは取り戻されました。ハードフォークではブロックチェーンに大幅な仕様変更を加えるために、それまでのブロックチェーンとの互換性は保たれなくなります。 ハードフォークする新たなブロックチェーンが提案された際、この新しいブロックチェーンを正当なものとして受け入れるかどうかは、ネットワーク上の各ノード(ブロックチェーンの管理やマイニングを行っている世界中に分散したコンピュータ)が選択します。 The DAO事件では、ある特定のハッキングのみを無効にするということが、ブロックチェーンの特長である ”過去に起こったことが変更不可能である” という性質に反するとして、1割程度のノードから反対されました。結果として、9割方のノードが採用した新しいブロックチェーンが正式なイーサリアムとなり、反対の立場にあるノードが元のブロックチェーンを運用し、これがイーサリアムクラシックとなりました。 このようにハードフォークを行うには、その提案を行う事自体の労力に加えて、ノード全体の半分以上の同意が必要であり、簡単に実現できるわけではありません。 EIP-867によるソフトフォーク EIP(Ethereum Improvement Proposals)コミュニティでは、現状のイーサリアムの問題に対する解決策が議論され、一般的に現状のイーサリアムに互換性のある形式の提案が承認され、アップデートとして配信されます。 EIP承認の流れやERCについての記事はこちら ネットワーク上のノードは、このEIPで承認されたアップデートをマイナーな公式アップデートとして受け取り有効化していきます。 EIP-867で提唱されたETHの救済方法は、このEIPの承認手順に則ったソフトフォーク的な方法だと言えます。 EIP Editorとは? EIPコミュニティには、EIP Editorという権限を持つ人物がいます。彼らは新たな提案を受け取り、その提案が適切である場合はEIPとして番号を与えて、EIPに関するGithubレポジトリに提案を検討(Draft)状態として公開します。 また、公開された提案に対する議論の末、EIPが公式アップデートとして取り込むべきと判断した場合には、提案を承認(Accept)し最終版を確認(Final)した上で公式なアップデートとします。 (提案されたEIPが経るプロセスフローチャート 引用:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md ) 2018年2月22日現在、EIP Editorはイーサリアムの開発者であるVitalik Buterin氏を含め6名です。EIP EditorやEIPコミュニティの目的やガイドラインについてはEIPの1番としてGithub上に掲げられています。 EIP Editor 平井洋一氏の懸念と辞職 2017年2月上旬に、6名いるEIP Editorの一人であった日本人論理学者の平井洋一氏が、EIP-867に関する提案を以下の2つの懸念事項を理由に受け入れられないと表明しました。平井氏はその後、この件をきっかけにEIP Editorを辞職します。この一件は、今回巻き起こっているEIP-867に関する倫理的な議論を象徴する出来事だと言えるでしょう。以下に平井氏の懸念事項を紹介し考察します。 平井氏の懸念 ① 〜イーサリアムの分散自治的な側面〜 ブロックチェーン技術に根ざしているイーサリアムは、そもそも国家や政府はもちろんのこと、どの様な立場の人や組織も管理権限を持たない分散自治組織的な設計がされています。この組織では権限者が居ないかわりに、全ての意思決定で全ユーザーの投票により過半数以上の賛成を必要とします。 しかし、そうとは言ってもイーサリアムの技術的な変更も公平なユーザーの投票によって過半数を得る事が最善とは言い切れません。イーサリアムは元々Vitalik氏を中心とした天才的なプログラマ達によって開発されている緻密な暗号理論に基づいたシステムです。これを正しく更新し続ける為には高度な専門知識が必要になります。そのため、イーサリアムEIPではこの様な背景から、EIP Editorが改善案の承認を最終的に行う事で初めて公式なアップデートとなるような一部の管理権限を認める仕組みを設けています。 この様な理由から権限を持つEIP Editorは慎重に検討して、イーサリアムコミュニティ全体にとって公平な改善案のみを承認するべきだと言えます。 平井氏の懸念事項の一つ目はこの点です。つまり、もし今回提案されたEIP-867が承認されれば、今後不正(と思われる)ETHの盗難や凍結があった場合に、この資金を最終的にどのように処理するのかと言う、極めて特定の利益に関わる決定権をEIP Editorが持つことになります。 これは上述したイーサリアムの分散システムの哲学に反します。EIP Editorはイーサリアム利用者の信任を得て決定される訳でも無く、また、その存在についても一般に高く認知はされていません。よってEIP Editorが特定のアカウントの残高情報を変更する強い権限を持つべきではない、というのが平井氏の指摘です。 “I don't think anybody has the authority to make an irregular state change. I don't think I have the authority to review processes regarding who has the authority to make an irregular state change. These beliefs come from the lack of authorizations from Ethereum users. I don't think all users of Ethereum gave authorization to this EIP process, or know about the EIP process. The EIP process is not mentioned in the licenses of Ethereum clients. EIP editors are not chosen democratically either.” (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の懸念 ② 〜日本の刑法との抵触の可能性〜 また日本人である平井氏がEIP Editorとして今後このEIP-867で述べられたERPを承認した場合に、日本の刑法 ”電磁的記録不正作出及び供用” に抵触する可能性があることを述べています。この刑法は、ある電磁記録に関する権限を持っていない状態で記録を作り出す・改変することを罰するという内容のものです。 例えば他人の預金残高の記録を持ち主の許可無く改変することはこの刑法で罰せられる可能性があります。 平井氏は直接的にどのように抵触するかについては言及していませんが、おそらく、EIP Editorとして他人のETH資金の情報を所有者の許可なしに書き換えるERP案を承認する行為が、この刑法での犯罪の幇助にあたると考えているのでしょう。 The Japanese penal code defines a crime called "Unauthorized Creation of Electromagnetic Records". (edit: this item applies also outside of Japan) I'm currently not in Japan but in Germany. I suspect there might be a similar rule in Germany, and I don't know how broadly that applies. Once I thought it's enough not to touch individual cases because I had civil cases in mind. After realizing the penal code aspects, I'm not sure if I can do anything here in this pull-request. (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の辞職 平井氏は当初、上述した2つの懸念事項を理由にEIP-867に対する否定的なコメント寄せました。ただし平井氏はその後の議論を経て、イーサリアムの哲学に反するという①の懸念事項については解釈を無視することで解決できるとしました。しかし、②の刑法への抵触については無視できないとしました。 平井氏が否定的なコメントを寄せる一方、イーサリアムのコミュニティマネジメント及びParityのテクニカルコミュニケーションを担当しているアフリ氏は、今回のERPの提案を強く支持しています。 そして、アフリ氏はTwitter上にて、日本という一つの国の法律に抵触する恐れがあるという理由で、イーサリアムに有用な提案が拒否されることは、イーサリアムコミュニティで起こるべきではないという旨の意見を表明し、平井氏がEIP Editorを辞任することを呼びかけました。 平井氏はこれに応答し、もし平井氏自身が辞任したとしても、それは後続のEIP Editorが刑法を無視することになるだけだという意見を表明しました。結果として、その10時間後にEIP Editorを辞任するに至りました。 各国の規制と分散自治組織の対立 今回紹介したEIP-867に関する議論は、イーサリアムにて大きな問題となっている盗難・凍結された資金の回収に関するものでした。しかしここから、イーサリアムと言う分散型システムを開発・推進するコミュニティが実際に存在することによって発生する、日本の法規制との対立構造が浮き彫りになりました。 公開されたブロックチェーンによって作られるシステムは、一般的に国などの従来の枠組みを超えた分散自治的な特徴を持っています。しかし、そのコミュニティに参加する人々は、何処かしらの国籍を持ち、自国の法規制に束縛されます。 今後ブロックチェーンをベースとした分散自治的な組織が更に拡大するでしょう。そして、そこで発生する従来の国や政府などの枠組みによる規制との対立をどのように解決していくのかは、分散自治組織を現実社会で利用する上で非常に重要な視点となるでしょう。
イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

2018/02/28 at 7:41 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。 本記事では2本連載にて前半ではこの提案の内容について、後半でこれにまつわる議論や出来事を整理して解説していきます。 ERCとEIPについて ERCとして公開された技術仕様に関する文章は、まず単なる問題提起からスタートします。提案された問題や技術が重要であれば議論が進み、最終的にはEIP(Ethereum Improvement Proposals)として採択されます。 EIP採択までの過程には、Draft(検討段階)→Accepted(承認済み段階)といったステータス(状態)があります。AcceptedされたEIPは最終的にまとめられ、イーサリアムの仕様として正式に採用(Final)されることになります。採用されたものは、イーサリアムの公式なアップデートとしてネットワーク上のクライアントに組み込まれていきます。 イーサリアムのバージョンアップや仕様変更などは、全てこのプロセスを経て行われることになっています。この一連のプロセスの解説については本メディアの過去の記事で解説しております。 EIP-867の概要について EIP-867は前述した通り、ICOなどによって調達したETHがハッキング被害やコードの不備などによって意図せず盗難・凍結した際に、被害者が資金を取り戻すリクエスト(ERP: Ethereum Recovery Proposals)を行い、これが承認された際にその資金が取り戻せる方法を標準化しようと試みた提案です。 これは2017年2月2日に、Musiconomiの開発者であるDan Phifer氏、そしてTapTrustの開発者であるJames Levy氏、Reuben Youngblom氏によって提案されました。 過去の被害と対処例 この提案が行われた背景には、過去に多発したICOで調達した資金の盗難・凍結があります。代表的な例として、The DAOでのハッキングやマルチシグウォレットサービスParityでのバグによる被害が挙げられます。 The DAO The DAOは非常に大きな注目を浴び、短期間で1億米ドル以上の資金を調達し、クラウドファンディングによる史上最高記録を塗り替えました。しかし調達直後に致命的なコードのバグによって、ハッキングの被害に遭い8000万米ドル相当の資金を盗難されました。 これはイーサリアム自体にとってもその価値を下げる大きな問題であった為に、イーサリアム自体がハードフォークし、このハッキングを無かったことにし、資金を元のウォレットに戻すという対応が取られました。最終的に、The DAOはこの対処によって盗難した資金を取り戻すことに成功しました。 Parity 次にParityの例について見てみましょう。 Parityは、スマートコントラクト上で実行されるウォレットサービスです。このParityの2017年7月20日にリリースされたバージョンにて、あるバグが報告されました。 このバグは、ある操作で通常のウォレットがマルチシグウォレットに意図せず変更されてしまい、この際にウォレットを開けるために必要な秘密鍵が資金と共にウォレットの中に保存されてしまうというものでした。 これはある部屋に入るために必要な鍵が部屋の中にある言わば”閉じこもり状態”であり、このマルチシグウォレットの中に保管されていたETHは事実上凍結されて、誰も移動することができなくなってしまうものでした。 プライベートブロックチェーンとパブリックブロックチェーンをリンクさせるというアイディアで、ICOにて1億4000米ドルを調達したPolkadotもこの被害にあっており、その調達資金のうちの60%が影響を受けているとされています。 Unfortunately, our multi-sig is among those frozen. @ParityTech is working on the situation and will provide updates when available. — Polkadot (@polkadotnetwork) 2017年11月7日 EIP-867の提案者であるDan氏が、ICOを行った音楽系のサービスMisiconomiも被害を受けています。そして昨今このような被害報告が急増しています。しかし、それに対する救済措置は殆ど行われていないのが現状です。むしろThe DAOで行われたハードフォークは、イーサリアム開発者の全面協力による特例的な対応であったと言えるでしょう。 そこで資金盗難・流出が発生した際に、大規模なハードフォークを行わずに資金回収をする方法がEIP-867で具体的に提案されました。 EIP-867で提案された資金回収方法 この提案では、実際に起こったParityの事件に限らず、ハッキングやコードの不備など様々な原因によって、あるウォレットからの資金が意図せず盗難・凍結した場合に、これを取り戻す方法が示されています。ここではある誤送金の例を用いて資金を取り戻すまでの一連の流れを解説します。 あるICOプロジェクトにてプロジェクト責任者が、誤ってテストネット(プログラムの評価や動作確認に使用する実際の金銭価値の無いネットワーク)で作成した振込先のアドレスをホームページ上に掲載した場合を考えます。 このアドレスはメインネット(金銭価値がある本物のネットワーク)でも有効ではありますが、秘密鍵はテストネットのものとは異なるために、この責任者はここに振り込まれた資金を利用することはできません。 問題が発覚した時には既に100人の投資家によってこの間違ったアドレスに500ETHが送金され、この500ETHは実質的に凍結されてしまいました。 ここでこの責任者は凍結した資金を解除するリクエストERP(Ethereum Recovery Proposals)によって、500ETHを投資家の元のアドレスに戻すような送金をすることを試みます。 まず責任者は、ERPの提案者としてイーサリアムのEIPコミュニティに、ERPの原案をEIP-xxx(xxxには提案番号が入る)として投稿します。 ERPの原案の中身 ERP原案には主に以下の内容が含まれています。 Verification script(検証コード) Verification scriptとは、イーサリアムのブロックチェーン上に存在するデータなどの事実を使って、State Change Actionsによって凍結資金の解除を実行するかどうかを決定する検証を行うコードです。 検証コードに具体的に記述された条件が満たされた場合に、検証コードはイーサリアムクライアントが実行できる形式のState Change Objectを生成して、凍結資金解除のトランザクションを生成します。 ここでは検証コードの例として、 ブロック番号○○~xxまでの取引にて誤ってメインネット上のテストネット用アドレスに500ETHが送金されたこと テストネット上でのこのアドレスには確かにICOプロジェクトのスマートコントラクトが実装されていたこと(つまり確立論的にメインネット上にこのアドレスの所有者は存在し得ないこと) 上記の全てが真実である場合には全ての送金者に投資されたイーサリアムを返却するState Change Objectを生成する と言った内容が書いてあるとします。 State Change Object これはイーサリアムネットワークのクライアントによって実行されるファイルの標準形式です。 この中には、ERPの番号(ERP id)や変更を要するブロック番号(Target Block)、そして検証コードを実行した際のブロック高(sourceBlock)と検証コードのバージョン(version)に加えて、資金返還を行うトランザクションがState Change Actionsとして記述されます。 State Change Actions この中には送金元のアドレス(凍結資金が保管されているアドレス)と送金先のアドレス(合計500ETHを送金した100人のアドレス)と返金するべき金額など、トランザクションの情報が具体的に記載されます。 (ERPの構造) ERPが承認されるまでの流れ EIPコミュニティに投稿されたERP原案は、以下の2つの立場の人たちからのフィードバックを受け、最後にEIP編集者の承認を受けます。 この資金凍結の関係者 プロジェクト関係者や実際に送金を行った投資家などがあたります。 特に被害に遭った投資家は、ERP原案のState Change Actionの中に確かに振り込んだ金額のETHが自分のアドレスに戻るようなコードが書かれているかを確認し、何かしらの誤りがあればコミュニティ上で指摘することができます。 非関係者 この資金凍結に関係が無い立場の人間が、検証コードに書かれている内容などが正しく実際に発生した事を記述できているか、これが実行された際に正しい資金凍結の解除がされるのかを判断します。これは裁判で言う陪審員や裁判官の役割に近いでしょう。 EIP編集者(EIP Editorship)による承認 フィードバックの期間は最低でも30日程度が必要だと述べられています。このフィードバック作業は、公開にて行われコミュニティ上では色々な議論が巻き起こるはずです。そして最終的にEIPの編集者が、コミュニティでの議論内容を踏まえてこのERPの提案を承認(Accept)するかを決定します。 ここで承認された提案はEIP可決案となり、公式なイーサリアムのアップデートとしてイーサリアムネットワークに拡散されることになります。 (ERP承認までの流れ) ERP承認から資金凍結解除までの流れ クライアントノードに伝わったERP可決案は、それぞれのクライアントノードで実行されていきます。まず検証コードが実行され、この時確かに検証内容が正しいと判断された場合には、State Change Actionsを含むState Change Objectを生成し、実際に資金凍結解除のトランザクションがイーサリアムネットワーク上に書き込まれていきます。 通常のトランザクション同様に、この凍結解除処理トランザクションも一定の時間が経過すれば有効となり、無事凍結した資金は送金者の元に戻っていくことになります。 (可決されたERP案はクライアントノードにて実行される) 以上がEIP-867で提案された凍結されたETHの取り戻しに関する仕組みになります。しかし凍結資金の取り戻しは非常にセンシティブな問題であり、議論が間違った方向に進めば誤って人の資金を不正に送金するツールになってしまう可能性も孕んでいます。後半の記事ではこの様なEIP-867に関して巻き起こっている様々な議論について解説していきます。
仮想通貨イーサリアムの技術標準 ERCとは何か?ERC-20,223,721の違い

仮想通貨イーサリアムの技術標準 ERCとは何か?ERC-20,223,721の違い

2018/02/01 at 6:58 PM 0 comments
ERCとは?なぜ必要? 市場規模第2位の仮想通貨イーサリアム、そのイーサリアムベースのトークンに関わり始めると、”ERC”や”ERC-20”といった言葉を耳にする機会が多いかと思います。今回の記事では、このERCやERC-20(ERC-223, ERC-721含む)について解説します。本記事を読めば、ERCとは何なのか?またERC-20/ERC-223/ERC-721のそれぞれの違いは何か?といった点について理解することができるでしょう。 インターネットの仕様は誰が決めてきたか?IETFとRFC ERCについて話す前に、インターネットの技術仕様がどのようにして決められているかについて説明します。インターネットの技術仕様の成り立ちを理解することで、より良くERCについて知識を深められます。 さて、今、みなさんが使っているインターネットですが、どうして異なるOSのコンピュータを、誰もがどこでも同じように使えて、相互に通信できるのでしょうか。ここから話を進めていきましょう。 理由の一つに、全員が共通の技術を使っている、ということがあげられます。インターネットは様々な技術の集合体です。しかし、もしもインターネットを構成する一つ一つの技術が、コンピュータや国や地域ごとに異なっていたら、相互接続し利用することは困難でしょう。 今では考えられませんが、昔は異なるOSのコンピュータ間でのデータ通信はできませんでした。異なるOSのコンピュータは、異なる仕組みや技術で動いていたからです。この問題を解決するために、アメリカのいくつかの大学によって結成されたのが「Networking Working Group」です。それは1969年の夏のことでした。 そして1986年、この活動はIETF(Internet Enginnering Taks Force)に引き継がれることとなりました。 インターネットに関連して広く公開されるべき技術は、このIETFへ提唱&議論されることになります。最終的に承認された技術仕様は、RFC(Request For Comments)という名前で文章化され、インターネット上で誰もが参照できるようになります。 参照:IETF | RFCs トークンの技術仕様は誰が決める?EIPとERC ここまでIETF/RFCに関して話してきましたが、ここから先はイーサリアムベースのトークンに関する、技術仕様を決定する方法について説明します。 ERCとは? ビットコインやイーサリアムをはじめとするブロックチェーン技術は、まだまだ歴史が浅く、誕生して10年すら経過していません。しかしブロックチェーン技術は日進月歩のスピードで、日々めまぐるしく開発が進められています。 この状況はまさに、インターネット技術の開発が始まった1960~1980年代と同じと言えるでしょう。ブロックチェーン技術の開発は、インターネット技術の開発から学ぶべきことが多くあり、その一つに技術の標準化があります。 特にイーサリアムは、ブロックチェーン上で動作するアプリケーションのプラットフォームとなることを目指して開発を続けてきていますので、技術の標準化は重要なテーマです。最近はICOなどを通じて、多くのイーサリアムベースのトークンが発行されています。 もしこのトークンがイーサリアム上で動作するにも関わらず、それぞれ別々の技術仕様で設計されていたらどうなるでしょう?取引所やウォレットの開発などが困難になることが想像できると思います。共通のトークン仕様を策定し、それに従う方が、イーサリアムコミュニティにとってもユーザーにとっても大きなメリットがあるでしょう。 実際にイーサリアム・コミュニティは、技術仕様の標準化に対して非常に積極的です。そしてイーサリアム・コミュニティでの標準化の流れによって生み出されたのがERC(Ethereum Request For Comments)です。 ERCは、イーサリアム上における技術仕様を文章化したもので、これは先ほど述べたIETFにおけるRFCに相当します。ERCもRFCも”Request For Comments”  ということで、広くコメントを集め、オープンに技術を発展させていく姿勢が伺えます。 EIP採択までの過程 ERCとして公開された技術仕様に関する文章は、まず単なる問題提起からスタートします。提案された問題や技術が重要であれば議論が進み、最終的にはEIP(Ethereum Improvement Proposals)として採択されます。EIP採択までの過程には、Draft(検討段階)→Accepted(承認済み段階)といったステータス(状態)があります。AcceptedされたEIPは最終的にまとめられ、イーサリアムの仕様として正式に採用(Final)されることになります。 例えば20番目に提案されたERC文章は、トークン仕様について議論されたもので、 ERC-20と呼ばれています。このERC-20はトークンの共通仕様を決める重要なものであったため、EIP20として採択(Final)されています。 このEIP20は、Github上にて公開されていますので、興味のある方は覗いてみると良いでしょう。EIP-20-Token-Standard またEIP/ERCでは、トークン仕様だけでなく、イーサリアムに関する様々な技術 - 例えば、EIP-669 ディフィカルティボム調整 - が議論されていることもわかるでしょう。 ERC-20/ERC-223/ERC-721とは ここまで読んでいただいた方は、ERCとは何か、また、ERCとERC-20の違いは何か、といった点に関して理解できたと思います。ここからは、数多く存在するトークン仕様の中で、実際に広く使われているERC-20, ERC-223, ERC-721について解説します。 ERC-20 ERC-20は、2015年11月19日にERCに提案されたトークン技術仕様です。ERC-20が採択されたことにより、イーサリアム上で発行される多くのトークンはこれに従うようになりました。結果として、異なるトークンでも同一ウォレット上で残高一覧を確認できたり、取引所はトークンのアドレスだけで、トークンを上場させることができるようになりました。 ERC-20の致命的欠陥 ERC-20は非常に成功し、広く使われているトークン仕様と言えるのですが、一つ重大な欠点があります。それは、ERC-20準拠のトークンをユーザーの通常のアドレスではなく、コントラクトアドレスに送金してもトランザクションが承認されてしまい、送金したトークンが取り出せなくなってしまう事です。 誤送金されたトークンは二度と取り出すことができなくなってしまい、事実上消滅することになるので注意が必要です。実際に失われたトークンの例が以下になります。日本円換算で3.6億円程度が失われているようです。 「How much ERC20 tokens are currently lost (27 Dec, 2017): QTUM, $1,204,273 lost. watch on Etherscan EOS, $1,015,131 lost. watch on Etherscan GNT, $249,627 lost. watch on Etherscan STORJ, $217,477 lost. watch on Etherscan Tronix , $201,232 lost. watch on Etherscan DGD, $151,826 lost. watch on Etherscan OMG, $149,941 lost. watch on Etherscan STORJ, $102,560 lost. watch on Etherscan」 (引用:https://github.com/ethereum/EIPs/issues/223) ERC-223 ERC-223は、ERC-20の問題を解決した上位互換の新規格で、2017年3月5日にERCに提案されました。223番目のERC提案ですので、ERC-223と呼ばれています。ERC-20と同様にGithub上で議論がなされています。現段階ではERC-223は”Draft”のステータスですので、まだEthereumで正式に承認されている訳ではありません。 参照:ERC 223 token standard token Fallbackとは? ERC-223の重要な機能の一つが”token Fallback”です。これはERC-20の欠陥であると上述した、誤送金を防ぐために実装されています。具体的には、コントラクトアドレス宛にコントラクトに対応していないトークンの送金がされた場合、元の送り主にトークンを送金し返します。一方で、コントラクトアドレス宛にコントラクトに対応したトークンが送金された場合、通常の処理をします。この機能を実装することで事実上、ERC-20トークンであったような誤送金を無くすことができます。 ERC-721 ERC-721は、2017年9月20日に提案された、ERC-20, ERC-223とは異なる方向にトークンを発展させる技術仕様です。注目すべき特徴はNFT(Non-Fungible Token)と呼ばれるトークン仕様を持っている点です。”Fungibility”とは”代替可能性”という意味です。つまり”Non-Fungible Token”とは、”代替不可能なトークン”と言えるでしょう。 Non-Fungible Tokenとは? Non-Fungible Tokenの説明に移る前に、まずは理解を深めるために、身近なFungibleの例を考えてみましょう。一番簡単な例としては、通貨が挙げられます。みなさんのお財布の中の1000円札は、隣の人のお財布の中の1000円札と基本的には同じです(プレミアがついていなければ)。そしてどこでもその1000円を使って、1000円分の買い物をすることができます。このように通貨の果たす機能や価値は同等ですので、”通貨はFungible”であると言えます。 一方で、Non-Fungibleな例としては、オリジナリティを持ったものが挙げられます。美術作品や、ゲーム内であなたが一生懸命育てたキャラクターなど、それ自体にオリジナリティやアイデンティティがあるものは代替不可能であると言えます。この概念をトークンに拡張すると”代替不可能なトークン”にたどり着くことができます。つまり「それぞれのトークンに独自の価値と保有者が結び付けられている」と言えるでしょう。 NFTの応用事例 このERC-721に準拠したトークンを用いて、昨年大ブレイクしたのがCrypto Kittes(クリプトキティーズ)です。Crypto Kittesは、イーサリアム上で「仮想の子猫」を育てるゲームです。ユーザーの育てた一匹、一匹の子猫がそれぞれアイデンティティ(猫の外見や性格など)を持っていて、飼育者に紐づけられています。まさにERC-721のNFTの概念と一致していることがわかるでしょう。 ERC-721の今後 ERC-721によって、イーサリアム上では代替不可能な物をトークン化して扱うことができるようになりました。今後は、このNFTを応用した例が増えてくるかと思います。 例えば、ゲーム内のキャラクターなどは、Crypto Kittesと同じぐオリジナリティを持つ場合が多いため、NFTが活用される機会があるでしょう。しかし、このERC-721はGithub上のERCにおいて議論の真っ最中であり、ERC-223と同じく”Draft”のステータスです。まだイーサリアムに正式に承認された訳ではないことに注意して、今後の動向を見守りましょう。 ERC: Non-fungible Token Standard