zkTLSとは：初心者向け解説

zkTLSは、Webページまたは認証済みAPIの値をコントラクトや取引相手に持ち込みたい読者向けの技術であり、HTTPSを置き換える新しい転送方式ではありません。スクリーンショットや自己申告と比べ、「そのセッションが対象サイトに接続したこと」や「フィールドが条件を満たすこと」を検証可能な証拠に変換します。継続的な公開市場フィードでは、より一般的にブロックチェーンオラクルが利用されます。フィード形式との比較は以下で説明します。

以下のセクションでは、定義、セッションから証明までの手順、MPC／Proxy／TEEの違い、ユースケース、オラクルとの比較、リスクについて、OasisのzkTLS解説やEthSystemsのzk-TLSパターンページなどの公開された仕組みの解説とあわせて説明します。

重要なポイント

• zkTLSはHTTPSセッションを検証可能な主張に変換します。ドメインと証明書を紐付け、必要に応じて条件の結果のみを開示できます。
• この名称は誤解を招く場合があります。すべての設計がハンドシェイク時にゼロ知識証明を使用するわけではなく、MPC、Proxy、TEEが主な3つの方式です。
• TLSは共有対称セッションキーで終端するため、クライアント単独では偽造されたトランスクリプトを作成して提示できます。そのため、公証者、プロキシ、またはTEEが必要になります。
• 来歴は真実性を意味しません。オリジンが誤ったフィールドを返した場合でも、証明は形式上有効であり得ます。
• 検証者は、ドメイン／証明書の紐付け、条件、証明経路上のアテステーション署名またはトラストルートを確認する必要があります。

zkTLSとは何か、どのような問題を解決するのか？

zkTLSは、通常のTLSにあるギャップに対応します。Transport Layer SecurityはブラウザのHTTPS接続を支え、クライアントとサーバー間のチャネルを暗号化して認証します。しかし、セッション終了後に、悪用可能な復号素材を渡したりスクリーンショットに依存したりせず、サーバーが実際にそのコンテンツを返したことを第三者に納得させるのは困難です。そのため、コントラクトはログイン後のフィールドを取り込むことに苦労します。

標準的なTLSハンドシェイクでは、対称セッションキーが導出されます。ブラウザとサーバーはどちらも暗号化と復号を行えます。ユーザーが暗号文とそのキーを単独で提示した場合、他者はそのユーザーが偽の平文を暗号化し、必要に応じて復号した可能性を排除できません。したがって、クライアント単独は信頼できる証人にはなれません。この制約が、公証者、プロキシ、またはTEEの必要性につながります。

zkTLSが提供するのは、ビジネス上の真実に関する最終判断ではなく、来歴と完全性の証拠です。残高フィールドがサイトのTLSセッションから取得されたことを証明しても、誤ったデータ入力や改ざんされたページを否定できるわけではありません。これはzkOracleとzkCoprocessorにおけるゼロ知識フィードの議論と隣接しますが、異なる問題領域です。

zkTLSはどのように機能するのか？HTTPSセッションから検証可能な主張へ

大まかに言えば、zkTLSは通常のHTTPSセッションから検証可能な証明へと進みます。ユーザーがオリジンへのセッションを開始し、MPC公証者、Proxy、またはTEEの経路が検証可能な証拠を残した後、選択的開示証明が生成・検証されます。

1. セッションを開始する — 対象ドメインへのTLSを開始します。証明書とドメインの紐付けは、後の主張の一部となります。
2. 共同証人化または委任する — 公証者がハンドシェイク／復号に参加し（MPC）、プロキシが暗号文の方向をアテステーションし（Proxy）、またはTEEがリクエストを実行します。これにより、単独のクライアントがサーバー送信の暗号文を容易に偽造できなくなります。一部の設計では、これを単独クライアントのフローではなくマルチパーティプロトコルとして扱います。
3. 対象フィールドを取得する — セッション内でアカウントページまたはAPIをリクエストし、暗号化されたレスポンスを受け取ります。
4. 主張を構築する — トランスクリプトコミットメント、サーバーID、残高 > 閾値などの条件に対する証明（または経路署名）を生成します。回路ベースの経路では、トランスクリプト制約を証明出力に変換します。
5. 検証のために提出する — コントラクトまたは取引相手が証明とトラストルートを確認し、受理または拒否します。

選択的開示は一般的な第2層です。たとえば、正確な金額を公開せずに残高が閾値を超えることを証明したり、残りを隠したまま1つのフィールドを抽出したりできます。zkTLSにおける「zk」についてのReclaimの説明によると、プライバシーのためのZKはしばしば拡張機能であり、より基本的な要件は、レスポンスが実際にオリジンから来たことを第三者に納得させることです。

