弊社Pontechではここ数ヶ月zkTLSの研究を進めています。これまでの記事では、zkTLSの可能性やその魅力的な側面について主にお伝えしてきました。しかし、実際にzkTLSを活用したアプリケーションのプロトタイプを開発する中で、いくつかの課題も明らかになってきました。今回は、zkTLSの現状と、それを実用化するうえで直面する課題について、技術的な制約、UXの課題、法的な整理の必要性という3つの視点から共有したいと思います。
過去関連記事↓
zkTLS技術の解説とETH Tokyoハッカソン参加レポート
zkTLSの現在地
zkTLSに関連するプロトコルはいくつか存在し、それぞれを活用したアプリケーションも登場しています。代表的なプロトコルとして以下が挙げられます。
これらの中で、特に実用的なユースケースを提供しているアプリケーションの一例が、PSE（Privacy & Scaling Explorations）が開発するzkP2Pです。zkP2Pは、法定通貨から暗号資産へのオンランプを実現するサービスで、以下のような仕組みを採用しています。
- ユーザーがVenmoやRevolutなどの個人間送金アプリで、特定の相手に送金を完了。
- その送金完了画面をもとに、zkProofを生成。
- zkProofをスマートコントラクトに提出し、対応するステーブルコインを引き出す。
このほかにも、ドメインやチケットの二次流通サービスなど、zkTLSを活用したユースケースが展開されています。これらはどれもzkTLSの使い所が上手く、感心するユースケースです。
しかし、現時点ではユーザー数が少なく、まだ「Battle Tested」（十分に実践で試された）の状態には至っていません。
次にzkTLSの現状の課題について、技術的な制約、UXの課題、法的な整理の必要性という3つの観点から整理してみます。
技術的な制約
Web2サービスのAPI仕様への依存
- zkTLSを利用するサービスは、証明を作成する対象となるweb2サービスのTLS通信やAPI仕様に合わせて開発する必要があります。当然ながら、web2サービス側がこちらの要件に適応してくれることは期待できません。
- 例えば、1つのページに表示されるデータが複数のAPIエンドポイントから取得されることは珍しくありません。しかし、zkTLSでは1つのTLS通信に対して1つのProofしか生成できないため、複数のデータを証明する場合、個別にProofを作成する必要があります。これにより、効率や実装の複雑さに課題が生じます。
- また、web2サービス側がAPIの仕様を変更した場合、それに応じてシステムのメンテナンスが必要になります。zkProofの検証がオフチェーンでのみ行われる設計の場合はアップデートすれば足りますが、オンチェーンで検証を行う設計の場合、コントラクトのアップグレードとガバナンスを考慮しておく必要があります。
証明の使い回しの問題
- zkProof内にユーザーを識別するためのIDが含まれていない場合、Proofを他人や自分で使い回すことが可能になります。これにより、本来意図した用途とは異なる形でProofが悪用されるリスクがあります。
- 例として、X（旧Twitter）上で特定のアカウントAをフォローしている人だけが購入できる商品を販売するケースを考えます。
- XのAPIでは、アカウントBがログインした状態でアカウントAのページにアクセスすると、アカウントBがAをフォローしているかどうかの情報が返されますが、このレスポンスにはアカウントBの情報は含まれていません。アカウントBの情報は別のAPIから取得されています。
- 仮にアカウントBがアカウントAをフォローしている場合、Bはその情報を基にzkProofを生成できます。しかし、AをフォローしていないCが商品を購入したい場合、BにProofの生成を依頼し、それを使用して商品を購入することが可能になってしまいます。
- zkTLSは匿名性を保つことが特長と謳われますが、多くのユースケースでは、Proofにある程度のユーザー識別要素が必要であることが上記のケースから分かります。
対応可能なデータの範囲
- 現時点のzkTLSプロトコルでは、Proofを生成できる対象はWebブラウザを通じてログイン可能なサービスに限定されています。ネイティブアプリのデータや、特定のデバイスでのみアクセス可能な情報には対応できないため、利用可能なデータ範囲が制約されています。
UXの課題
ブラウザ拡張機能またはスマホネイティブアプリの必要性
zkProofを作成するには、ブラウザ拡張機能またはスマホネイティブアプリを利用する必要があります。それぞれに特徴がありますが、導入ハードルや操作性に課題が残ります。
ブラウザ拡張機能
- メリット：既存のブラウザで動作し、ログイン済みのページから直接Proofを生成できるため、操作がスムーズ。
- デメリット：
- インストールのハードル：拡張機能をインストールする必要がある。
- PC依存：PC環境でしか利用できない。
スマホネイティブアプリ
- メリット：スマホでも利用可能で、モバイルユーザーへの対応が可能。
- デメリット：
- 再ログインの必要性：アプリ内ブラウザで対象サービスに再ログインが必要。
- インストールの手間：アプリのダウンロードが障壁に。
Reclaim Protocolでは軽量版アプリであるApp Clipを採用し、インストールの手間を軽減する工夫をしています。
zkProof生成にかかる時間
zkProofの生成は計算負荷が高いため、一定の処理時間を要します。zk技術の進化により計算速度は向上しており、これがzkTLSの実用化を後押しする要因となっています。しかし、現時点でも待機時間が発生する場合があり、ユーザーのストレスを軽減するために分かりやすく工夫されたUIが重要です。
また、Proof生成にはデバイスの性能やネットワーク環境も影響を与えます。これらの要因を踏まえたさらなる技術的な最適化が、ユーザー体験の向上に向けた次の課題と言えます。
法的な整理の必要性
技術的には全てのデータのproofを作成することが可能でも、企業の保有する知的財産の観点から、zkTLSを使うべきではないグレーゾーンなケースも考えられます。Reclaim ProtocolのCEOが述べている点を要約します。
- zkTLSは、まず「正当にユーザーのものであるデータ」を守るために戦う技術。
- ユーザーがプラットフォーム上で生成したデータ（例：視聴履歴、フォロー、購入履歴）はユーザーの権利として扱うべき。
- 一部のデータやアルゴリズムは企業に正当な所有権がある（例：Spotifyのトップアーティスト、プレイリストなど）。
- ユーザーのデータとして扱うか企業のデータとして扱うか曖昧なデータもある（例：ユーザーに対するレコメンデーションなど）。
- ユーザーに直接または間接的に属さないデータにはzkTLSを使うべきではない。
まとめ
zkTLSは、データの透明性とプライバシー保護を両立しながら、ユーザーが自身のデータを自由に活用できる未来を実現する可能性を秘めた技術です。その一方で、技術的な制約、UXの改善、そして法的な整理といった課題が依然として存在します。これらの課題を解決することで、zkTLSがより多くのユーザーやサービスに採用され、Web3やデジタルエコシステム全体の進化に貢献することが期待されます。
本記事がzkTLSに興味を持つきっかけや、新たな可能性を考えるヒントになれば幸いです。今後もzkTLSの発展やその応用例について共有していきますので、引き続きご注目ください。
株式会社Pontechでは、Dapps開発の受託を請け負っております。本記事のように採用する技術やサードパーティのサービスの検討からお手伝いすることが可能です。
Dapps開発に関するご相談がございましたら、ぜひ当社までお問い合わせください。
About ponta
2019年からEthereumを中心にDapp開発に従事。スキーとNBAとTWICEが好き。