【レポート記事】zkTLS入門：個人がwebデータを証明する技術とweb3ビジネスへの応用
こんにちは、こにちゃんです。
今回の記事は、2024年12月19日（木）に行われたzkTLSに関する勉強会「zkTLS入門：個人がwebデータを証明する技術とweb3ビジネスへの応用」のまとめ記事です。
また、今月の1月25日（土）に弊社が運営するDuneの日本コミュニティDune Japanでオンチェーン分析のワークショップを開催します。オンチェーン分析の考え方から実際のダッシュボードづくりまでの流れを体験できるようなプログラムを実施予定なので、ぜひご参加ください。
以下のボタンからLumaに登録できます✨
それでは本題のzkTLSに入っていきます。
本記事の構成は、当日のアジェンダを踏襲します。
１. 登壇者紹介
２. zkTLS・Web Proofとは？
（１）Web Proofが満たすべき条件について
（２）zkTLSを用いた仕組みの優位性について
３.zkTLSのユースケースと活用事例
（１）Credentials - 個人のデータを第三者に証明する
（２）Data Integrity - データの正確性と信頼性を向上させる
（３）Data Portability - 個人のデータをあるプラットフォームから別のプラットフォームに移動させる
（４）Data Assets - データを収益化する
（５）その他
４.zkTLSの現在地と課題
（１）zkTLSの現在地
（２）zkTLSが抱える課題
５.勉強会で出た質問と回答について
１. 登壇者紹介
今回、登壇していただいた株式会社Pontech 代表取締役のぽんたさんは、6年間ブロックチェーンエンジニアとしてアプリケーション開発に従事していた経歴があります。
今回なぜ「zkTLS・web proof 勉強会」を開くことになったかというと、ぽんたさんが複数のハッカソンにzkTLSをテーマに出場して賞金(Prize)を受賞しており、zkTLSの将来性を感じている経緯があります。
２. zkTLS・Web Proofとは？
（１）Web Proofが満たすべき条件について
「Web Proof」は、情報が特定のWebサイトから受け取られ、改ざんされていないことを第三者に証明するためのデータ証明で、「zkTLS」はWebを生成するための技術的なプロトコルです。
具体的に言うと、「ユーザーは、ウェブサイト W からリクエスト Q に対するレスポンス R を受け取り、そのレスポンス R に文字列 S が含まれている。」というデータの証明が「Web Proof」になります。
この「Web Proof」を使うことで、例えば以下のようなことが可能になります。
自分のSpotifyのマイページから「Web Proof」を作成し、トップアーティストがAKB48であること（AKB48のファンであること）を第三者に証明する。
自分の銀行口座ページから「Web Proof」を提示し、口座残高が一定額以上であることを第三者に証明する。
これまで、このような検証は、情報を提供するWebサイトが特定のAPIや署名を用意している場合にのみ可能でした。「Web Proof」は、特定のAPIが提供されていない場合でも、HTTPSを介して任意のWebサイトから受け取った情報を誰でも証明できるようにします。この一連の動作は、サービスの承認を必要としないパーミッションレスの形で実現できます。
本勉強会では、Xで特定のアカウントをフォローしている「Web Proof」を提出した人だけが購入できるECサイトを使ったデモをしました。
このような「Web Proof」のデータ形式は、規格化されているものではないため、以下のような条件があります。
MUST HAVE
Authenticity（真正性）
データがユーザーによって改ざんされていないことを証明できる。Provenance（データの出所）
データが特定のウェブサイトから確かに来たことを検証できる。
NICE TO HAVE
Privacy
「選択的開示」とも呼ばれ、必要な情報だけを開示し、それ以外の情報は開示しないことができる。
（２）zkTLSを用いた仕組みの優位性について
例えば、Uberと競合する配車サービスを始める際、zkTLSを用いることでUberの優良ドライバーとして高評価を得ている人を班別できるため、対象のユーザにより良い報酬レートや特典を付与できます。
Web3の世界では、このような行動をヴァンパイアアタックと呼びます。
従来のヴァンパイアアタックは、DefiやNFTマーケットプレイスで行われていましたが、zkTLSを使うことで、Web2のサービスに対して上記の行動を取ることが可能になります。
まとめると、zkTLSは各視点から以下のような見方ができる技術であると言えます。
ユーザー視点：データの主権をプラットフォームから取り戻すための技術
第三者視点：コールドスタート問題を解決しうる技術
大企業視点：データの管理方法を再考する必要性を促す技術
web3視点：オフチェーンのプライベートデータをオンチェーンに持ち込むことを可能にする技術
３.zkTLSのユースケースと活用事例
zkTLSは、以下の5つのカテゴリのユースケースが考えられます。
（１）Credentials - 個人のデータを第三者に証明する
Airdrop基準の拡大
プロジェクトはオンチェーン活動に限定されていたAirdropの対象者を、オフチェーンでの行動に基づいて拡張できます。
Onchainの信用スコア
DeFiの担保要件の引き下げや個別の借入条件の設定に使用できる信用スコアを、収入証明やクレジット支払い履歴などのオフチェーンのデータから作成してオンチェーンで検証できます。
Dynamic Pricing
Eコマースプラットフォームでは、Amazonでの購入履歴を「Web Proofs」で確認し、頻繁な購入者に割引を提供できます。
Auto-gated communities
いわゆるトークンゲートの機能を拡張し、「オープンだがプライベートな」コミュニティを構築する新しい方法が生まれます。
検証プロセスの自動化
例えば現在スクリーンショットを提出してもらっているような確認プロセスや、履歴書のバックグラウンドチェックなど、手動の検証プロセスを自動化することで、運用コストを削減し、業務の効率化を達成します。
（２）Data Integrity - データの正確性と信頼性を向上させる
データの品質管理
AIの強化学習のためのデータをラベリングしているユーザーが、特定タスクに必要な医師や弁護士などの資格を持っていることを検証します。
Proof of Humanity
「Web Proofs」でリアルなユーザーデータを検証し、偽アカウントやBotによる不正行為の脅威を効果的に排除できます。
Proof of Autonomy
注目を集めているAIエージェントにおいて、彼らが出力したとされるアウトプットが、実際に特定のAIモデルから生成されたものであることを証明できます。
偽レビューの排除
製品を購入したりサービスを利用したり、特定の場所を訪れたりした実際のユーザーだけがレビューを書けるようにすることで、偽レビュー対策に活用できます。
DePINデータの検証
「Web Proofs」は、DePIN（分散型物理インフラネットワーク）において、リソースの使用状況と消費量を検証するための重要なツールとして機能します。
（３）Data Portability - 個人のデータをあるプラットフォームから別のプラットフォームに移動させる
コールドスタート問題の解決
コールドスタート問題とは、ネットワーク効果が必要なプラットフォームが、十分なユーザー数を確保する前に価値を提供できない状況を指します。
「Web Proofs」を使用すれば、競合プラットフォームからユーザーデータを検証可能な形で取り込み、ユーザーの移行を容易にすることで、新規プラットフォームの早期成長を支援できます。
（４）Data Assets - データを収益化する
Private Data Pools
パブリックデータセットが枯渇する中、LLM（大規模言語モデル）では、個人化された多様なデータが必要になるため、zkTLSで取得できるデータが収益化できます。
Pay with Your Data
「データを売る」から「データで支払う」へと進化する新しい取引モデルが可能になります。金銭の代わりに、ユーザーが検証済みの個人データを提供することで、商品やサービスの対価を支払う仕組みです。
Connections Marketplace
Connections Marketplaceは、個人のソーシャルネットワークを安全に収益化できる分散型のマーケットプレイスです。ユーザーは、「Web Proofs」を活用することで、他者とのつながりを証明して報酬を得ます。
Expertise Marketplace
従来のフリーランスマーケットプレイスでは、プロフィールやスキルの主張は自己申告が多く、不正確な情報が掲載されるリスクがあります。
（５）その他
Prediction Market Oracle
従来は、オンチェーンのオラクルがブロックチェーン上のデータソースから市場の結果を確定するために必要な情報を取得しており、現実世界のイベントを扱う場合、パブリックな情報や必要性が高い情報など限定されたものしか使えなかった。
Crypto Onramp / Offramp
ユーザーがVenmoやPayPalなどのWeb2決済システムを通じて支払い、その支払いを「Web Proofs」で検証してオンチェーンエスクローから暗号資産を受け取る仕組み。
Web3エコノミクスを組み込んだWeb2ゲーム
たとえば、Fantasy Premier League (FPL)のようなゲームでは、プレイヤーが通常はポイントや娯楽のためにプレイしますが、「Web Proofs」を導入すれば、オンチェーンの報酬システムとリンクさせ、プレイヤー間の取引を自動化できます。
実際に、zkP2PやzkP2P Ticketなどのサービスが稼働しており、今後も上記のユースケース以外の新しいサービスが産まれていく可能性があります。
実際にzkTLSを活用しているサービスとして、zkP2PやzkP2P Ticketがあります。
zkP2Pは、暗号資産を法定通貨にしたいユーザーAがコントラクトに暗号資産をロックし、法定通貨を暗号資産にしたいユーザーBがユーザーAに対して法定通貨を送金し、その「Web Proofs」をzkTLSを使って作成してコントラクトに提出することで、暗号資産を引き出せるという仕組みになっています。
また、zkP2Pの開発チームはzkP2P Ticketで、チケットの二次流通サービスを実現しています。
zkP2P Ticketは、チケットを売りたいユーザーAがzkTLSでチケットを所持証明する「Web Proof」を作成し、チケットを買いたいユーザーBがコントラクトに預けた暗号資産を、ユーザーBへチケットを譲渡して、その譲渡証明の「Web Proof」をコントラクトに提出することで暗号資産を引き出せるという仕組みです。
このようにzkTLSを活用したサービスは存在するものの、認知度はそこまで高くありません。
従って、上記のユースケース以外の新しいサービスが産まれていく可能性があります。
４.zkTLSの現在地と課題
（１）zkTLSの現在地
zkTLSの現在地は、各プロトコルが実用化に足る性能を備え始めており、いくつかのユースケースに基づいて稼働している一方、まだ十分なユーザー数がいない状態です。
（２）zkTLSが抱える課題
技術的な制約
対応可能なデータの範囲がwebサービスのみで、ネイティブアプリには使えない。
Web2サービスのAPI仕様へ依存しており、出力フォーマットの変更に対応が必要。
証明の使い回しに対する対応策を検討する必要がある。
UXの課題
ブラウザ拡張機能またはスマホネイティブアプリをユーザーに入れてもらう必要がある。
zkProof生成に時間がかかる。（どんどん早くなっており、実用化レベルまで来ている）
法的な整理の必要性
個人のデータか企業のデータかの整理が必要で、訴訟リスクがある。
５.勉強会で出た質問と回答について
Q1.zkTLSはネイティブアプリに実装できるのか
A.ネイティブアプリには実装が出来ない。対応可能なデータの範囲はwebサービスのみ。
Q2.zkTLSプロトコルでどの方式が優位になるのか
A.それぞれの優位性があり、現状はどの方式が優位になるか不明である。「MPC-TLS」は計算に時間がかかっている印象があり、現状の使用感的には「Proxy-TLS」が一番良いと思う。
Q3.データの永続性や相互運用性を担保するために企業がブロックチェーンを使う場合、zkTLSによって異なるシステム間のデータ証明が可能になればブロックチェーンを使う理由が1つなくなるのでは
A.zkTLSによってデータの永続性は担保されないが、相互運用性という面で考えるとそのような考え方も一理ある。そもそも現状でブロックチェーンを使う理由がなくて、その要因の一つにオンチェーン上にデータが少ないことがある。zkTLSを使うことでオンチェーンに紐づけられるオフチェーンのデータが増え、現状よりもブロックチェーンを使う理由が増えると考えている。
Q4.企業がzkTLSによるアクセスを防ぐ方法はありますか
A.まず一つ目の対策はネイティブアプリを使用すること。データの出力フォーマットを頻繁に変更する方法は対策ではあるが、逆に言うと、変更されたフォーマットに合わせるだけなので、いたちごっこの側面がある。
Q5.企業が自社プロダクトのAPI開発・提供する代わりに、zkTLSフレンドリーなシステム設計にすることでコスト削減やエコシステムを拡大することはできますか
A.API開発・提供とzkTLSフレンドリーなシステム設計は、同じようなコストなので削減にはならなそう。GDPR（EU一般データ保護規則）のような文脈でzkTLSフレンドリーなシステム設計にする可能性は考えられる。
Q6.web上のアクションであれば何でも証明できるのか
A.何でも証明できる。webページで表示されているものは理論上全て証明できる。ただしwebページの仕組みによって複雑な手順が必要なものもある。
執筆者：こにちゃん
最後まで読んでいただきありがとうございました。