zkTLSと従来のオラクル：オンチェーンにより適したWebデータはどちらか？

この比較は、非公開ページのフィールドと公開フィードのどちらを選ぶか検討する、プロダクト担当者およびリスク担当者向けです。仕組み自体はzkTLSで解説しています。オフチェーンデータブリッジの包括的な用語については、ブロックチェーンオラクルを参照してください。以下のセクションでは、データソース、プライバシー、信頼、レイテンシーを比較し、スクリーンショット／PDFと暗号学的プロベナンスの境界についても扱います。

スクリーンショットやPDFで保証できる範囲と、暗号学的プロベナンスが始まる地点を含め、比較項目と「選択すべき場合」のチェックリストを示します。プロトコル形式のラッパーにはzkPass zkTLSオラクルがあり、ゼロ知識フィードに関する説明としてはzkOracleおよびzkCoprocessorがあります。

重要なポイント

• zkTLSは、HTTPSセッション内のフィールドがどのドメインに紐付くサーバーから取得されたかを証明することに最適化されています。一方、従来型オラクルは、操作耐性を備えた公開情報を継続的にオンチェーンへ書き込むことに最適化されています。
• 署名付き公開APIのないログイン後の非公開ページにはzkTLSが適しており、継続的な市場価格や複数ソースの集約には成熟したオラクルネットワークが適しています。
• 選択的開示はzkTLSの一般的な利点です。一方、従来型フィードでは通常、集約値がすべてのオンチェーン閲覧者に公開されます。
• スクリーンショットやPDFのアップロードは業務運用を支援できますが、検証可能なセッションプロベナンスはありません。暗号学的な主張が証明するのはプロベナンスと完全性であり、情報源の内容が真実であることではありません。
• 「選択すべき場合」のリストを用いて選択し、公証人／ノードセットのリスクと情報源のエラーを脅威モデルに記載してください。

この表は、判断を確認しやすい項目に整理しています。データソースとアクセス経路は誰がデータを閲覧できるかを決め、プライバシーと信頼の根拠は誤った受理のコストを決め、レイテンシーとデータタイプはどの経路がより低コストで実装できるかを決めます。スクリーンショットは、業務上、画像が「証拠」として扱われることが多い一方で、暗号学的プロベナンスとは異なる証拠の種類であるため、独立した行として扱っています。

図1：データソースへのアクセス、プライバシー、信頼前提、レイテンシーにおけるzkTLSと従来型オラクルの並列比較。

zkTLSとは？

zkTLSは技術群の一つであり、TLS／HTTPSセッション内のフィールドを第三者が検証できる主張に変換します。ドメインと証明書をバインドし、必要に応じて、完全な平文を渡すことなく、述語の結果のみを開示できます。たとえば、残高がしきい値を超えていることを証明できます。

zkTLSはHTTPSを置き換えるものではなく、情報源のビジネス上の事実が正しいかどうかを自動的に判断するものでもありません。クライアントとサーバー間の安全なデータ交換を可能にするHTTPSプロトコルとしてのトランスポート層セキュリティを用い、プロベナンスと完全性の証拠を提供します。チームは一般的な完全性確保の経路としてMPC、Proxy経路、またはTEEを使用します。「zk」は包括的なラベルとして使われることが多く、より広いプロトコル群における任意のレイヤーとしてゼロ知識証明が含まれる場合でも、TLSハンドシェイク自体がゼロ知識回路を実行するとは限りません。

実際には、クライアントが情報源サーバーとのTLSセッションを開始します。セッションキーはクライアントとサーバーで共有されるため、クライアント単独でも任意のバイト列を暗号化し、後から「復号」できます。そのため、第三者は生のトランスクリプトを正直なサーバー出力として扱うことはできません。そこでzkTLSの設計では、証人を追加します。たとえば、クライアントと共同でプロトコルを実行するMPC公証人、暗号文の方向を証明するProxy、またはキーを封印された計算環境内に保持するTEEです。生成された証明により、検証者はページ全体やセッションキーを知ることなく主張を利用できます。

従来型オラクルとは？

