Zenn
🐥

zkTLS (Web Proofs) がっつり解説

2025/01/18に公開
ブロックチェーン
zk
zktls
tech

zkTLSについて、全体像を掴みながら詳細も理解できるようにリソースを整理しています。

zkTLSとは

zkTLSは「ある特定のwebサーバーから特定のデータを受け取ったことを第三者に証明するための技術・プロトコル」です。
このとき生成され、検証可能な証明をWeb Proofsと呼びます。もう少し具体的に言うと、Web Proofsにより以下のような暗号学的証明が可能になります。

「ユーザーは、ウェブサイト W からリクエスト Q に対するレスポンス R を受け取り、そのレスポンス R に文字列 S が含まれている。」

よくある誤解は「zkTLSはTLSの進化形で、ウェブサイトWが第三者に証明可能なProofをユーザーに対して発行してあげる」という印象を持ってしまいがちですが、これは誤りです。正しくは「ユーザーがウェブサイトWの許可を得ずに（パーミッションレスで）第三者に証明できる」点がポイントです。言い換えると、中央集権的なWebプラットフォームが管理しているユーザー自身のデータについて、ユーザーが自ら主権を取り戻すための技術ともいえます。

実現できること

zkTLSの可能性をより具体的に理解していただくため、まずユースケースの例を1つ紹介します。

ユースケース例: 新規ライドシェアサービス「Zber」の立ち上げ

あなたが新しいライドシェアサービス「Zber」（Uberの架空の競合サービス）を立ち上げようとしているとします。ドライバーを獲得するための戦略として、Uberの優良ドライバーがZberに登録すると特典を提供するキャンペーンを実施したいと考えています。これは、Web3の世界で「ヴァンパイアアタック」と呼ばれる手法に似ています。

zkTLSを使用したフローは以下のようになります：

  1. UberドライバーにUberのマイページにログインしてもらう
  2. Uberのサーバー→フロントエンドへの通信（TLS通信）からzkProof（ゼロ知識証明）を作成
  3. 作成されたproofをZber側に提出
  4. Zber側で、新規登録者が優良Uberドライバーであることを検証

このシステムの重要な特徴は次の2点です：

  • Uberの協力を必要としない
  • ドライバーは必要以上の個人データをZberに提供する必要がない

以下では、この技術の詳細について深掘りしていきます。

TLSとTLSハンドシェイク

まずは既存のTLSの仕組みを把握し、元々第三者への証明が想定されていないことを理解します。

出典: TLS | SSLハンドシェイクのプロセスは？

TLSは、インターネット通信を安全にするために設計された暗号化および認証プロトコルです。TLSハンドシェイクは、TLSを使った通信セッションを始めるプロセスです。TLSハンドシェイクの間、通信する二者がメッセージをやり取りして互いを認識し、検証し、使用する暗号アルゴリズムを決定し、セッション鍵について合意します。TLSハンドシェイクはHTTPSの仕組みの根本部分です。

サーバーとクライアントはそれぞれ秘密鍵を用意し、協働してセッション用の共通鍵を生成します。生成された共通鍵は通信の暗号化だけに使われ、ハンドシェイク後は秘密鍵は破棄されるため、二者間での安全な通信が確保されます。

しかし「第三者への証明」を考える場合、以下の問題があります。

  • 共通鍵を使用しているため、レスポンスのデータをクライアント側で改ざんできてしまう可能性がある
  • HTTPSレスポンス全体を転送すると、必要以上の個人情報が開示されてしまう

Web Proosの条件

そこで登場するのがWeb ProofsとzkTLSです。詳しい技術に入る前に、Web Proofsを構成する条件を整理します。

MUST HAVE

  • Authenticity（真正性）
    • データがユーザーによって改ざんされていないことを証明することができる
  • Provenance（データの出所）
    • データが特定のウェブサイトから確かに来たことを検証することができる

NICE TO HAVE

  • Privacy
    • 「選択的開示」とも呼ばれ、必要な情報だけを開示し、それ以外の情報は開示しないことができる。

このことから「zkTLS」という名称はややミスリーディングではないか、という批判もあります。ただし本記事では検索のしやすさから「zkTLS」を併用しつつ、「Web Proofs」という言葉も使用していきたいと思います。

3つのモデル

zkTLSの技術的仕組みには、大きく分けて以下の3つの種類があります。
1.TEEベース
2.MPCベース
3.Proxyベース

TEEベース

TEE（Trusted Execution Environment）は、CPU内部の安全な領域で機密情報を取り扱い、計算を行う機能です。OSや他のソフトウェアが侵害されても、TEE内部で実行されるプロセスやデータを安全に保護できる点が特徴です。

TEEベースモデルでは、以下のような流れで証明が行われます。

  1. Prover（証明者）がサーバーから取得した生のデータをTEEに渡す
  2. TEEがエンクレーブ内でメッセージの内容を検証・認証
  3. 証明（ネットワーク証明）を生成し、第三者へ直接送信

これにより、ウェブサイトの応答が正真正銘のものであることを第三者に保証できます。

詳細はこちらの動画をご覧ください↓

https://vimeo.com/923289638

Trust Assumption

  • ハードウェアプロバイダーを信頼する
  • サイドチャネル攻撃のリスクを許容する