図1。zkTLSは、クライアントのHTTPSセッションからMPC／Proxy／TEEのアテステーション経路を経て、検証者またはスマートコントラクトが確認する選択的開示証明へと進みます。

検証者のチェックリストでは、少なくとも4項目を確認する必要があります。主張されたオリジンへのドメインおよび証明書の紐付け、ビジネスルールに合致する条件、許可リストに含まれる証明経路の署名またはトラストルート、そしてオリジンの構造変更によってパーサーが壊れるかどうかです。いずれかを省略すると、スマートコントラクトや取引相手向けに検証可能なデータを生成するという目的にもかかわらず、「検証可能」は「証明のように見える」ものに変わってしまいます。

なぜzkTLSと呼ばれるのか？MPC、Proxy、TEEはどう異なるのか？

「zkTLS」は、ゼロ知識証明がハンドシェイク時に実行される必要があることを示唆する一般的な総称ですが、必ずしもそうではありません。このラベルはハイブリッドプロトコルに広く使われますが、すべての実装が実際にその説明に当てはまるわけではありません。多くの設計はWeb ProofsやTLSアテステーションに近く、焦点はハンドシェイク内で必須となるZKではなく、検証可能性にあります。

3つの方式はいずれも、悪用のために対称キーを渡すことなく、暗号文がサーバーから来たことを第三者に納得させるという同じ問題に答えます。プロキシは平文を見ずにデータ転送の方向を観測できます。MPC／2PC設計（TLSNotary形式）は共同キーを用いて単独での偽造を防ぎます。Proxy設計は方向のアテステーションとユーザー側の復号証明を組み合わせます。TEE設計はハードウェア分離の中でセッションをホストします。フィールドの秘匿化のためにプライバシーZKを上乗せできますが、TEEおよび大半のMPCハンドシェイクはハンドシェイク層のZKではありません。

方式の選択は、脅威モデルとコストに関する判断です。単一の公証者、プロキシ、またはTEEを許容できるか、セッションを低レイテンシーに保つ必要があるか、オリジンが特定のTLSバージョンしかサポートしないかを検討します。MPC経路では、単一ノードが完全なキーを保持しないことも保証されます。「zk」は厳密な暗号分類ではなく、検証可能なWebデータのラベルとして捉えるべきです。

zkTLSは何に利用できるのか？

代表的なユースケースは、完全な明細を公開せずに、オフチェーンのアカウントが閾値を満たすことを証明することです。たとえば、信用適格性における残高基準、正確な金額を明かさない金融ワークフローでの銀行残高確認、ログイン済みポータルからの雇用または評判に関するフィールド、クエストルール向けのオフチェーン活動の確認などがあります。共通するパターンは、署名済みの公開APIが用意されていないHTTPSの背後にデータがあることです。

IDおよび属性のユースケースには、本人確認や検証可能なクレデンシャルのほか、年齢区分、会員ランク、要約評価などが含まれます。検証者が確認するのは条件の結果であり、プライベートデータを含むページ全体ではありません。zkPass zkTLSオラクルのようなプロトコル型製品は、プライベートデータをオンチェーンで検証可能にするものとして位置付けられます。プロトコルが証明をどのようにラップするかと、zkTLSパターン自体が保証する内容は分けて考える必要があります。

もう1つの分類は、プライバシーを保護するデータフィードです。アプリケーションは、完全なスクレイピング平文をすべての観測者に公開せずに、Webサイトのフィールドをオンチェーンアプリに取り込む必要があります。この場合、zkTLSは来歴を伴うフィールド証明を提供します。ただし、分散型金融やより広範なWeb-to-chainワークフローで利用される継続的な価格フィードや複数ソースの集約とは区別する必要があります。

zkTLSは従来のオラクルとどう異なるのか？

従来のオラクルは、多くの場合ノード群または複数ソースのフィードを通じて、オフチェーンの事実（価格、イベント結果）をチェーンに書き込むことに重点を置いています。この違いはオラクル問題の一部です。すなわち、信頼できるオフチェーンまたはWebデータをコントラクトに取り込むという問題です。zkTLSは、HTTPSセッションのフィールドが特定のオリジンから来たことを、必要に応じて選択的開示とともに証明することに重点を置きます。フィードは可用性と操作耐性を最適化し、zkTLSはWebセッションを検証可能な主張に変えることを最適化します。

