![見出し画像](https://assets.st-note.com/production/uploads/images/93675632/rectangle_large_type_2_b6f1fbcbad5bbc9dc71ec27a10d72680.png?width=800)
生体認証 x ウォレットでWeb3クレデンシャルのボトルネックを解決する
はじめに
久しぶりにnoteを書いています。東大経済学部のNagumoです。
先日、本郷Web3バレーという東大生を中心としたWeb3の技術面に注力しているサークルで開催されたハッカソンで優勝することができたので、そのプロダクトについて紹介させて頂ければなと思います!
一言で言うと・・・
一言でいうと、「ウォレットとその持ち主を生体認証を用いて紐づける」ことを通じて、Web3クレデンシャルのボトルネックを解決することを目指すプロダクトです。
Web3クレデンシャルとは?
そのボトルネックとは?
どう解決するの?
という疑問が出てくるかなと思うので一つずつ解説していきます
Web3クレデンシャルとは
そもそもクレデンシャルとは、「ある人が特定の属性、資格などを持っていることを証明するもの」を指します。例えば、運転免許証、大学卒業証明書、〇〇検定合格通知書等がそれにあたります。基本的に中央集権的な当局・組織によって管理され、オフラインで物理的な形態を伴って発行・使用されます。
一方でWeb3クレデンシャルとは、中央集権的な当局によって管理されず、トークンの形で発行されます。オンチェーンに保存される場合、基本的には譲渡不可・売却不可・(破壊不可)のSoulBoundToken(SBT)の形式で発行されます。
Web3クレデンシャルによって、従来のWeb2クレデンシャルの問題点をいくつか解決することができます。プライバシーの問題に関して、Web3クレデンシャルデータはデータの所有権が個人に帰属することによって、所有者の同意なしにアクセスされ、使用される可能性がなく無ります。また、デジタル世界においても安全に利用・持ち運ぶことが可能になり、ポータビリティが向上します。もちろん、物理的に損失することもなくなります。さらに、KYCのような同じ検証プロセスを複数の中央集権的な組織で繰り返す必要もなくなることでしょう。そして、オンチェーンデータのオープンな性質により、クレデンシャルの検証が即座に可能になります。
その他Web3クレデンシャルに関する詳細の情報に関しては、Fracton Venturesさんの記事にてとても分かりやすく解説されていますので是非ご一読頂きたいです。参考にさせて頂きました。
Web3クレデンシャルのボトルネック
Web3クレデンシャルの革新性・重要性が理解できたところでWeb3クレデンシャルのボトルネックを考えましょう。
私の考えるWeb3クレデンシャルのボトルネックは、「ウォレット(秘密鍵)を盗難する(or 譲渡される)ことで容易に他人のクレデンシャル情報を利用できるようになってしまう」ことです。
例えば、AさんがT大学の卒業証明SBTを持っていたとして、BさんがそのSBTをどうにかして手に入れたいと考えているとします。その際、BさんはAさんを嵌めてウォレットの秘密鍵を不正に入手する or Aさんに交渉して秘密鍵を入手することで、BさんはAさんのウォレットにアクセス可能となり、T大学卒業証明SBTをBさんが利用できるようになってしまいます。
![](https://assets.st-note.com/img/1671481718000-NE2SFaeKv1.jpg?width=800)
この、「ウォレットの盗難・譲渡」への耐性を欠いたまま、クレデンシャルの発行・検証(評価)のサービスが隆興しつつあるのが現状のWeb3クレデンシャル領域と考えています。
Web3クレデンシャル情報を利用する人・場所が少ない現状のままであれば、わざわざ特定のWeb3クレデンシャル欲しさに盗難や不正な譲渡が起こるとは考えられにくいですが、いずれWeb3クレデンシャルの重要性が高くなると仮定した場合、盗難や不正な譲渡への対応は必須になってくると考えられます。
将来を見据えて、今のうちに根本的なボトルネックは排除可能なインフラを整えておくことが重要だと思います。
インフラが整わないうちに、発行や検証・評価のサービスが先行して広まってしまうことは危ういと考えます。どこかのタイミングで決定的な問題が起こることでしょう。Web3クレデンシャル自体の信用問題に直結する問題が起こることになる前に、まずは土台・インフラを整えていくべきだと思います。
どう解決するのか?
Web3クレデンシャルのボトルネックを認識いただけたでしょうか?
それでは、次にどのようにこのボトルネックを解決するのかを説明いたします。
私たちは解決方法として、「ウォレットとその持ち主を生体認証を用いて紐づける」ことを提案します。
事前準備時と利用時(クレデンシャルの発行・検証)の二段階に分けて考えます。
まず、事前準備段階です。ここではウォレットとその持ち主との関係を何かしらのデータを介してオンチェーン上に保存することを目的としています。各個人が特有の特徴を持っており、取得難易度も低いことから、介するデータとして持ち主の生体認証データを用いることとしました。
やることとしては、「ウォレットアドレス」と「持ち主の生体情報をハッシュ化した値」を対応させたデータをオンチェーンに保存するのみになります。
![](https://assets.st-note.com/img/1671482013282-Z4E3ATWVpU.jpg?width=800)
続いて、利用段階です。Web3クレデンシャルにおける「利用」には大きく、「発行」と「検証(評価)」の2つがあると考えます。
「発行」は大学や国等の機関がクレデンシャル情報を個人に発行すること。「検証(評価)」は個人が示したクレデンシャル情報の真正性を検証し、そのクレデンシャルに基づき個人を評価することです。それぞれにおいて、事前準備段階での処理があったことで、先ほどボトルネックとして解説した課題が解決されることを説明します。
まず、発行段階において、以下の形でクレデンシャルを発行することによって課題は解決されます。
⓵発行主体は発行前にクレデンシャル配布対象ウォレットの持ち主の生体情報をハッシュ化した値を取得する
⓶対象ウォレットに対応する生体情報ハッシュ値(事前準備段階でオンチェーンに保存した値)と⓵で取得したハッシュ値を照合する
⓷一致していた場合のみ、クレデンシャル情報を配布する
![](https://assets.st-note.com/img/1671482648287-STRWgy7MoF.jpg?width=800)
このようにすることで、ウォレットの真の持ち主が申請した場合のみクレデンシャル情報を配布することが可能になります。
例えば、AさんがBさんの代わりに何かしらのカンファレンスに出席し、BさんのウォレットにPOAPを受け取ることはできなくなります。
また、AさんがBさんのウォレットを盗難した際に、その盗難したウォレットに新たなクレデンシャル情報をAさんの下で追加することは不可能になります。(どちらも後で言及しますが、すでにBさんのウォレットに関しても、ウォレットアドレスとBさんの生体情報の対応関係がオンチェーン上に保存されていることを前提としています)
次に、検証(評価)段階についても同様の形で課題が解決されます。
⓵検証(評価)者がクレデンシャルの検証(評価)前にクレデンシャルの提出者の生体情報をハッシュ化した値を取得
⓶提出されたクレデンシャルを所有するウォレットアドレスに対応する生体情報ハッシュ値(事前準備段階でオンチェーンに保存した値)と⓵で取得したハッシュ値を照合する
⓷一致していた場合のみ、クレデンシャル情報を検証(評価)する
![](https://assets.st-note.com/img/1671482825567-osuA2s3TEN.jpg?width=800)
このようにすることで、ウォレットの真の持ち主が申請した場合のみクレデンシャル情報を検証(評価)することが可能になります。
例えば、AさんがBさんのウォレットを盗難して、Bさんのクレデンシャル情報をあたかも自分のクレデンシャル情報かのように使用することができなくなります。
以上がボトルネックの解決策として私たちが提案するものになります。
今後の課題
さて、上記のような仕組みがあればweb3のボトルネックは解決すると思いますが、この仕組みが機能するにはとても大きな壁があると思われます。
それは、この仕組みをweb3クレデンシャル領域の常識にしなければならないということです。
過激かもしれませんが、この仕組みを取り入れた状態で獲得したweb3クレデンシャル以外は認めないといった認識が業界全体に広まり、皆が意識的に取り組んでインフラとして機能して初めて、この仕組みは機能するようになると思います。
ただし、現状、この課題に対する危機意識を抱いている人は少ない印象です。大きい企業(影響力のある企業)が表に立って声を上げる必要があるのかなと思います。
今後の展望
プロトタイプ(MVP)版を開発し、サービス化を視野に入れていきたいと考えています。
前述の通り、影響力のある企業とアライアンスを組むことの重要性は大きいため、そこを見据えた上で利用実績を蓄積していきたいです。
また、生体情報の取り扱いには細心の注意が必要です。
暗号学を研究している友人から、完全準同型暗号という技術を用いて、取得した生体情報をすぐに暗号化し、暗号状態のまま特徴量取得の計算を行うなどという理想的な実装方法を検討する必要もあるのではないか?というアドバイスをもらいましたが、どうも計算量が多く、サーバー代が馬鹿にならないようなので、Web2.5的なアプローチで現実的な落とし所を見つけられれば良いかなと考えています。
さいごに
ご意見・ご感想・アドバイス頂けると、とても嬉しいです。
アイデアの壁打ち相手になっても良いよ!という方も絶賛募集中です。
Twitterまでご連絡お待ちしています!
この記事が気に入ったらサポートをしてみませんか?