従来型オラクルは、スマートコントラクトがオフチェーンまたは現実世界のデータソースから外部データへアクセスできるよう、オフチェーンの事実をオンチェーン状態に書き込みます。一般的な出力には価格フィード、レート、スポーツ結果、公開イベントの結果があり、これらのネットワークは非公開のユーザー記録よりも公開データまたは公開利用可能なデータに適しています。設計の焦点は通常、複数ソースの集約、ノードの可用性、操作耐性であり、ユーザーのログイン済みセッション内にどのHTMLフィールドが表示されたかの証明ではありません。

コントラクトが読み取るのはブラウザのトランスクリプトではなく、フィードの更新です。継続的な公開市場データはこの経路に自然に適合します。一方、ログイン後の非公開ページのフィールドには署名付き公開APIがないことが多く、フィードネットワークはデフォルトで各ユーザーのHTTPSセッションを再現しません。そのため、分散型アプリケーションでは、個人のセッション証拠ではなく、共有される外部データにオラクルが使用されることが一般的です。オラクルの関係者は通常、公開エンドポイントを取得するサーバーを運用し、ユーザーのクライアントTLSチャネル内には存在しません。そのため、zkTLSのクライアントと証人によるプロトコルのように、非公開の銀行ページを容易に利用することはできません。

データソースとアクセス経路はどのように異なりますか？

主な違いは次のとおりです。zkTLSはユーザーがすでに情報源に対して開けるセッションを追跡し、従来型オラクルは運営ノードが取得できる公開ソースを追跡します。

zkTLSの経路では、クライアントが対象ドメインのサーバーとのHTTPSを完了し、事前のAPIアクセスを必要とせずに、あらゆるHTTPSウェブサイトから証明を生成できます。一部の設計では、MPC形式のセッション処理の代わりに、仲介者がクライアントとサーバーの通信を証人として確認または転送するProxyモデルを使用します。その他のMPCベースの方式では、安全なセッションキーを設定するプロトコル手順であるTLSハンドシェイクを共同実行し、どちらの当事者も単独ではサーバーの暗号文を偽造できないようにします。公証人、Proxy、またはTEEが検証可能な証拠を残し、その後に主張の証明が構築されます。

従来型オラクルの経路では、ノードが取引所、指数、または公開APIを取得してフィードに集約し、コントラクトがそのフィードを読み取ります。このため、容易に利用できる公開フィードがない既存システムのWeb2データを検証する場合に、zkTLSが役立ちます。そうでない場合、従来型のデータ検証または別の確認プロセスでは、別の当事者が同じソースを直接取得する必要があります。ユーザーセッションがなければ、zkTLSは公開フィードを置き換えられません。取得可能な公開ソースがなければ、ノードはログイン後の非公開フィールドを安全に利用できません。サーバー対応方式では、情報源サーバーがエクスポートを許可することにも依存するため、運営者は共有される情報を制限できます。そのため、Web Proofsを使用するプロダクトでは、クライアント、サーバー、証人となる関係者を一つのプロトコル経路として扱います。Oasis zkTLS解説やEthSystems zk-TLSパターンページなどの公開された仕組みの説明も、同じセッションから証明への経路を示しています。

プライバシー、非公開データ、選択的開示はどのように異なりますか？

zkTLSの一般的な機能は選択的開示です。正確な金額を公開せずにしきい値を満たしていることを証明したり、残りの情報を隠したまま一つのフィールドを抽出したりできます。また、完全な内容を明かさずに、そのようなデータに関する主張を証明することも可能です。このため、完全な記録を公開することなく、非公開または機微なデータを証明する必要がある場合にzkTLSが役立ちます。従来型オラクルのフィードがオンチェーンに置かれると、集約値は通常すべての閲覧者に見えるため、プライバシーの目標は完全に読み取り可能なフィードと衝突することがよくあります。

完全な明細なしで資格判定ゲートが必要な場合、zkTLSはその目的に適しています。これは、法的身元情報や財務記録などの個人データまたは機微なデータを、選択的開示で証明する場合に特に重要です。全員が同じ公開価格で決済する必要がある場合は、従来型フィードが目的に適しています。両者を組み合わせることもできます。公開価格にはオラクルを使用し、非公開のユーザー属性にはzkTLSの主張を使用することで、幅広い開示を行わずに非公開のインターネットデータをオンチェーンへ持ち込めます。一部のシステムでは、完全な記録を公開せずにHTTPSウェブサイトの非公開インターネットデータをオンチェーンで検証できるモデルとして説明されています。

