12月にハイパーレジャー東京ミートアップイベントに、インディシオが招待され、プレゼンテーションさせて頂きました。その時の要約をこちらに記します。

Trussted Data Ecosystemの仕組み 

この図式にあるように、Trussted Data Ecosystemは、

シームレスで効率的なデータエクスチェンジシステムです。Issuer, Credential Holder, Credential Verifierを含みます。どうして私たちがこのようなシステムを構築しているかというと、現在存在しているデータモデルは、信頼できないシステムだからです。

ToIP illustration of the Trust Diamond

インディシオがTrussted Data Ecosystemに取り組んでいる背景:アナログからデジタルへの歴史

<紀元前3200年前から1964年まで>私たちはアナログの世界で書類を郵送したり、持ち運んだりして書類をエクスチェンジしてました。

Notarity (公証人) から封を閉じられたスタンプ付きの封筒や郵便局で登録された書類など、持ってきた人がポケットに入ってた封筒を手渡したりしてきましたね。

<1964年からこれまで>信頼できる効率化されたプライバシーが保護されたハイブリットな世界が出来上がりましたが、便利になった分、たくさんの信頼を犠牲にしました。書類をスキャンしてアップロードしたり、デジタル化されたドキュメントやデータをEメールするようになり、効率は高まりましたが、トラストやプライバシーを失いました。Eメールを受け取ったり送ったりすることで中央集権型となり、便利にはなりましたが、送信や受信したEメールは、信頼やプライバシーを失いました。

<Decentralized Idneity(分散型ID)の世界>このような三つの要因 Trust, Efficiency, Privacyをオプティマイズすることで、効率を最大限にし、データエクスチェンジの際、分散型IDを利用することで、プライバシーを保護することが可能となりました。

アナログ vs. デジタル:プラスチックでできている免許証は、もし偽造された場合、もし例えば、プラスティックの免許証の一部の加工の仕方が一般に目にするものと違っていたり、都道府県が表記されていなかったりすると、これは偽物じゃないかと思うかと思います。このように、アナログの世界では物理的な変化があるとこのデータが本物か偽物かが判断できます。これが、デジタルの世界になると、デジタルIDが本物か偽物かどうかを判断するのには、物理的なプラスティックなカードではなくなるので、わかりにくくなりますが、Decentralized ID分散型IDの世界だとわかります。

Do not put a trust registry here

信頼性のあるモデル

信頼性はTrustedモデル(信頼性のあるモデル)に存在しています。こちらの図式にありますのが、Trustモデルのガバナンス(ステークホルダーとの信頼関係を築くための管理体制)です。

このガバナンスは、二つのフォームによって成り立っています。一つは、コードで書かれた暗号化された信頼と、署名を読み取りに行ったり、本当の情報を読みに行ったりします。

もう一つは、哲学的な信頼です。この図の右にあるお店のオーナーが、データが送られてくる機関または業者が、どの信頼できる機関であるかどうかを選んで決めさえすれば、このガバナンス内で、信頼されたデータを受け取ることができます。

データを受け取った時に、データが信頼された機関から送られてきたかどうか、このガバナンスで、Machine Reachableなやり方で実行されます。そして、お店のオーナーは、送られてきた情報が、信頼できる情報かどうかを判断します。

Do not put a trust registry here

<ビルディングブロック> *図式は、Cardeaプロジェクトで使われた説明図です。

インディシオで世界中のクライアントに使っているビルディングブロックは、オープンソースのものですので、全く同じものが誰にでもアクセスできます。一番下の部分にあるブロックにイミュータブルデータ(作成後にその状態を変えることのできないデータ)のブロックがあります。このブロックは、Issuer(発行者)のDecentralized Identifier(DID)が保存するためにあります。スキーマは、違った参加者の間で共有されるかもしれません。クレデンシャルの定義、基本的には、それぞれのフィールドのパブリックキーとなるものが、それぞれの Issuer(発行者)によって署名されます。レボケーション(取り消し)レジストリー情報は、最終的な確認を常に最新情報としてアップデートされています。テールファイルに続いているアキュムレーターやデルタ、これらの四つの基盤となるデータがパブリックレジャーに書かれます。これらの四つの基本となるデータが全体のシステムをサポートしています。またインディシオは、私たち自身でネットワークを運営しています。テストネット、デモネット、プロダクションネットワークです。ハイパーレジャーINDYベースのネットワークの中でも一番大きなネットワークです。5つの大陸に跨って、25のノードオペレータがいます。ノードオペレータは、ソフトウエアをアップデートしたり、プレミアムコードを書いたりしています。デモネットは、ネットワーク上でテストする方々のためにあります。そして、メインネットは、プロダクションユースケースのためです。他のネットワークとのやりとりは、世界中で行われており、ヨーロッパや、アメリカ、その他様々なところで使われております。顧客の様々な機能のタイプによって、例えば、政府によっては自身のプライベートネットワークが必要となり、決められた範囲内に情報が置かれていないといけない場合もありますし、その場合は、それぞれの地域で法律が違うので世界のネットワークでの運営は避けています。

