技術スタックの拡張：zkTLSの原理と潜在的なアプリケーションシナリオの概要

著者：@Web3_Mario
概要：最近、新しいプロジェクトの方向性を探しており、製品設計の際に以前に触れたことのない技術スタックに出会ったため、研究を行い、学んだことを整理して皆さんと共有します。一般的に、zkTLSはゼロ知識証明（ZKP）とTLS（トランスポート層セキュリティプロトコル）を組み合わせた新しい技術であり、Web3の領域で主にチェーン上の仮想マシン環境で、第三者を信頼することなく提供されるオフチェーンHTTPSデータの真実性を検証するために使用されます。ここでの真実性は、データソースが確かに特定のHTTPSリソースからのものであり、返されたデータが改ざんされていないこと、データの有効性が保証されることの3つの側面を含みます。この暗号学的実装メカニズムにより、オンチェーンのスマートコントラクトはオフチェーンのWeb2 HTTPSリソースに信頼できるアクセス能力を得て、データの孤立を打破します。
TLSプロトコルとは何か
zkTLS技術の価値を深く理解するためには、TLSプロトコルの簡単な概要を説明する必要があります。まず、TLS（トランスポート層セキュリティプロトコル）は、ネットワーク通信において暗号化、認証、データ完全性を提供し、クライアント（例：ブラウザ）とサーバー（例：ウェブサイト）間のデータの安全な転送を保証します。ネットワーク開発の方向性に関心がない方には、ウェブサイトにアクセスする際、一部のドメインはhttpsで始まり、一部はhttpで始まることに気づくかもしれません。後者にアクセスする際、主流のブラウザは常に安全でないという警告を表示します。一方、前者は「あなたのリンクはプライベートリンクではありません」やHTTPS証明書エラーの警告に遭遇しやすいです。このような警告の原因は、TLSプロトコルの可用性にあります。
具体的には、HTTPSプロトコルとは、HTTPプロトコルを基にTLSプロトコルを利用して情報の伝送のプライバシーと完全性を保証し、サーバー側の真実性を検証可能にしたものです。私たちは、HTTPプロトコルが明文伝送のネットワークプロトコルであり、このプロトコルがサーバー側の真実性を検証できないため、いくつかのセキュリティの問題を引き起こすことを知っています。
1. あなたとサーバー間の情報が第三者に傍受され、プライバシーの漏洩を引き起こす可能性があります。
2. サーバーの真実性を検証できず、リクエストが他の悪意のあるノードによってハイジャックされ、悪意のある情報が返されているかもしれません。
3. 返された情報の完全性を検証できません。つまり、ネットワークの理由でデータが失われる可能性はあります。
TLSプロトコルは、これらの問題を解決するために設計されました。ここで説明するのは、SSLプロトコルをご存知の方もいるかもしれませんが、実際にはTLSプロトコルはSSL 3.1バージョンを基に開発されたものであり、商業的な関連の問題から名前が変更されたに過ぎませんが、実際には一脈相承です。そのため、時々、ある文脈では2つの用語が互換的に使用されることがあります。
TLSプロトコルが上記の問題を解決するための主な考え方は：
1. 暗号化通信：対称暗号（AES、ChaCha20）を使用してデータを保護し、盗聴を防ぐ。
2. 身分認証：第三者が指定機関に発行したデジタル証明書（例：X.509証明書）を通じてサーバーの身元を検証し、中間者攻撃（MITM）を防ぎます。
3. データの完全性：HMAC（ハッシュメッセージ認証コード）またはAEAD（認証暗号）を使用してデータが改ざんされていないことを保証します。
ここで、TLSプロトコルに基づくHTTPSプロトコルのデータ交換プロセスにおける技術的詳細を簡単に説明します。全体のプロセスは2つの段階に分かれています。まず、ハンドシェイク段階（Handshake）で、クライアントとサーバーが安全なパラメータを交渉し、暗号化セッションを確立します。次に、データ転送段階で、セッションキーを使用して暗号化通信を行います。具体的なプロセスは4つのステップに分かれています：
1. クライアントが ClientHello を送信：
クライアント（例：ブラウザ）がサーバーに ClientHello メッセージを送信、内容は以下を含む：
サポートされている TLS バージョン（例：TLS 1.3）
サポートされている暗号アルゴリズム（Cipher Suites、例：AES-GCM、ChaCha20）
乱数（クライアントランダム）（キー生成に使用）
鍵共有パラメーター（例：ECDHE 公開鍵）
SNI（サーバー名表示）（オプションで、多ドメイン HTTPS をサポートするため）
その目的は、サーバーにクライアントの暗号化能力を知らせ、安全なパラメータを準備することです。
2. サーバーが ServerHello を送信：
サーバーが応答する ServerHello メッセージ、内容は以下を含む：
選択された暗号アルゴリズム
サーバー乱数（Server Random）
サーバーの証明書（X.509証明書）
サーバーの鍵共有パラメーター（例：ECDHE 公開鍵）
Finished メッセージ（ハンドシェイクの完了を確認するため）
その目的は、クライアントにサーバーの身元を知らせ、安全なパラメーターを確認することです。
3. クライアントがサーバーを検証：
クライアントが以下の操作を実行します：
サーバー証明書の検証：証明書が信頼された CA（証明書発行機関）によって発行されていることを確認し、証明書が期限切れまたは取り消されていないことを検証する。
共有鍵を計算する：自分とサーバーの ECDHE 公開鍵を使用してセッションキーを計算し、そのキーは後続の通信の対称暗号化に使用されます（例：AES-GCM）。
Finished メッセージを送信：ハンドシェイクデータの完全性を証明し、中間者攻撃（MITM）を防ぎます。
その目的は、サーバーが信頼できることを確認し、セッションキーを生成することです。
4. 暗号化通信を開始：
クライアントとサーバーは、合意されたセッションキーを使用して暗号化通信を行います。
対称暗号（例：AES-GCM、ChaCha20）を使用してデータを暗号化し、速度とセキュリティを向上させます。
データの完全性保護：AEAD（例：AES-GCM）を使用して改ざんを防ぎます。

