「ERC725 ERC735」Ethereumベースの分散型IDの標準

- 2020年2月10日
更新日： 2020年7月27日

IDを所有者の手に返し、シェアリングエコノミーをはじめさまざまなP2P型、ブロックチェーンベースの基盤となりうる分散型IDについては古くから議論が重ねられてきました。本記事では、Ethereumベースの分散型IDの標準ERC725とERC735について解説します。

1 中央集権型IDと分散型ID
2 ERC725と関連する標準
3 ERC725とERC735のしくみ
4 公開されている実装例
5 今後の展望

中央集権型IDと分散型ID

分散型ID（Decentralized ID、DID）について考える上で、まず、その対極にある現在私たちが使用している中央集権型IDについて見てみましょう。

現実世界の身近なIDとしてパスポートがあります。たとえば、日本では出生登録をすると、戸籍が作られ、居住者の場合は住民登録がされます。パスポートを申請する際には戸籍謄本や住民票の写し、本人確認書類を提出します。これらの情報をもとに日本国民に対して外務省がパスポートを発行します。パスポートは中央集権的に外務省が管理するIDと言えます。

インターネット上のサービスを利用する際に使うIDも中央集権型のIDです。ほとんどの人が何らかのサービス利用開始時にメールアドレスとアカウント名、パスワードを登録して、IDを発行された経験があることでしょう。金融サービスなど、KYCが必要なサービスでは、さらにパスポートや運転免許証など、公的機関が発行する証明書を提出します。IDの保有者が提出した情報は、IDの発行元によって中央集権的に管理されます。私たちは中央集権型のIDやそれを使ったサービスに慣れ親しみ、確かに利便性など利点もありますが、運営の不備により大規模な情報漏洩が起きたり、ユーザーが意図しない形で情報が利用されたりすることがあります。

中央集権型IDが広く使われている中、分散型IDが提案される背景には、中央集権的なサービスへの不信感から、ユーザー自身の手にIDを取り戻そうという特有の思想があります。また、分散型IDは、ユーザーがIDを自身の手に取り戻せるというだけでなく、ユーザー同士が本人確認をしあうといった用途でも利用できます。P2P型、ブロックチェーンベースのシェアリングエコノミーで、知らない人同士がものやサービスをシェアする上で本人確認は欠かせません。そのための標準ができつつあることは、今後のブロックチェーンベースのシェアリングエコノミーが広がりに寄与することでしょう。

このように現状を大きく変えうる分散型IDの構想は新しいものではなく、本ブログでもさまざまなブロックチェーンベースの分散型IDを取り上げてきました。本記事で解説するEthereum上の分散型IDの標準「ERC725」もすでに2017年10月の時点で提案されていました。ERC725はFabian Vogelsteller氏とTyler Yasaka氏の共同提案で、ERC725と密接に関連するERC735はVogelsteller氏の提案です。Vogelsteller氏はERC20の共同提案者としても知られ、web3.jsの開発者でもあります。ERC725 Allianceが中心になり、ERC725に関する議論や採用を進めています。

分散型IDのための一連のERCを一言で説明すると、第三者または自分自身が発行するクレーム（claim）と呼ばれる信用情報を自身のIDに紐付け、IDの証明に使う仕組みの標準といえます。

続いてERC725と関連する標準について詳しくみていきましょう。

ERC725と関連する標準

ERC725には、バージョン1とバージョン2があり、ERC725のバージョン2が最新のERC725に、ERC725のバージョン1は鍵管理のための標準として今後ERC734に移行されます。ERC725、ERC734、ERC735のそれぞれの概要は以下の通りです：

ERC725 Proxy Account
- ERC 725 バージョン2
- ERC 725 バージョン1

ERC734 Key Manager（2017年10月に一度クローズされ、2019年2月に再びオープン）
ERC735 Claim Holder（ERC725 バージョン1に対応）

ERC725はバージョン2のドラフトが書かれ始めていますが、ERC735はERC725のバージョン1に対応していることもあり、本記事ではERC725のバージョン1をもとにERC725とERC735について解説します。

ERC725とERC735のしくみ

分散型IDの考え方は独特で、はじめにERC725とERC735で実現される分散型IDの全容を押さえておくと理解しやすいです。もっともシンプルな例を見てみましょう。

IDを利用したいと考える人は、ERC725に基づいて実装された自身のIDを表すスマートコントラクトをデプロイします。続いて、クレームと呼ばれる信用情報を、クレーム発行者に署名・発行してもらい、IDに紐付けます。クレーム発行者は信頼のおける第三者機関が想定されます。ウェブ開発に慣れた人であれば、クレームをクレデンシャルと読み替えるとわかりやすいかもしれません。IDの保有者はクレームをサービスに提示して、サービス側でクレームの署名を検証し、問題がなければサービスを利用できるようになります。

画像： ERC725/ERC735に準拠した分散型ID利用の概要

