技術スタックの拡張：zkTLSの原理および潜在的な応用シナリオの概要
TechFlow厳選深潮セレクト
技術スタックの拡張：zkTLSの原理および潜在的な応用シナリオの概要
zkTLS の最大の利点は、Web2 HTTPSリソースの可用性を実現するコストを削減できることです。
Web3業界の深掘り報道に専念し潮流を洞察著者：@Web3_Mario
概要：最近、新しいプロジェクト方向性を探している中で、製品設計を行う際にこれまで触れたことのない技術スタックに出くわしたため、調査を行い、その学習内容を整理して皆様と共有したいと思います。
総じて、zkTLSとはゼロ知識証明（ZKP）とTLS（トランスポート層セキュリティプロトコル）を組み合わせた新技術であり、Web3分野では主にブロックチェーン上の仮想マシン環境において、第三者を信頼することなく、提供されたオフチェーンHTTPSデータの真実性を検証するために利用されます。ここでいう真実性には三つの側面があります。すなわち、データソースが実際に特定のHTTPSリソースから来ていること、返されたデータが改ざんされていないこと、およびデータの有効性が保証されることです。
このような暗号技術による仕組みにより、オンチェーンのスマートコントラクトが信頼できる形でオフチェーンのWeb2 HTTPSリソースにアクセス可能となり、データサイロを打破します。
TLSプロトコルとは何か
zkTLS技術の価値を深く理解するためには、TLSプロトコルについて簡単に概説しておく必要があります。まずTLS（トランスポート層セキュリティプロトコル）は、ネットワーク通信における暗号化、認証、データ完全性を提供し、クライアント（ブラウザなど）とサーバー（ウェブサイトなど）間のデータ安全転送を確保するために使用されます。ネットワーク開発分野以外の方々は、ウェブサイトにアクセスする際、一部のドメイン名がhttpsで始まり、他のものはhttpで始まることに気づくかもしれません。後者の場合、主流ブラウザは「安全ではない」と警告を出します。一方前者では、「接続はプライベートではありません」や「HTTPS証明書エラー」などのメッセージに遭遇することがあります。このような警告が出る理由は、TLSプロトコルの可用性に起因しています。
具体的には、HTTPSプロトコルとはHTTPプロトコルの上位にTLSプロトコルを用いて、情報伝送の機密性と完全性を確保するとともに、サーバー側の真正性を検証可能にするものです。HTTPプロトコルは平文でデータを転送するネットワークプロトコルであり、サーバーの真正性を検証できないため、以下のようなセキュリティ課題が生じます。
1. クライアントとサーバー間の通信内容が第三者に傍受され、プライバシー漏洩のリスクがある；
2. サーバーの真正性を検証できないため、リクエストが悪意あるノードにハイジャックされ、偽の情報を返される可能性がある；
3. 返された情報の完全性を検証できないため、ネットワーク上の問題によってデータが欠落する可能性がある；
これらの問題を解決するために設計されたのがTLSプロトコルです。なお、SSLプロトコルをご存知の方もいるかもしれませんが、TLSプロトコルは実質的にSSL 3.1を基に開発されたものであり、商業的理由により名称が変更されたものの、本質的には同じものです。そのため、一部の文脈では両者は交換可能に使われることもあります。
TLSプロトコルが上記の問題を解決する主なアプローチは以下の通りです。
1. 暗号化通信：対称鍵暗号（AES、ChaCha20など）を使用してデータを保護し、盗聴を防ぐ。
2. 身元認証：第三者機関（CA）が発行するデジタル証明書（X.509証明書など）を通じてサーバーの身元を検証し、中間者攻撃（MITM）を防止する。
3. データ完全性：HMAC（ハッシュメッセージ認証コード）またはAEAD（認証付き暗号）を使用して、データが改ざんされていないことを保証する。
ここでは、TLSプロトコルに基づくHTTPSプロトコルのデータ交換過程における技術的詳細を簡単に説明します。このプロセスは大きく二つの段階に分けられます。第一段階はハンドシェイク段階であり、クライアントとサーバーがセキュリティパラメータを協議し、暗号化セッションを確立します。第二段階はデータ転送段階であり、事前に合意したセッション鍵を使って暗号化通信を行います。具体的な手順は以下の4ステップで構成されます。
1. クライアントがClientHelloを送信：
クライアント（ブラウザなど）がサーバーにClientHelloメッセージを送信します。内容は以下の通りです。
l 対応するTLSバージョン（例：TLS 1.3）
l 対応する暗号アルゴリズム（Cipher Suites、例：AES-GCM、ChaCha20）
l ランダム数（Client Random）（鍵生成用）
l 鍵共有パラメータ（例：ECDHE公開鍵）
l SNI（サーバー名表示）（オプション、複数ドメイン対応用）
目的は、サーバーにクライアントの暗号化能力を知らせ、セキュリティパラメータの準備を促すことです。
2. サーバーがServerHelloを送信：
サーバーはServerHelloメッセージで応答します。内容は以下の通りです。
l 選択された暗号アルゴリズム
l サーバーランダム数（Server Random）
l サーバーの証明書（X.509証明書）
l サーバーの鍵共有パラメータ（例：ECDHE公開鍵）
l Finishedメッセージ（ハンドシェイク完了確認用）
目的は、クライアントにサーバーの身元を知らせ、セキュリティパラメータを確定させることです。
3. クライアントがサーバーを検証：
クライアントは以下の操作を実行します。
l サーバー証明書の検証：証明書が信頼できるCA（認証局）によって発行されており、期限切れまたは失効していないかを確認；
l 共有鍵の計算：自身とサーバーのECDHE公開鍵を使用して、セッション鍵（Session Key）を計算。この鍵は以降の通信の対称鍵暗号（例：AES-GCM）に使用される。
l Finishedメッセージの送信：ハンドシェイクデータの完全性を証明し、中間者攻撃（MITM）を防止。
目的は、サーバーの信頼性を確保し、セッション鍵を生成することです。
4. 暗号化通信の開始：
クライアントとサーバーは、合意したセッション鍵を使用して暗号化通信を開始します。
l 対称鍵暗号（例：AES-GCM、ChaCha20）でデータを暗号化し、速度と安全性を向上。
l データ完全性保護：AEAD（例：AES-GCM）を使用して改ざんを防止。
このように4ステップを経ることで、HTTPプロトコルの問題を効果的に解決できます。しかし、このWeb2ネットワークで広く使われる基礎技術は、Web3アプリケーション開発においては逆に課題となっています。特にオンチェーンのスマートコントラクトが特定のオフチェーンデータにアクセスしたい場合、データ可用性の観点から、オンチェーンVMは外部データ呼び出し機能を開示せず、すべてのデータの追跡可能性を保証することで、コンセンサスメカニズムの安全性を維持しています。
しかし、幾度かの反復を経て、DAppがオフチェーンデータに依存する必要があることが明らかになり、ChainlinkやPythなどのOracle（予言機）プロジェクトが登場しました。これらはオンチェーンとオフチェーンデータの中継橋として機能し、データサイロを打破しています。また、中継データの可用性を確保するため、これらのOracleは一般的にPoSコンセンサスメカニズムを採用しています。つまり、中継ノードが不正行為を行うコストを利益よりも高く設定し、経済的インセンティブからオンチェーンに誤った情報を提供しないようにしています。例えば、スマートコントラクト内でBinanceやCoinbaseなどの中心化取引所におけるBTCの加重平均価格を参照したい場合、これらのOracleがオフチェーンでデータを取得・集計し、オンチェーンのスマートコントラクトに保存して初めて利用可能になります。
zkTLSが解決する問題
しかし、人々はこのOracleベースのデータ取得方式に2つの問題があることに気づきました。
1. コストが高すぎる：Oracleがオンチェーンに伝えるデータが改ざんされておらず、真実であることを保証するためには、PoSコンセンサスメカニズムが必要ですが、このPoSの安全性は預入金額に依存しており、運用コストが発生します。さらに通常、PoSコンセンサスでは大量のデータ冗長性が存在し、データセットがネットワーク内で繰り返し転送・計算・集計される必要があるため、コンセンサスが成立します。これによりデータ利用コストがさらに高くなります。そのため、Oracleプロジェクトは顧客獲得のために、BTCなどの主要資産価格といった最も主流なデータのみ無料で提供し、特殊なニーズに対しては有料サービスを提供する傾向があります。これは特にロングテールやカスタマイズされたニーズを持つアプリケーションの革新を妨げています。
2. 効率が低い：通常、PoSコンセンサスには一定の時間がかかり、オンチェーンデータの遅延が生じます。これは高頻度アクセスを必要とするユースケースにとって不利です。なぜなら、オンチェーンで取得できるデータはリアルタイムのオフチェーンデータと大きな時間差があるからです。
これらの問題を解決するために、zkTLS技術が登場しました。その主なアイデアは、ZKP（ゼロ知識証明）アルゴリズムを導入することで、オンチェーンのスマートコントラクトが第三者として、あるノードが提供するデータが実際に特定のHTTPSリソースにアクセスして得られたものであり、かつ改ざんされていないことを直接検証できるようにすることです。これにより、従来のOracleがコンセンサスアルゴリズムによって引き起こされる高コストな利用問題を回避できます。
ここで疑問を持つ方もいるでしょう。「なぜオンチェーンVM環境にWeb2 API呼び出し機能をそのまま組み込まないのでしょうか？」答えは「不可能」です。オンチェーン環境が閉鎖的なデータ構造を維持する必要があるのは、すべてのデータのトレーサビリティを保証するためです。つまり、コンセンサスプロセスにおいて、すべてのノードが特定のデータまたは実行結果の正確性について統一された評価ロジック、あるいは客観的な検証ロジックを持つ必要があります。これにより、完全に非信頼環境下でも、多数の善意ノードが自らの冗長なデータ判断に基づき、結果の真偽を直接判定できます。しかし、Web2のデータについては、このような統一評価ロジックを構築するのが困難です。なぜなら、ネットワーク遅延などの理由により、異なるノードが同一のWeb2 HTTPSリソースにアクセスしても異なる結果を得る可能性があるため、コンセンサス形成に困難が生じます。特に高頻度データ領域では顕著です。もう一つの重要な問題は、HTTPSプロトコルが依存するTLSプロトコルの安全性が、クライアントが生成するランダム数（Client Random）と鍵共有パラメータに依存している点です。これらはサーバーとの暗号鍵に関するネゴシエーションに使用されますが、オンチェーン環境は公開透明であるため、スマートコントラクトがこれらのランダム数と鍵共有パラメータを管理すれば、重要なデータが暴露され、データの機密性が損なわれてしまいます。
そこでzkTLSは別のアプローチを採用します。その構想は、暗号技術によって、従来のOracleがコンセンサスメカニズムに依存してデータ可用性を確保する高コストを代替することです。これはL2におけるZK-RollupがOP-Rollupを最適化するのと類似しています。具体的には、ZKP（ゼロ知識証明）を導入し、オフチェーンの中継ノードが特定のHTTPSリソースから取得したデータ、関連するCA証明書検証情報、時系列証明、およびHMACまたはAEADに基づくデータ完全性証明を計算してProofを生成します。そしてオンチェーンでは必要な検証情報と検証アルゴリズムを維持することで、スマートコントラクトが重要な情報を露呈せずに、データの真実性、有効性、およびデータソースの信頼性を検証できるようにします。アルゴリズムの詳細についてはここでは述べませんが、興味のある方は各自で深く研究してください。
この技術の最大の利点は、Web2のHTTPSリソースの可用性を確保するコストを大幅に削減できることです。これにより、ロングテール資産のオンチェーン価格取得コストの低減、Web2世界の権威あるウェブサイトを活用したオンチェーンKYCによるDIDの最適化、Web3 Gameの技術アーキテクチャ設計の改善など、多くの新規ニーズが喚起されます。もちろん、zkTLSが既存のWeb3企業に与える衝撃も無視できません。特に現在主流のOracleプロジェクトにとっては大きな脅威です。そのため、ChainlinkやPythなどの業界大手は積極的に関連研究を進め、技術進化の中で依然として主導的地位を維持しようと努めています。同時に、従来の時間課金から使用量課金への移行、Compute as a serviceなどの新たなビジネスモデルも生まれるでしょう。ただし、この分野の難しさは、多くのZKプロジェクトと同様、計算コストを下げて商業的価値を持たせる方法にあります。
以上のように、製品設計を行う際には、zkTLSの動向にも注目し、適切な場面でこの技術スタックを取り入れることで、ビジネス革新や技術アーキテクチャの面で新たな方向性を見出すことができるかもしれません。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@web3_mario
