技術スタックの拡張：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バージョンに基づいて開発されたものであり、商業的な理由から名前が変更されたに過ぎませんが、実際には一貫しています。そのため、ある文脈では、両方の用語が互換的に使用されることがあります。

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など）
• ランダム数（Client Random）（キー生成に使用）
• キー共有パラメータ（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は何を解決したのか

しかし、人々はこのオラクルに基づくデータ取得の方法に2つの問題があることに気づきました：

1. コストが高すぎる：オラクルがチェーン上に伝達するデータが本物であり、改ざんされていないことを保証するためには、PoSコンセンサスメカニズムによって保証される必要があります。しかし、PoSコンセンサスメカニズムの安全性は、ステーキングされた資金の量に基づいているため、維持にコストがかかります。また、通常、PoSコンセンサスメカニズムには大量のデータ交互冗長性が存在します。データセットがネットワーク内で大量に繰り返し転送、計算、集約される必要があるため、コストが上昇します。そのため、通常、オラクルプロジェクトは顧客を獲得するために、BTCなどの主流資産の価格など、最も主流なデータを無料で維持することが多いです。特定のニーズには、支払いを通じて対応する必要があります。これがアプリケーションの革新を妨げ、特に長尾のカスタマイズされたニーズに対して障害となります。

2. 効率が低すぎる：通常、PoSメカニズムのコンセンサスには一定の時間が必要であり、これがチェーン上のデータの遅延を引き起こします。これは、高頻度のアクセスが求められる使用シーンには不利です。なぜなら、チェーン上で得られるデータと実際のオフチェーンデータとの間に大きな遅延が存在するからです。

これらの問題を解決するために、zkTLS技術が登場しました。その主な考え方は、ZKPゼロ知識証明アルゴリズムを導入することで、チェーン上のスマートコントラクトが第三者として、特定のノードが提供するデータが実際に特定のHTTPSリソースにアクセスした後に返されたデータであり、改ざんされていないことを直接検証できるようにすることです。これにより、従来のオラクルがコンセンサスアルゴリズムによって引き起こされる高額な使用コストを回避できます。

一部の方々は、なぜチェーン上のVM環境にWeb2 API呼び出しの能力を直接組み込まないのかと疑問に思うかもしれません。答えは、できないからです。チェーン上の環境が閉じたデータを維持する必要がある理由は、すべてのデータの追跡可能性を保証するためです。つまり、コンセンサスプロセスにおいて、すべてのノードが特定のデータまたは特定の実行結果の正確性に対して統一された評価ロジック、または客観的な検証ロジックを持つ必要があります。これにより、完全に信頼を排除した環境下で、大多数の善意のノードが自らの冗長なデータを基に直接結果の真偽を判断できるようになります。しかし、Web2データに関しては、このような統一された評価ロジックを構築することは非常に困難です。なぜなら、ネットワークの遅延などの理由により、異なるノードがWeb2 HTTPSリソースにアクセスして得られる結果が異なる可能性があるからです。これが特に高頻度データ領域において、コンセンサスを難しくします。さらに、もう一つの重要な問題は、HTTPSプロトコルが依存するTLSプロトコルの安全性が、クライアントが生成するランダム数（Client Random）（キー生成に使用）とキー共有パラメータに依存しており、サーバー側との暗号化キーの協議を実現することです。しかし、チェーン上の環境は公開されているため、スマートコントラクトがランダム数とキー共有パラメータを維持すると、重要なデータが露出し、データのプライバシーが損なわれます。

zkTLSは別の手段を採用しています。その構想は、暗号学的な保護を通じて、従来のオラクルがコンセンサスメカニズムに基づいてデータに可用性をもたらす高額なコストを代替することです。これは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の発展動向にも注目し、適切な分野でこの技術スタックを統合することで、ビジネスの革新や技術的なアーキテクチャの面で新しい方向性を見出すことができるかもしれません。