Midnight ハッカソンのプロジェクトがプライベートなウェブデータとクレデンシャル検証を実証

Buenos Aires の Midnight ハッカソンの開発者たちが、外部データとデジタルクレデンシャルを中核に据えた、動作するプライバシーのプロトタイプ二つを発表した.

一つ目は、ZK Fetch と Reclaim のアテステーションを Midnight Compact と組み合わせ、ウェブデータの出所を特定する。KEEP は別のアプローチを採り、保持者の完全な個人記録を転送することなくクレデンシャルを発行および検証するよう設計されたモバイルアプリケーション Ward を通じて実装されている。

ZK Fetch が証明済みのウェブデータを Compact に取り込む

この最初のプロジェクトは、スマートコントラクトが外部 API から取得した情報に依存する際によく生じる課題に対処する。

HTTPS はクライアントとサーバー間の通信を保護するが、その情報を受け取るコントラクトは元の接続の当事者ではない。そこで開発者は ZK Fetch と Reclaim Protocol を用い、主張された送信元と HTTPS でやり取りが行われたことを示す暗号学的な証拠を作成した。

Reclaim の証明システムと Midnight Compact は直接の互換性がなかったため、チームはその間にノータリー層を追加した。ノータリーは証明を検証して署名し、Compact 内の Schnorr 署名の実装は、情報をコントラクト入力として受け入れる前に少なくとも二人のノータリーからの確認を要求する。

このアーキテクチャは Strava のデータでデモされた。二つのアカウントが約3.5キロメートルと15キロメートルのランニング結果を提出し、アプリケーションはより広いデータセットを公開することなく勝者を判定できた。

チームによれば、外部の証明プロセスには約3〜4秒を要し、その後に通常の Midnight のトランザクションに必要な時間が続くという。Compact の実装は依然として MVP であり、今後さらなるリファクタリングが予定されている。

KEEP はクレデンシャルを保持者のデバイスに保存する

KEEP は大学や学校、行政機関などが発行するクレデンシャルにプライバシーを適用する。

その Ward モバイルアプリケーションは、保持者と検証者の双方の役割をサポートする。個人記録を複数のシステムに分散させる代わりに、クレデンシャルはユーザーの電話に留まり、保持者は特定の確認に必要な情報だけを開示できる。

このシステムは選択的開示のために Merkle tree を使用し、暗号学的な完全性を保ったままクレデンシャルの一要素だけを開示できる。開発者はまた、エンドユーザーに見えるブロックチェーンの複雑さを軽減することを意図したスポンサー付きトランザクションのために、Schnorr 署名と Capacity Exchange も組み込んだ。

デモでは、一台の電話が検証者として動作して QR チャレンジを表示し、もう一台の電話がクレデンシャルを保持した。保持者がチャレンジをスキャンすると、プロセスは Midnight を経由して実行され、クレデンシャルが有効であるとの確認が返ってきた。

チームは処理時間がおよそ20秒であると報告した。検証者は、保持者の完全なクレデンシャル記録を受け取ることなく結果を受領した。

二つのプライバシー系プロトタイプは異なるデータ課題を対象とする

この二つのプロジェクトは、異なる情報源に対処している。

ZK Fetch の実装は既存のウェブサービスから来るデータに焦点を当て、外部の主張が期待される HTTPS の送信元から来たことを立証する手段を Compact のコントラクトに提供する。

KEEP は個人に直接発行されるクレデンシャルに焦点を当て、保持者が記録をローカルに保持し、検証者に必要なものだけを開示できるようにする。

いずれもハッカソン段階の実装にとどまっている。KEEP チームは、24時間でのビルドでは完全な分散化は実現できず、現在はある程度中央集権的な Capacity Exchange のノードを使用していると述べた。開発者によれば、そのノードはユーザーの Midnight トランザクションに署名するために必要な保持者キーを保有していない。

これらのデモにより、Midnight には二つの明確に異なる動作するプロトタイプが残された。一方は証明済みの HTTPS 情報を Compact のコントラクトに渡すことができ、もう一方はモバイルデバイスにクレデンシャルを発行し、検証者に完全な個人記録を渡さずに主張を確認できる。