選択的開示は通常、TLSトランスクリプト証明の上に構築されます。クライアントは引き続き情報源サーバーと通信し、証人となる関係者が応答のバインドを支援した後、回路または秘匿化プロトコルが他者が利用できるより小さな証明を生成します。MPC設計では、単独の関係者が悪用できないようセッションキーを分割する場合があります。Proxy設計では、クライアントが復号キーを保持し、計算内で平文の知識を証明する一方、Proxyが暗号文を証明します。いずれの場合も、非公開フィールドをすべての検証者サーバーに送らずに使用することが目的です。

信頼前提、データ完全性、障害モードはどのように異なりますか？

zkTLSにおける信頼は、ドメイン／証明書のバインドと、公証人、Proxy、またはTEEの経路が正直かつ稼働しているかに基づきます。情報源サーバーが誤ったフィールドを返した場合、形式上有効な証明が受理される可能性があります。プロベナンスは内容の真実性を意味しません。ゼロ知識開示が正しく実装されている場合、検証者は証明者の個人情報を知ることができません。それでもレビュー担当者は、どの関係者がキー素材を保持するか、どの関係者がMPCまたはProxyプロトコルを実行するか、どのサーバー証明書がTLSエンドポイントを固定するかを確認すべきです。

従来型オラクルにおける信頼は、ノードセットの構成、複数ソースのルール、経済的インセンティブに基づきます。障害は、ソース操作、ノードの共謀、古いまたは偏ったフィードとして現れることが多くなります。検証者または運営者が非公開記録を直接確認する必要がある場合、非公開記録には追加のセキュリティリスクとデータ漏えいの懸念も生じます。チェックリストは異なります。zkTLSではバインディング、述語、データ真正性、データ完全性、信頼の根拠の確認を重視し、オラクルでは鮮度、乖離しきい値、集約ソースを重視します。いずれかの確認を省略すると、「使えそう」という印象が誤った検証感につながります。証人が存在しない場合はクライアント側の偽造が主要な障害モードであり、プロトコルの関係者が共謀する場合は証人の不正が主要な障害モードです。

レイテンシー、コスト、データタイプはどのようにトレードオフすべきですか？

実務上の原則は3つあります。継続的な公開市場データには従来型オラクルが適しており、ユーザー固有のデータまたは財務データに関する単発または低頻度の証明にはzkTLSが適しており、スクリーンショットやPDFは暗号学的プロベナンスではなく業務記録に適しています。

zkTLSにはセッションごとのコストと証明コストがかかり、通常は即時更新されるフィード経路よりもレイテンシーが高くなります。残高しきい値、会員ランク、雇用または評判に関するフィールドに適しています。これには、基礎となる認証情報や完全な明細を公開せずに、銀行口座または銀行口座残高が必要なしきい値を満たすことを証明する用途も含まれます。MPC TLS経路は通信負荷が高くなる場合があります。Proxy経路では対話型計算を抑えられる場合がありますが、稼働中の証人サーバーが必要です。TEE経路ではキー処理を封印されたハードウェアへ移します。従来型オラクルは継続的な更新を維持し、価格、レート、公開イベントに適しています。多くのクライアントアプリが各ブロックで利用する低レイテンシーの市場データ向けに設計されています。

スクリーンショット、PDF、または手動アップロードは、「ページのように見えるもの」を示すことはできますが、第三者はTLSセッションが対象ドメインのサーバーに接続されたことや、フィールドがクライアントによって編集されていないことを暗号学的に検証できません。zkTLS形式の主張は、この種の非公開入力についてデータ真正性を確保し、データプロベナンスを維持できますが、それでも情報源のビジネス上の事実が真実であることを証明するものではありません。それでも、誤った情報源ページ、DOMの破損、公証人の停止は、正確性または可用性を損ないます。スクリーンショットのみをゲートとして扱う場合はアップロード者とレビュー担当者を信頼することになり、証明を「真実」として扱う場合は情報源のエラーが形式上有効なまま残り得ることを見落とします。スクリーンショットと暗号学的証明の両方を使用するチームは、各ゲートが受け入れる証拠の種類を明記すべきです。