この4つの操作を経て、HTTPプロトコルの問題を効果的に解決できます。しかし、Web2ネットワークで広く使用されている基盤技術が、Web3アプリケーションの開発に困難をもたらしています。特に、オンチェーンのスマートコントラクトが特定のオフチェーンデータにアクセスしたいとき、データの可用性の問題により、オンチェーンの仮想マシンは外部データの呼び出し能力を開放せず、すべてのデータの追跡可能性を確保し、合意メカニズムの安全性を保証します。
しかし、一連の反復を経て、開発者はDAppがオフチェーンデータに対するニーズがあることに気づき、一連のオラクルプロジェクト（例：ChainlinkやPythなど）が登場しました。彼らは、オンチェーンデータとオフチェーンデータの中継橋として機能し、このデータ孤立の現象を打破します。また、これらのオラクルは中継データの可用性を保証するために、一般的にPoS合意メカニズムを通じて実現します。つまり、中継ノードの悪行コストが利益を上回るようにし、経済的な利点から誤った情報をオンチェーンに提供しないようにします。例えば、スマートコントラクト内でBinance、Coinbaseなどの中央集権的取引所でのBTCの加重価格にアクセスしたい場合、これらのオラクルに依存してデータをオフチェーンで集約し、オンチェーンのスマートコントラクトに保存する必要があります。