フィードアーキテクチャ、信頼前提、失敗モードを比較する場合は、zkTLSと従来のオラクルを参照してください。簡潔に言えば、継続的な公開市場フィードには成熟したオラクルネットワークが適しています。一方、最小限の開示を必要とするログイン後のプライベートフィールドにはzkTLSの方が適しています。また、一部のシステムではデータポータビリティを別の設計目標として扱います。両者は組み合わせることができますが、どちらももう一方を置き換えるものではありません。

機密データにzkTLSを使用または依存するメリットとリスクは何か？

メリットとしては、ユーザーがオリジンへのHTTPSを完了できる限り、専用のフィードAPIを待たずに検証可能なフィールドを出力できること、選択的開示によりコントラクトが完全なプライベート記録を公開せずに事実を検証できること、そして主張をコントラクトがプログラム上で確認できることが挙げられます。

リスクも同様に具体的です。公証者、プロキシ、またはTEEの誠実性と可用性がトラストルートを形成します。共謀、拒否、または停止は、誤受理や失敗につながります。TEEベースの設計には、ハードウェアメーカーまたはアテステーションルートに関連するセキュリティリスクもあります。オリジンの誠実性はプロトコルの対象範囲外です。誤ったページであっても、形式上有効な証明が生成される可能性があります。フィールドパスの変更は条件を壊し、一部の公証スタックは特定のTLSバージョンしかサポートしません。

依存する側は、証明コスト、セッションレイテンシー、セッショントランスクリプトの保持リスクも考慮する必要があります。zkTLSは検証可能な来歴を改善しますが、任意のWebページを監査なしの真実の情報源に変えるものではありません。

まとめ

zkTLSは日常的なHTTPSセッションを検証可能かつ最小限に開示できる主張へと変換し、コントラクトがスクリーンショットを信頼するのではなく、フィールドがどのドメインに紐付くサーバーから来たかを検証できるようにします。「zk」はハンドシェイク時のゼロ知識証明を保証するものではありません。MPC、Proxy、TEEは異なる信頼前提のもとで完全性を実現します。

導入前に、対称キーを持つ単独クライアントが偽のセッション提示を演出できること、検証者のチェックリストがドメイン／証明書、条件、トラストルートを対象とする必要があること、来歴はコンテンツの真実性ではないこと、従来のオラクルとzkTLSが継続的フィードとプライベートページのフィールド証明を分担することを受け入れる必要があります。脅威モデルに応じて方式を選び、オリジンとアテステーションのリスクをそのモデルに記載してください。

FAQ

zkTLSとは何ですか？

zkTLSは標準的なTLS／HTTPS上に構築された設計群であり、第三者が確認できる主張を生成します。すなわち、特定のデータがドメインと証明書に紐付くサーバーから来たことを示し、必要に応じて条件の結果のみを開示します。HTTPSを置き換えることなく、プライベートなWeb2フィールドをコントラクト検証へ橋渡しします。

zkTLSはHTTPSセッションをどのように検証可能な主張へ変換しますか？

クライアントとオリジンがセッションを開始します。MPC公証者、Proxy、またはTEEが共同証人となるか処理を委任されることで、単独クライアントがサーバー暗号文を偽造できなくなります。その後、選択的開示証明が構築され、検証者はドメインの紐付け、条件、トラストルートを確認してから受理または拒否します。

zkTLSはTLSハンドシェイクでゼロ知識証明を使用する必要がありますか？

いいえ。zkTLSと呼ばれる多くのシステムは完全性のためにMPC、Proxy、またはTEEを使用します。ゼロ知識証明は、選択的開示やProxy形式の復号証明のために後段で用いられることが多くあります。ハンドシェイク自体ではZK回路が一度も実行されない場合があります。「zk」は一般的なラベルです。

zkTLSは従来のオラクルとどう異なりますか？

従来のオラクルは、複数ソースと可用性を目的としてオフチェーンの事実をコントラクトへ継続的に供給します。zkTLSは、セッションレベルのHTTPSフィールドについて、来歴と必要に応じた条件を証明します。公開フィードとプライベートなログインページのフィールドは異なる問題です。比較トピックを参照してください。両者は組み合わせることができます。

zkTLSに依存する際の主なリスクは何ですか？

主なリスクには、侵害または利用不能となった公証者、プロキシ、TEE、誤ったデータを返しても証明が形式上有効なままとなるオリジン、パーサーを停止させるページ構造の変更、TLSバージョンの制限があります。ドメインの紐付けとトラストルートの確認を省略すると、誤受理のリスクが高まります。