zkTLSと従来型オラクルのどちらを選ぶべきですか？

**次の場合はzkTLSを優先してください：**データが、クライアントが情報源サーバーに対して開けるログイン後のHTTPSページまたは非公開APIに存在する場合、述語レベルで最小限の開示が必要な場合、利用可能な複数ソースの公開フィードがない場合、リクエストごとの証明レイテンシーと、公証人、Proxy、またはTEEの信頼の根拠が許容できる場合。これは、完全な開示を許容できない非公開のユーザー記録に対する本人確認やその他の証明において、より適した経路となることが多いです。関係者間の共同計算がブラウザの利便性より重要な場合はMPCを選択し、既存のクライアントProxy機能を使用したい場合はProxyを選択し、封印されたキー保管が主な制御手段である場合はTEEを選択してください。

**次の場合は従来型オラクルを優先してください：**継続的な公開市場価格またはイベント結果が必要な場合、コントラクトがネットワークで読み取り可能なフィードに基づいて決済する必要がある場合、成熟した複数ソース集約と乖離監視がすでに存在する場合。プライバシーがフィールドの主な制約ではなく、これらのフィードは通常、個人記録ではなく共有外部システムに基づいてスマートコントラクトの判断を支えます。オラクルネットワークは、各ユーザーが非公開TLSセッションを開かなくても、多数のクライアントコントラクトが同じ公開フィードを使用できるように構築されています。

**次の場合は両方を組み合わせてください：**公開価格をオラクル経由で取得し、非公開のユーザー属性をzkTLS経由で取得する場合。この組み合わせは、アプリが現実世界資産のワークフローや機微なビジネスロジックのために、公開フィードと非公開の主張の両方を必要とする場合によく使われます。いずれの場合も、「プロベナンス≠真実」をルールに記載してください。情報源サーバーのエラー、ノードの共謀、公証人の不正、脆弱なキー管理、ページの再設計は、注記ではなく重要なリスクです。プロトコルの選択では、証明が意味を持ち続けるためにどの関係者が正直であり続ける必要があるかを明示すべきです。

まとめ

zkTLSと従来型オラクルは、異なるオンチェーン上の問いに答えます。従来型オラクルは主に共有される外部データを提供する一方、zkTLSはプライバシーを保ちながら非公開のウェブ記録を検証可能にします。この差により、歴史的には公開フィードの方が利用しやすく、比較すると非公開データは十分に活用されてきませんでした。データソースへのアクセス、プライバシー、信頼の根拠、レイテンシーを比較すると、非公開のログインページフィールドと公開フィードが互いに代替可能であるケースはほとんどありません。

要するに、多数のコントラクトが同じ公開フィードを必要とする場合は従来型オラクルを使用し、クライアントが情報源サーバーからの非公開TLS応答を選択的開示証明で証明する必要がある場合はzkTLSを使用してください。MPC、Proxy、TEEは、そのプロトコル経路における主な証人の形式であり、それぞれどの関係者がキー素材を保持するか、またクライアントがどの程度の対話型計算を実行する必要があるかを変えます。スクリーンショットやPDFでは暗号学的プロベナンスの不足を補えず、TLS証明でも情報源の内容が正しいことを自動的に保証できません。「選択すべき場合」のリストを用い、公証人／ノードおよび情報源の障害モードを脅威モデルに記載する方が、ラベルについて議論するより有効です。

FAQ

zkTLSと従来型オラクルの違いは何ですか？

従来型オラクルは主に公開データをスマートコントラクトに提供します。一方、プロダクトでは、ユーザーが保持するHTTPSセッションにおいてデータの真正性を示す必要がある場合にzkTLSを使用します。これは、検証者が基礎となる記録を閲覧するか、それに関する証明のみを閲覧するかにも影響します。zkTLSは、TLSセッション内のフィールドがドメインおよび証明書に紐付くサーバーから取得されたことを証明します。一部の設計では、クライアントと公証人の関係者間でTLSハンドシェイク中にMPC（安全なマルチパーティ計算）を使用し、他の設計ではProxyまたはTEEベースの証人に依存します。従来型オラクルは、ノードセットと複数ソース集約を通じて、価格などの公開オフチェーン情報を継続的にコントラクトへ書き込みます。一方はセッションプロベナンスを最適化し、もう一方はフィードの可用性と操作耐性を最適化します。Proxyまたは証人ベースの設計では、通常、情報源サーバー自体を変更する必要はなく、クライアントはプロトコルのルールに従ってセッションキーを保持または共有します。

