ERC725/735の仕組み 2

  • 2020.01.24
  • 2020.01.24
  • DeFi
ERC725/735の仕組み 2

はじめに


本連載では、ブロックチェーンを活用したDID(Decentralized Identity及びDecentralized ID)技術の概要と仕組み、現状について概観します。あまり表立って議論のテーマになることはないDIDですが、ブロックチェーンの金融エコシステムやWeb3の発展には欠かせない技術です。今回は2回目の記事として「ERC725/735の仕組み 2」をを説明していきます。

Claimの作成の仕方


Claimの作成は、基本的に上記で説明したClaimに含められるデータを用意します。claim issuer(サービスプロバイダ)は自身のアカウントアドレスを含めて、特定の文字列をハッシュ化することで署名を作成し、その署名(signature)をClaimに加えます。署名の詳しい作成手順は以下になります。この署名を使って、ユーザーからClaimを受け取った別のサービスプロバイダは、Claimを検証します。ERC735のClaimは、検証可能なことから「Verifiable Claim(検証可能なClaim)」 と呼ばれます。
console.log("Signing FractalId's KYC claim...");

  var hexedData = web3.utils.asciiToHex("Yea no, this guy is totes legit");
  var hashedDataToSign = web3.utils.soliditySha3(
    investorClaimHolder.options.address,
    CLAIM_TYPES.KYC,
    hexedData,
  );
  var signature = await web3.eth.sign(hashedDataToSign, fractalIdClaimAccount);

出典 : https://github.com/trustfractal/erc725/tree/master/contracts

利用の仕方


ERC725/ERC735を利用した、KYCを必要とするクラウドセールに参加するためのフローをみていきます。

実装元 : https://github.com/trustfractal/erc725/tree/master/contracts

参考

https://medium.com/@kctheservant/a-companion-guide-to-first-impressions-with-erc-725-and-erc-735-identity-and-claims-part-1-51b53603cfc0

https://medium.com/@kctheservant/a-companion-guide-to-first-impressions-with-erc-725-and-erc-735-identity-and-claims-part-2-cdb1e434b382

https://medium.com/@kctheservant/a-companion-guide-to-first-impressions-with-erc-725-and-erc-735-identity-and-claims-part-3-41216b5a9e97

まずここで、登場する関係者を紹介します。
  • KYCプロバイダー : 投資家のKYCを実施して、「KYC claim」を発行する主体。
  • 会社A : クラウドセールを実施して、トークンを発行して資金調達を行う主体。
  • 投資家 : 会社Aのクラウドセールに参加して、会社Aのトークンを購入したいと思っている主体。

以下はクラウドセールの簡単なフローになります。


  1. 投資家は必要な情報をKYCプロバイダーに渡し、KYCの申請を行います。
  2. KYCプロバイダは、投資家に「KYC Claim」を発行します。
  3. 投資家は、「KYC Claim」を使用して、会社Aが発行するトークンを購入します。
  4. 会社Aは、投資家の「KYC Claim」を検証して、投資家にトークンを発行します。

このクラウドセールの中で、どのようにERC725/ERC735が機能するのか詳細をみていきます。

まずERC725(インタフェース)とERC735(インターフェース)を継承・実装した「Claim Holder Contract」を投資家とKYCプロバイダーは、それぞれデプロイする必要があります。会社Aは「VeryGoodCrowdsale Contract」と「VeryGoodCoin Contract」をデプロイします。



KYCプロバイダーは、「Management Key」と「Claim Signer Key」を、投資家は、「Management Key」を会社AはETHを受け取るためのEOAのアドレスをそれぞれ持ちます。

以下では、詳細を説明していきます。


  1. KYCプロバイダは、「Management Key」(公開鍵アドレス)で、「Claim Holder Contract」をデプロイします。その後、「Claim Signer Key」(公開鍵アドレス)をそのコントラクトに追加します。
  2. 投資家は、「Management Key」(公開鍵アドレス)で、「Claim Holder Contract」をデプロイします。
  3. オフチェーン上で、投資家はKYCプロバイダに必要な情報を渡し、KYCをクリアします。KYCプロバイダは、オフチェーン上で「Claim Signer Key」を使って、署名を行い投資家の「KYC Claim」を作成します。
  4. 投資家は、「Management Key」でKYCプロバイダから受け取った「KYC Claim」を「addClaim(…)」を実行して、「Claim Holder Contract」に追加します。


  1. 会社Aはクラウドセールコントラクトをデプロイします。このコントラクトは「Claim Holder Contract」を継承していて、関数checkClaim(….)を実装しています。投資家の「KYC Claim」を検証するために、デプロイ時にKYC プロバイダの「Claim Holder Contract」のアドレスをコンストラクトの引数として持たせています。
  2. 投資家は、トークンを購入します。「Claim Holder Contract」(ERC725の関数execute(…)を実行する)を経由して、プロキシ方式でクラウドセールコントラクトの関数buyTokens(…)を実行します。同時にETHを送金します。
  3. buyTokens(…)が発動されると、実行者のClaimを検証する関数checkClaim(…)が発動され、検証に成功すると、投資家にトークンが発行されます。