このVerifiable Credentialの技術で面白い点は、Verifiable Credential が扱うデータ、PIIはパブリックレジャーに残らないことです。エンドユーザーがコントロールしています。そのためにプライバシーが守られているデザインで、コンプライアンスも保護されています。レジャーが使われるのは、データが正確なものかどうかを確かめるためだけに使われます。IDを発行したIssuerから署名されており、他の誰からも署名されてないのを確認されて、Holderに届きます。そして、誰か信用している人から署名されていることを確認します。Holderのウォレット(お財布)の中あるデータは、すでに同意されたものが保護されたまま、やりとりされます。

Do not put a trust registry here

<クリプトグラフィー暗号について>

ハイパーレジャーインディのエコシステム上で走っています。どのような暗号法による計算によって、実際に証明書が発行されているか、クリプトグラファーが143ものステップを一つ一つ説明してくれました。もしこのクリプトグラフィーに興味があって、詳細を見たい方、オンラインで、ドキュメンテーションが見れます。Issuerは、暗号ツールを使って署名したり、DIDやパブリックキーを使ったり、またはパブリックキーと同じようなものを使って、レジャーにおきます。署名されてきちんと処理された証明書がIssuerそしてHolderに届くように承認します。 ハイパーレジャーで使われている、ZKPスタイル、zero knowledge proofの仕組みによって、エンドユーザは、選別的情報開示またはpredicate proofs述語証明と呼ばれるやり方で、一部のフィールドを見えないようにしたり、または選んだフィールドだけを見えるようにした証明書を提示できます。例えば、年齢が18歳以上という規定があり、年齢が18歳以上かどうかだけを確認する場合は、体重や住所は必要ない情報ですので、開示する必要がないですよね。こういった必要な情報だけを開示する設定ができます。これらは、クリプトグラフィーの中でも重要な部分で、Camenisch-Lysyanskaya signature / CL signature と呼ばれる署名スタイルです。

Verifierは、ほとんどの情報をキャッシュできることです。空港の中など、インターネットのアクセスが限られている場所が多いと思います。Wifiのコネクションが悪いところでも、HolderとVerifierとまだやりとりできます。

<Cardeaプロジェクト>

病院などのメディカルIssuerがデータをHolderに渡し、そして、Holderは政府や航空会社の人たちに、空港などでワクチン接種の証明書や、PCR検査の結果などを見せます。みなさんはご存知かと思いますが、こういった状況の中では、いつも政府と医療関係者やそのコミュニティがうまく一緒に調和できるとは限らないんですよね。ですので、こういった状況では大変便利なツール・技術となります。なぜなら直接、政府と医療関係のシステムをインテグレーション しなくても、プライバシーを保護しながらデータを受け渡しできるからです。

私たちのクライアントの中には、ヨーロッパの顧客が多いです。彼らは、GDPRのレギュレーションの中で、ビジネスをしている会社ですので、プライバシー保護法には非常に敏感でPIIパーソナルデータの扱いに気をつけています。GDPRの違反で、多大な罰金を払っている会社の記事を新聞などでご覧になったかと思います。Verifierが、ビジネスに必要な扱わなければならない情報だけを扱うことで、コーポレーションにおいてはリーガルチーム、法務部やエグゼクティブにはかなり助かるツールなんですね。重要なのは、技術的な部分とビジネスやそのオペレーションの部分のバランスを取りながら、ソリューションを築いていくことです。それぞれの会社にとって、ビジネスチーム、リーガルチーム、マーケティングチーム全ての部署の人たちがハッピーに満足できるように進めていくことで、満足いく結果が生まれます。