zkTLSが解決した問題しかし、人々はこのOracleに基づくデータ取得ソリューションに2つの問題があることを発見しました：
1. コストが非常に高い：Oracleがチェーン上に送信されるデータが真実で改ざんされていないことを保証するためには、PoS合意メカニズムによって保証されなければなりません。しかし、PoS合意メカニズムの安全性は、ステーキングされた資金の量に基づいています。これが維持にコストをもたらします。また、通常の場合、PoS合意メカニズムには大量のデータ交互冗長性が存在します。データセットがネットワーク内で大量に重複して転送、計算、集約される必要があるため、合意を得られるのです。これもデータ使用コストを引き上げます。そのため、通常、Oracleプロジェクトは顧客を獲得するために、最も主流のデータ（例：BTCなどの主流資産の価格）を無料で維持しますが、専用のニーズには料金を支払う必要があります。これがアプリケーションの革新を妨げ、特に長尾やカスタマイズされたニーズに対して障害をもたらします。
2. 効率が非常に低い：通常、PoSメカニズムの合意には一定の時間が必要で、これがオンチェーンデータの遅延を引き起こします。これは高頻度アクセスの使用シーンにとって不利です。なぜなら、オンチェーンで得られたデータと実際のオフチェーンデータには大きな遅延が存在するためです。
上記の問題を解決するために、zkTLS技術が登場しました。その主なアイデアは、ZKPゼロ知識証明アルゴリズムを導入し、オンチェーンのスマートコントラクトが第三者として機能し、特定のノードが提供するデータが確かに特定のHTTPSリソースにアクセスした後に返されたものであり、改ざんされていないことを直接検証できるようにすることです。これにより、従来のOracleが合意アルゴリズムによって引き起こされる高額な使用コストを回避することができます。
興味のある方は、なぜチェーン上のVM環境にWeb2 API呼び出しの機能を直接組み込まないのかと尋ねるかもしれません。その答えは、できないということです。なぜなら、オンチェーン環境ではすべてのデータの追跡可能性を保証するために、データを閉じた状態に保つ必要があるからです。つまり、合意プロセスにおいて、すべてのノードが特定のデータまたは特定の実行結果の正確性について統一的な評価ロジックを持っている必要があります。もしくは、それは客観的な検証ロジックの一種です。これにより、完全に信頼しない環境で、大多数の善意ノードが冗長なデータから直接結果の真偽を判断できるようになります。しかし、Web2データにはこのような統一的な評価ロジックを構築することが非常に難しいのです。なぜなら、ネットワーク遅延のために、異なるノードがWeb2 HTTPSリソースにアクセスした際に取得した結果が異なる可能性があるためです。これが合意を難しくし、特に高頻度データの領域では困難を増します。加えて、もう一つの重要な問題は、HTTPSプロトコルが依存しているTLSプロトコルの安全性が、クライアントが生成した乱数（クライアントランダム）（キー生成に使用）と鍵共有パラメータに依存していることです。これはサーバー側との暗号化キーの交渉を実現しますが、私たちはオンチェーン環境が公開されていることを知っています。もしスマートコントラクトが乱数と鍵共有パラメータを保持させると、重要なデータが公開され、データのプライバシーが損なわれることになります。
zkTLSは別の手段を採用しています。その構想は、暗号学的保護を通じて、従来のOracleが合意メカニズムに基づいてデータに可用性をもたらす高額なコストを代替することにあります。これはL2のZK-RollupがOP-Rollupを最適化するのに似ています。具体的には、ZKPゼロ知識証明を導入し、オフチェーンの中継ノードから特定のHTTPSリソースを取得し、関連するCA証明書の検証情報、時系列証明、HMACまたはAEADに基づくデータ完全性証明を計算してProofを生成し、オンチェーンで必要な検証情報と検証アルゴリズムを維持することにより、スマートコントラクトが重要な情報を公開することなく、データの真実性、有効性、およびデータソースの信頼性を検証できるようにします。具体的なアルゴリズムの詳細についてはここでは議論しませんが、興味のある方は自分で深く研究してください。
この技術的ソリューションの最大の利点は、Web2 HTTPSリソースの可用性コストを低減したことです。これにより、多くの新しいニーズが刺激され、特に長尾資産のオンチェーン価格取得のコストを低減し、Web2世界の権威あるウェブサイトを利用してオンチェーンKYCを行い、DIDやWeb3ゲームの技術アーキテクチャ設計を最適化するなどの面があります。当然、zkTLSが現在のWeb3企業に与える影響もあります。特に、現在の主流のオラクルプロジェクトに対してです。したがって、この影響に対処するために、ChainlinkやPythなどの業界の巨人が関連する方向の研究に積極的に取り組んでおり、技術の進化の過程で依然として主導的な地位を占めようとしていると同時に、新しいビジネスモデルも生まれています。たとえば、元々の時間課金から使用量課金への移行や、Compute as a Serviceなど。また、ここでの難点は、大多数のZKプロジェクトと同様に、計算コストをどのように低減し、商業的価値を持たせるかです。
総じて、仲間たちが製品設計を行う際に、zkTLSの発展動向に注目し、適切な側面でこの技術スタックを統合することもできるかもしれません。もしかしたら、ビジネスの革新や技術的な構造の面で新しい方向性を見つけられるかもしれません。