利用例


ERC725/735を利用した事例にOrigin Protocolがあります。



Origin Protocolは、事業者がシェアリングエコノミー・サービスを構築できるミドルウェアに位置するプラットホームです。Origin Protocolでは、例えばUberやAirbnb、メルカリなどのようなサービスが複数形成されていくことが想定されますが、仮にプロトコルベースでIDや信用スコアを実装できれば、Origin Protocolで実装されたシェアリング・サービス間をユーザーが自由に行き来できることになります。

ですが、集権的にデータを収集・保存をOriginのようなWeb3のサービスが行なってしまっては元も子もないので、DID技術が必要になります。OriginはEthereumのスマートコントラクトで実装されたプラットホームなので、上述したERC725を活用しています。彼らのブログではデモも紹介しています。

参考

Origin Protocol

DIDの普及に向けた課題と今後の展望


非常に理想的な理念が打ち立てられ、大企業からスタートアップ、ブロックチェーンという最新技術まで巻き込み開発が進められているDIDですが、当然課題もいくつか存在します。

まず、どこまで非中央集権にこだわるのか、という議論が存在します。現在はまだ非中央集権的に信用を積み上げることができるサービスが少ない(ほぼない)ので、幾分かは国や企業によって管理される情報を用いています。今後は少しずつ分散を志向すると見られますが、依然として一部集権的な色は残り続けるでしょう。

そして技術的な課題も残っています。例えば、パスワードや秘密鍵を失ってしまった場合のリスクや、その予防策に関する実装です。

そして、DIDはDIDがそれ一つあっても、広がりはしない、コミュニティ・ドリブンなインフラサービスです。したがって、Originや金融領域において、特定のキラーアプリと共に普及すると予想できます。

免責事項


本記事に掲載されている記事の内容につきましては、正しい情報を提供することに務めてはおりますが、提供している記事の内容及び参考資料からいかなる損失や損害などの被害が発生したとしても、弊社では責任を負いかねます。実施される際には、法律事務所にご相談ください。

技術・サービス・実装方法等のレビュー、その他解説・分析・意見につきましてはblock-chani.jp運営者の個人的見解です。正確性・正当性を保証するものではありません。本記事掲載の記事内容のご利用は読者様個人の判断により自己責任でお願いいたします。

ブロックチェーン学習に最適の書籍の紹介


図解即戦力 ブロックチェーンのしくみと開発がこれ1冊でしっかりわかる教科書

本書は、ブロックチェーン技術に興味を持ったエンジニアや、その仕組みを学び、自分の仕事に活かしたいビジネスパーソンを対象にして、ブロックチェーンのコア技術とネットワーク維持の仕組みを平易な言葉で解説しています。この本を読んだうえで、実際にコードを書くような専門書、ブロックチェーンビジネスの解説書を読むことで、理解度が飛躍的に高まるでしょう。(はじめにより)

会社紹介


弊社(コンセンサス・ベイス株式会社)は、2015年設立の国内で最も古いブロックチェーン専門企業です。これまでに、大手企業の顧客を中心に、日本トップクラスのブロックチェーンの開発・コンサルティング実績があります。ブロックチェーンに関わるビジネスコンサル・システム開発・教育・講演などご希望でしたら、お気軽にお問い合わせください。

会社ホームページ

https://www.consensus-base.com/
     

免責事項

本記事に掲載されている記事の内容につきましては、正しい情報を提供することに務めてはおりますが、提供している記事の内容及び参考資料からいかなる損失や損害などの被害が発生したとしても、弊社では責任を負いかねます。実施される際には、法律事務所にご相談ください。

技術・サービス・実装方法等のレビュー、その他解説・分析・意見につきましてはblock-chani.jp運営者の個人的見解です。正確性・正当性を保証するものではありません。本記事掲載の記事内容のご利用は読者様個人の判断により自己責任でお願いいたします。

     

コンセンサス・ベイス(株)とブロックチェーン事業を行なってみませんか?

当サイトを運営するコンセンサス・ベイス株式会社は、2015年設立の国内で最も古いブロックチェーン専門企業です。これまでに、大手企業の顧客を中心に、日本トップクラスのブロックチェーンの開発・コンサルティング実績があります。

ブロックチェーンに関わるビジネスコンサル・システム開発・教育・講演などご希望でしたら、お気軽にお問い合わせください。

     
     

ブロックチェーン学習に最適の書籍の紹介

図解即戦力 ブロックチェーンのしくみと開発がこれ1冊でしっかりわかる教科書

ブロックチェーン イーサリアムへの入り口 第二版 (ブロックチェーン技術書籍)

本書は、ブロックチェーン技術に興味を持ったエンジニアや、その仕組みを学び、自分の仕事に活かしたいビジネスパーソンを対象にして、ブロックチェーンのコア技術とネットワーク維持の仕組みを平易な言葉で解説しています。この本を読んだうえで、実際にコードを書くような専門書、ブロックチェーンビジネスの解説書を読むことで、理解度が飛躍的に高まるでしょう。(はじめにより)

DeFiカテゴリの最新記事