zkTLSと従来型オラクルはいつ使い分けるべきですか？

最小限の開示が必要で、署名付き公開APIがないログイン後の非公開フィールドにはzkTLSを使用してください。特に、プロダクトがアクセストークンまたはセッション認証情報を使用して非公開ソースからの検証可能なデータ共有を必要とし、仲介者に生の記録を渡すのではなく、クライアントが情報源サーバーに直接認証する必要がある場合に適しています。一部の実装ではゼロ知識証明の計算をローカルで実行するため、完全な記録をアップロードせずに選択した属性を証明できます。ネットワークで読み取り可能な決済が必要な継続的な公開市場価格またはイベント結果には、従来型オラクルを使用してください。これにより、コントラクトが共有価格を使用できる一方で、非公開記録を公開オラクルフィードから除外できます。異なる関係者が異なる証拠の種類を必要とする場合、公開フィードと非公開属性を一つのプロダクトで組み合わせることができます。

スクリーンショットまたはPDFアップロードはzkTLS証明の代わりになりますか？

信頼性の高い代替にはなりません。ウェブページのスクリーンショットやPDFは業務上は説得力があるように見える場合がありますが、検証可能なTLSセッションプロベナンスがなく、セッションの情報源または完全性に関する暗号学的証明も含まれません。そのため、第三者が編集済み画像や誤ったページを容易に除外することはできません。これに対し、HTTP Proxyの証人は、スクリーンショットやPDFでは不可能な方法で、検証可能なプロベナンスを維持するために通信を観測または中継できます。zkTLS形式の主張はドメインバインディングと完全性確認の経路を提供しますが、情報源が不正確なデータを返した場合でも、証明は形式上有効であり得ます。

zkTLS検証に成功すれば、情報源データが真実であることを意味しますか？

いいえ。通常、成功は、明示された信頼前提の下でプロベナンスと完全性について主張が成立することを意味します。証明には、応答データに対するメッセージ認証コードなどの完全性確認が含まれる場合があります。証明はプロベナンスと完全性を示す場合がありますが、基礎となる機微情報が誤ったフィールドまたは情報源側の不正確な入力を反映している可能性は残ります。情報源でのデータ入力エラー、改ざんされたページ、誤ったAPIフィールドでも、形式上有効な証明が生成されることがあります。一部の設計では、セッション中に暗号化キーも導出されるため、検証者が基礎記録を閲覧できないままユーザーは応答を復号できます。検証可能なプロベナンスと内容の真実性は別の層です。

従来型オラクルは、ユーザーのログイン後のウェブページフィールドを直接利用できますか？

通常、個人のHTTPSセッションとして利用することはできません。従来型ノードは通常、ユーザーの非公開ログイン後セッショントランスクリプトやWeb Proofsではなく、APIまたはその他の公開エンドポイントから公開ソースを取得します。一部の新しいプライベート・ツー・プライベート型オラクル設計では、認証済みTLSデータを標準フィードとして公開するのではなく、ブラインド計算サーバーへ送信します。このモデルは非公開入力に対するデータプロベナンスの提供を中心とし、規制コンプライアンスのために暗号化データを非公開に保つことができ、複数クライアントのデータを組み合わせて共同計算を行うこともできます。NillionのPrivate-to-Private Oraclesのようなプラットフォームはプライバシーのためにブラインド計算を使用しており、Reclaim Protocolはそれとは異なるProxy形式の例です。この方法では、機微なセッションデータを生のページ内容として公開せず、非公開計算へ移すことでセキュリティを高めることもできます。ログイン後の非公開ページに署名付きオープンAPIがない場合は、デフォルトのフィードジョブよりも、zkTLS形式のWeb Proofsまたは専用のデータパートナーシップが適しています。