Do not put a trust registry here

コードアーキテクチャ

基盤となるライブラリは前までは、ハイパーレジャーインディだけだったのですが、今はハイパーレジャーUrsaと分裂しました。なぜなら他のいくつものプロジェクトとも共有できるようになったからです。クリプトグラフィ・ライブラリに様々な面白いオプションができて、クリプトグラフィック暗号Suiteが可能になったからです。今では中国のアルゴリズムも含まれています。一部の方々は、どうしてユニバーサルに信頼されていないアルゴリズムを含まなければいけないんだろう、と思われる方がいるかと思います。けれども、クリプトグラフィックライブラリの違ったコンポーネントは、一部の国や地域にそったレギュレーションの必要条件に合わせなければなりません。ハイパーレジャーインディプロジェクトでは、cl signaturesに集中していたのですが、新しいシグネチャスタイルが査定されて、cryptographic suiteに付け加えられました。シンプルなシグネチャも付け加えられました。新しいsignatureスタイルは、シンプルな署名も扱えます。Jason LD Signatureでパッケージを署名することで、全てのデータを明らかにすることができます。フィールドは5つしかないのですが。ZKPスタイルのSignature署名は、意味がないのかもしれません。

そして、BBS Plusというのも査定されました。新しい署名タイプで、ハイパーレジャーウルサのライブラリに付け加えられました。これらはレイヤーが上の部分を利用することができます。

この左側にある緑の部分にあたる部分ですが、レジャーそのものを形作ってます。現在、コンセンサスアルゴリズム インディプレナムコード、これはPBFT (practical Byzantine Fault Tolerance) ビザンチン障害耐性をもつ分散合意アルゴリズムの 1 つです

レジャーを常にシンクさせています。そうすることで、みんながレジャーに何が書かれているかを同意することができ、変更できません。

インディノードは、トランザクションを受け取るところで、トランザクションをレジャーから査定したり、書いたり、読んだりまたは誰か使う必要がある人に戻したりするところです。

ハイパーレジャープラグインもあります。実験的なトークンのプラグインです。例えば、ネットワーク上でトークンを使って、トークンネットワークフィまたはバリューエクスチェンジの他のタイプを試したりします。

これらのプラグインは、みなさんがノードやプレナムコードを強制的に変化させたりすることなく、ネットワークの機能を延長させることができます。

右側の部分をみてみましょう。これらはノードコードの若干上にありまして、アプリケーションに書き込むようにしています。

indie resolver は、DIDが基本的なアドレスです。DIDメソッドを用いて、解明します。そして、ある情報を取りにいくのに、どこのレジャーにいけば良いかなどです。

Resolverの上にあるSDKは、エージェントコードより簡単で、エージェントコードがその上にあります。典型的なエージェントコードは、AriesAgentです。クラウドエージェントパイソンまたはACA-Py(Hyperledger Aries Cloud Agent Python)また、Biフォールドプロジェクトは、このAries Framework Javascriptの上にあります。

他の違ったフレームワークもGoやJAVAにもあります。全てインターオペラブルに使われています。なぜなら同じプロトコルとスタンダードを維持しているからで、エンタープライズやモバイルアプリがそれぞれ一番上にありまして、コミュニティによってカスタマイズされています。IndiesやAries Ursaを使ってみたい方、是非この図の上から初めてください。この図のしたから始めないでくださいね。すでにあるエージェントを使ったり、コードやサンプルを今いらっしゃる業界の必要に応じて修正したら良いです。

プレゼンテーション後、たくさんの良い質問を頂きました。中でも皆さんが気にされていたのは、ゼロ知識証明に関することだと思いました。質問は、「ゼロ知識証明は既に社会実装可能な技術でしょうか。技術的困難は残されていますか。」でした。ゼロ知識証明は、すでに実装されています。技術的な詳細も公開されています。新しい署名スタイルができれば、リビューされたり、実行したりできます。ですから、技術は使用可能な状態ですので、開発を遅らせる必要はないです

もし詳細など、御質問等などございましたら、兼原麻弥 maya@indicio.techまで直接、お気軽にご連絡ください。