IDを表すスマートコントラクトはIDの保有者が所有するもので、中央集権的に管理されるものではありません。IDの「保有者」と書きましたが、人のほか、組織、機械といった主体であることも想定されています。IDはいくつでもクレームを持つことができ、IDの所有者とクレームを発行したクレーム発行者は適宜クレームを削除できます。また、IDの保有者自身が自分にクレームを発行することもできます。

このようなEthereumの分散型IDの仕組みについて、ERC725がIDのインターフェイスを、ERC735がクレームの構造や取り扱いを定義しているというわけです。

Ethereumの分散型IDの仕組みの概要を把握したところで、実際にERC725とERC735の中身を見てみましょう。ERC725とERC735に準拠して分散型IDを実装する場合には、以下のインターフェイスを継承してイベントやメソッドの中身を記述していくことになります。

ERC725の定義

pragma solidity ^0.5.4;

interface ERC725 {
    // 関連するイベントの定義
    // ・・・

    // address public owner;

    // IDの所有者の変更、データの設定・取得、外部スマートコントラクトの実行
    function changeOwner(address _owner) external;
    function getData(bytes32 _key) external view returns (bytes32 _value);
    function setData(bytes32 _key, bytes32 _value) external;
    function execute(uint256 _operationType, address _to, uint256 _value, bytes calldata _data) external;
}

ERC725で定義されたインターフェースには、一見するとERC735との関連が見当たりませんが、getData関数とsetData関数とあるように、ERC725では任意の情報をキーと値の組合せで持ち、ここにIDの所有者の情報やクレームを保持します。execute関数で、ほかのスマートコントラクトの実行、ETHの転送といった処理を実行します。

ERC735の定義

pragma solidity ^0.4.18;

contract ERC735 {

    // 関連するイベントの定義
    // ・・・
 
    // クレームの構造
    struct Claim {
        uint256 topic;
        uint256 scheme;
        address issuer; // msg.sender
        bytes signature; // this.address + topic + data
        bytes data;
        string uri;
    }

    // クレームの追加、取得、変更、削除する関数の定義
    // ・・・
}

ERC735では、クレームの構造や、クレームの取り扱いに関する関数やイベントが定義されています。クレームの構造についても記載があり、何に関する情報なのか（1: 生体認証、2: 住居など今後定義が進む予定）、どのように処理すべきか、発行者、発行者による署名といった情報が含まれます。分散型IDの実装にあたっては、ClaimHolder（クレームの所有者）といったコントラクトでERC735を継承し、関数やイベントの中身を実装することになります。

公開されている実装例

ERC725とERC735を利用した実際の実装を見てみたいという人は、ERC725 Allaianceのメンバーで、分散マーケットプレイス構築を目指すアメリカのスタートアップOrigin Protocolがデモとコードを公開しています。スマートコントラクトはコンパクトで、コントラクトをどのように継承し、クレームを取り扱えばよいかがわかります。

また、ドイツのRegTech企業FractalのCTO Júlio Santos氏は、ブログでコードを示しながらICO参加者がクレームを取得してICOに参加する例を解説しています。FractalもERC725 Allianceのメンバーです。

First impressions with ERC 725 and ERC 735 — identity and claims

今後の展望

ERC725、ERC735については、ERC725のバージョン2に対応する形で今後はERC734も含めより詳細な定義が進んでいくことが期待されます。標準の策定と合わせて、一般の利用者がスマートコントラクトやデプロイといった技術的な部分を意識せずにIDを利用できるインターフェイスの開発や、現在完全に自己責任の鍵管理をどう使いやすいものにしていくのかといった課題もあります。

一方で、分散型IDにはさまざまな可能性があります。本ブログでも取り上げたブロックチェーンと教育や医療についてとりあげましたが、これらの分野の記録は保有者が自身の手元に置いておきたい情報です。クレーム発行者を学術機関や医療機関として学位証明や医療記録を用途別にIDに記録していくこともできるでしょう。ブロックチェーンベースのシェアリングエコノミーにおいても分散型IDは欠かせない要素で、知らない人同士の本人確認に使えるほか、ERC725、ERC735では誰もがクレームを発行できることから、ユーザー同士の評価に基づく信用基盤を作ることも考えられます。

中央集権的な機関の証明によらない新しい信用基盤は、IDを持たない人たちの救済につながるかもしれません。世界には公的な証明書を取得できない人が少なくなく、こうした人たちについては、手に入る情報をもとにブートストラップ的にIDを作っていく必要があります。すでにブロックチェーンを使ってすべての人にIDを提供しようという取り組みは存在し、本ブログでもID2020やBitnationといった事例を紹介しました。今後、ERC725、ERC735を利用したソリューションが出てくる可能性があります。

ERC725と関連する標準の採用までにはまだ時間がかかりそうですが、さまざまな応用が考えられ、これまでにない信用基盤を構築できる可能性があるという点から、大きな期待を持てそうです。ノン・ファンジブル・トークンの標準ERC721は、議論が行われている段階から利用が進み、採択にいたりました。ERC725と関連する標準も同様の流れで採択にこぎつけるのかもしれません。ERC725と関連する標準の今後に注目していきたいところです。