利点

  • データを検証するために第三者の公証人や代理人が必要ない
  • 最小限のネットワークオーバーヘッド

欠点

  • ハードウェアへの依存度が高く、柔軟性に欠ける。ハードウェアの脆弱性に晒される
  • デバイス間の互換性の問題により、導入が妨げられる可能性がある

プロジェクト

MPCベース

次にMPC（マルチパーティ計算）ベースです。クライアントとNotary（公証人）が協調してMPCを使用し、TLSハンドシェイクを行います。

  1. クライアントと公証人が共有公開鍵を生成
  2. セッションキーは2つに分割され、クライアントと公証人がそれぞれ保持
  3. 公証人＋クライアントは単一の「スーパークライアント」としてサーバーと暗号化通信をする

セッション終了時には、クライアントがプレーンテキストデータに対する認証済みコミットメントを作成し、公証人がこれを検証して署名します。その後、クライアントはZK Proofを生成し、必要な情報のみを開示することが可能になります。

Trust Assumption

  • 証明者が公証人／検証者と共謀しないこと

利点

  • 高いセキュリティ
  • サーバーによるIPブロックのリスクがない
    • サーバーは単一のクライアントとして認識したものと対話するため、特定のIPアドレスがブロックされる可能性がない

デメリット

  • データサイズが大きいほど計算量・通信量が急増し、オーバーヘッドが高い
  • ネットワーク遅延に弱い（わずかな遅延増加でもMPCの完了時間が大幅に延びる）

プロジェクト

Proxyベース

最後にProxyベースです。ブラウザのプロキシ機能を活用します。クライアントはウェブサイトに直接リクエストを送る代わりに、HTTPSプロキシを介してリクエストを送信します。

  1. クライアントとサーバーの仲介役としてプロキシが暗号化データを検証（ただし内容への直接アクセスはない）
  2. セッション完了後にクライアントがセッションキーの一部を共有し、機密でない部分だけを復号可能に
  3. クライアントがレスポンスデータに対するゼロ知識証明（ZKP）を生成し、機密情報なしでTLSセッションの内容を検証

Trust Assumption

  • 証明者がサードパーティのプロキシと共謀しないこと

利点

  • MPCモデルと比較してレイテンシが低く、大規模なリアルタイムクライアントアプリケーションに適している

デメリット

  • プロキシサーバーの過負荷によるパフォーマンス低下の可能性
  • サーバー側でプロキシ経由のリクエストをブロックする可能性がある

プロジェクト

期待されるユースケースの分類

ここまでzkTLSの技術面を見てきましたが、どのような潜在的なユースケースがあるのかも重要です。以下の記事では4つの主要目的＋その他として事例やユースケースを分類しています。

What will the verifiable web look like?

大きな分類だけ引用しますので、詳細は上記記事をご覧ください。

  1. Credentials: 個人のデータを第三者に証明する
  2. Data Integrity: データの正確性と信頼性を向上させる
  3. Data Portability: 個人のデータをあるプラットフォームから別のプラットフォームに移動させる
  4. Data Assets: データを収益化する
  5. その他: 予測市場のオラクルやCryptoのオンランプ/オフランプなど、上記に当てはまらない事例

また、ユースケースについて記載しているリンクをいくつかご紹介します。
https://zkpass.gitbook.io/zkpass/overview/use-cases
https://telah.vc/zktls
https://www.zkon.xyz/blog/zktls-crypto-use-cases
https://reclaimprotocol.org/blog/posts/zktls-rfps
https://tlsnotary.org/use-cases

実用化されている事例

zkTLSをプロダクションレベルで使用しているサービスはいくつか出てきていますが、現時点ではユーザー数が少なく、まだ「Battle Tested」（十分に実践で試された）の状態には至っていません。
私が注目しているのはTLSNotaryと同じチームが開発するZKP2Pの以下2つの事例です。オンチェーンとzkTLSをうまく掛け合わせていると思います。


https://zkp2p.xyz/

また、web2の競合サービスからユーザーを移行させるためのキャンペーン（いわゆる「ヴァンパイア攻撃」）の事例もあるようです。
https://www.youtube.com/watch?v=XaTWxPTTELc&t=955s

https://www.noshdelivery.co/
Daisyのほうはリンクを見つけられませんでした😅

zkTLSを組み込んだアプリケーション開発方法

開発SDKとして比較的簡単に、そしてオープンに開発できるようになっているのは以下二つのプロトコルかと思います。
https://pontech.dev/post/zktls-app-dev-reclaim-protocol
https://pontech.dev/post/zktls-app-dev-zkpass

実運用に向けた課題

こちらの記事の中で技術的な制約、UXの課題、法的な整理の必要性という3つの観点から整理しています。
https://www.pontech.dev/post/zktls-current-position

よくある質問

Q. ブロックチェーンとの関係性は？
A. 一連のzkTLSのProof生成プロセス自体にはブロックチェーンは関わりません。生成されたzkProofはオンチェーンでもオフチェーンでも検証できます。そのためオフチェーンデータをオンチェーンで検証して動作するスマートコントラクトを開発することができます。また、その際検証するチェーンは問わないのでEVMでもSolanaでもその他様々なチェーンでも検証することが可能です。

Discussion