ゼロ知識証明のブロックチェーンユースケースについて
●背景：
各エンタープライズブロックチェーン基盤のゼロ知識証明対応状況は下記のように整理した。
ゼロ知識証明の概要は、「証明者が検証者に対して、ある秘密を知っていることをその秘密を明かすことなく、証明することができること」
・HyperLedger Fabric：あり
・Corda：なし
・Quorum：あり
ゼロ知識証明自体の概要自体は理解したものの、具体的な仕組みまで理解できていないので、「どこまで証明できるのか」、また具体的に「どのようなユースケース で有効なのか」まで腹落ちしていないので、本ブログで整理しようと思う。
●どこまで証明できるのか
ゼロ知識証明というが、どんな秘密でも持っていることを証明できるのか？また、証明をするために必要な前提条件は何なのか？
・どんな秘密でも持っていることを証明できるのか？
これに対する答えは、「No」だ。
Wikipediaによると、ゼロ知識証明は以下の３条件を満たさないといけないという。
ゼロ知識証明は次の3条件を満たしていないといけない。
・完全性（completeness）: 真であることを確認する側（検証者）は、証明する側（証明者）の持っている命題が真であるならば、真であることが必ずわかること。
・健全性（soundness）: 証明者の持つ命題が偽であるなら、検証者は高い確率でそれが偽であると見抜けること。
・ゼロ知識性（zero-knowledge）: 証明者の持つ命題が真であるなら、検証者が不正して証明者から知識を盗もうとしても「命題が真である」以外の何の知識も得られないこと。このゼロ知識性は、どんな検証者（知識を持たない）であっても、正しい証明者と対話したかのような対話記録を生成できることだと記述することもできる。
例えば、証明したい内容が、「私の冷蔵庫入っているビールの本数（秘密の内容）を、私が知っていること」だったとする。
これを、完全性も健全性もゼロ知識性も満たすことはなかなか難しい。（３条件を満たすための仕組みが思いつかない）
一方で、証明したい内容が、「私がある公開鍵に紐づく秘密鍵（秘密の内容）を持っていること」だとする。
この場合は、検証者がランダムな暗号化してもらいたいランダムなトランザクションを渡し、証明者（私）が秘密鍵で暗号化し、検証者が公開鍵で複合化できたなら、それは証明者（私）が秘密鍵を持っていたことの証明となる。また同時に、上記３条件を満たしている。（というか３条件を満たしているから、ゼロ知識証明が成り立っている）
ゼロ知識証明の概略説明サイトを見ると、概略レベルで「証明者が検証者に対して、ある秘密を知っていることをその秘密を明かすことなく、証明することができること」とあり、ともするとどんな秘密でも持っていることを証明できるのかと勘違いしてしまいそうになるが、そういうわけではなく３条件が満たせる命題を見つけ、それを発展させることでベネフィットが得られる応用ユースケース になるようだ。
●ゼロ知識証明のブロックチェーンユースケース
では、ブロックチェーンにおけるゼロ知識証明のユースケースはどのようなものがあるのだろうか？
参考サイトは以下。
上記サイトによると、下記のユースケース があるとのこと。
①プライバシーのためのゼロ知識証明
②スケーリングのためのゼロ知識証明
③検証または認証のためのゼロ知識証明
④インターオペラビリティのためのゼロ知識証明
ただ、ゼロ知識証明対応しているBlockchain基盤が上記の全てのユースケースを実現できるというわけではなさそうだ。（各ユースケース毎に、実現できるブロックチェーン基盤が異なる）
以下の３大エンタープライズブロックチェーンでは、FabricとQuorumがゼロ知識証明対応ありと整理したが、それぞれ深掘りしてみる。
・HyperLedger Fabricのゼロ知識証明
上記 ibmの公式サイトによると、以下の２つがFabricではゼロ知識証明の文脈では実現できるとのこと。
・匿名クライアント認証（Anonymous client authentication with Identity Mixer）
・プライバシー保護下のアセット交換（Zero-Knowledge Asset Transfer (ZKAT)）
前者（匿名クライアント認証）は、先に例に出したような仕組みで、IDやパスワード情報を入力せずに、自身を証明するというユースケースだろう。
これは、現在広く利用されている自分の管轄できないサイトにIDとパスワードを入力するというある意味危険な行為による自身の証明の代替となりえるのだと思う。
現行のID・パスワード管理は、フィッシングサイトを始めとした、危険に満ちている。多くの人は管理しきれないIDとパスワードの数に課題を感じており、管理しきれないが故に同じパスワードで管理をしてしまい、あるサイトのID・パスワードが漏れた結果、あらゆるサイトになりすまし認証されてしまう。
この匿名クライアント認証は、おそらく先にあげた秘密鍵を利用した認証なのだろうと思うが、この方式を取れば、少なくともNW上のトランザクションに自身のIDとパスワードを流すという危険は回避できる。
（代わりに、秘密鍵の管理が重要になり、ここについてまた別の記事で深掘りしたいと思う。秘密鍵を生体認証情報と紐づける方法など）
後者（プライバシー保護下のアセット交換）は、要は、トランザクション送付元のアドレスと、送付先のアドレス、送付するトランザクションの内容を隠すということだと理解した。
このユースケース は、仮想通貨の送付という文脈であれば、価値を理解することができる。銀行振り込みの内容を関係のない第三者に見られたい人はいないので。
エンタープライズブロックチェーン基盤前提ではどうだろうか？
例えば、サプライチェーンコンソーシアムにおける２社間の受発注情報のトランザクションなど、絶対にライバル企業には見せたくない内容だ。トランザクションの中身をハッシュ化するだけでは不十分（A社とB社の間でやたらと最近トランザクションが流れているな・・というのも気づかれたくない）なのだ。
・Quorumのゼロ知識証明
パッと調べて出てこなかったので時間切れで諦める。
Fabricと似た感じなんじゃない？という勝手に想像しておくレベルで留めておく。