テクノロジースタックの拡張: zkTLS の原理と潜在的なアプリケーションシナリオの概要

马里奥看Web3 ｜2025-02-24 6:00

一般的に、zkTLS はゼロ知識証明 (ZKP) と TLS (Transport Layer Security Protocol) を組み合わせた新しい技術です。Web3 トラックでは、主にオンチェーン仮想マシン環境で使用され、第三者を信頼することなく、提供されるオフチェーン HTTPS データの信頼性を検証できます。

著者: @ Web3_Mario

概要: 最近、新しいプロジェクトの方向性を模索しています。製品設計をしているときに、これまで触れたことのないテクノロジースタックに遭遇したので、調査を行い、学習経験を整理して皆さんと共有したいと思います。一般的に、zkTLS はゼロ知識証明 (ZKP) と TLS (Transport Layer Security Protocol) を組み合わせた新しいテクノロジーです。Web3 トラックでは、主にオンチェーン仮想マシン環境で使用されます。第三者を信頼することなく、提供されるオフチェーン HTTPS データの信頼性を検証できます。ここでの信頼性には、データソースが特定の HTTPS リソースからのものであること、返されたデータが改ざんされていないこと、データの有効性が保証されるという 3 つの側面が含まれます。この暗号化実装メカニズムにより、オンチェーンスマートコントラクトはオフチェーン Web2 HTTPS リソースへの信頼できるアクセスを獲得し、データサイロを破壊できます。

TLSプロトコルとは

zkTLS テクノロジーの価値をより深く理解するには、TLS プロトコルの概要を簡単に理解する必要があります。まず、TLS (トランスポート層セキュリティ) は、ネットワーク通信で暗号化、認証、およびデータの整合性を提供し、クライアント (ブラウザなど) とサーバー (Web サイトなど) 間のデータの安全な送信を保証するために使用されます。ネットワーク開発の分野に携わっていない人でも、Web サイトにアクセスすると、一部のドメイン名の先頭に https が付いていて、他のドメイン名の先頭に http が付いていることに気付くかもしれません。後者にアクセスすると、主流のブラウザでは安全ではないというメッセージが表示されます。前者の場合、「リンクはプライベートリンクではありません」などのプロンプトや HTTPS 証明書エラーが発生する可能性が高くなります。このプロンプトが表示される理由は、TLS プロトコルが利用可能であるためです。

具体的には、いわゆる HTTPS プロトコルは、HTTP プロトコルに基づく TLS プロトコルを使用して、情報伝送のプライバシーと整合性を確保し、サーバーの信頼性を検証できるようにします。ご存知のとおり、HTTP はプレーンテキストを送信するネットワークプロトコルであり、サーバーの信頼性を検証できないため、次のようないくつかのセキュリティ上の問題が発生します。

1. お客様とサーバー間で送信される情報は第三者によって監視され、プライバシー漏洩につながる可能性があります。

2. サーバーの信頼性、つまり、リクエストが他の悪意のあるノードによってハイジャックされ、悪意のある情報が返されたかどうかを検証できません。

3. 返された情報の整合性、つまりネットワークの問題によるデータ損失の可能性があるかどうかを検証できません。

TLS プロトコルはこれらの問題を解決するために設計されています。ここで説明させてください。SSL プロトコルをご存知の方もいらっしゃるかもしれません。実は、TLS プロトコルは SSL バージョン 3.1 に基づいて開発されました。業務上の問題で名前が変更されただけですが、実際には同じ流れをたどっています。そのため、場合によっては、この 2 つの単語は互換的に使用されることがあります。

上記の問題を解決するための TLS プロトコルの主なアイデアは次のとおりです。

1. 暗号化通信：対称暗号化（AES、ChaCha20）を使用してデータを保護し、盗聴を防止します。

2. ID 認証: 指定された組織に対してサードパーティが発行したデジタル証明書 (X.509 証明書など) を使用して、サーバーの ID を検証し、中間者攻撃 (MITM) を防止します。

3. データの整合性: HMAC (ハッシュメッセージ認証コード) または AEAD (認証済み暗号化) を使用して、データが改ざんされていないことを確認します。

データ相互作用プロセスにおける TLS プロトコルに基づく HTTPS プロトコルの技術的な詳細を簡単に説明しましょう。プロセス全体は 2 つの段階に分かれています。1 つ目はハンドシェイク段階で、クライアントとサーバーがセキュリティパラメータをネゴシエートし、暗号化されたセッションを確立します。 2 番目は、セッションキーを使用して暗号化された通信を行うデータ転送段階です。具体的なプロセスは次の 4 つのステップに分かれています。

1. クライアントはClientHelloを送信します。

クライアント (ブラウザなど) は、次の内容を含む ClientHello メッセージをサーバーに送信します。

サポートされている TLS バージョン (TLS 1.3 など)
サポートされている暗号化アルゴリズム (AES-GCM、ChaCha20 などの暗号スイート)
クライアントランダム（キー生成に使用）
キー共有パラメータ（ECDHE公開キーなど）
SNI (サーバー名表示) (オプション、HTTPS で複数のドメイン名をサポートするために使用)

その目的は、サーバーにクライアントの暗号化機能を知らせ、セキュリティパラメータを準備することです。

2. サーバーは ServerHello を送信します。

サーバーは、次の内容を含む ServerHello メッセージで応答します。

選択された暗号化アルゴリズム
サーバーランダム
サーバーの証明書（X.509証明書）
サーバーの鍵共有パラメータ（ECDHE公開鍵など）
完了メッセージ（ハンドシェイクが完了したことを確認するために使用）

その目的は、クライアントにサーバーの ID を知らせ、セキュリティパラメータを確認することです。

3. クライアントがサーバーを検証します。

クライアントは次のことを実行します。

サーバー証明書を確認します。証明書が信頼できる CA (証明機関) によって発行されていることを確認し、証明書の有効期限が切れていないか、取り消されていないかを確認します。
共有キーを計算します。独自の ECDHE 公開キーとサーバーの ECDHE 公開キーを使用してセッションキーを計算します。このセッションキーは、後続の通信の対称暗号化 (AES-GCM など) に使用されます。
完了メッセージを送信します。ハンドシェイクデータの整合性を証明し、中間者攻撃 (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 の高い使用コストを回避できます。

Web2 API を呼び出す機能をオンチェーン VM 環境に直接組み込まないのはなぜかと疑問に思う人もいるかもしれません。答えはノーです。なぜなら、オンチェーン環境でクローズドデータを維持する必要がある理由は、すべてのデータのトレーサビリティを確保するためです。つまり、コンセンサスプロセスでは、すべてのノードが特定のデータまたは特定の実行結果の正確性について統一された評価ロジック、または客観的な検証ロジックを持っているということです。これにより、完全に信頼できない環境でも、ほとんどの善意のノードが独自の冗長データに依存して直接的な結果の信頼性を判断できるようになります。ただし、Web2 データでは、ネットワーク遅延により、Web2 HTTPS リソースにアクセスする異なるノードによって取得される結果が異なるため、このような統一された評価ロジックを構築することは困難であり、特に一部の高頻度データ領域ではコンセンサスを得ることが困難になります。さらに、もう 1 つの重要な問題は、HTTPS プロトコルが依存する TLS プロトコルのセキュリティが、暗号化キーに関するサーバーとのネゴシエーションを実現するために、クライアントが生成した乱数 (Client Random) (キー生成用) とキー共有パラメータに依存していることです。ただし、オンチェーン環境はオープンで透明であることがわかっています。スマートコントラクトが乱数とキー共有パラメータを維持すると、キーデータが公開され、データのプライバシーが侵害されることになります。

そこで、zkTLS は別のアプローチを採用します。その考え方は、従来の Oracle ベースのコンセンサスメカニズムの高コストを置き換えて、暗号化保護を通じてデータの可用性を実現することです。 L2 での ZK-Rollup による OP-Rollup の最適化と同様です。具体的には、ZKPゼロ知識証明を導入し、オフチェーンリレーノードがHTTPS経由で取得したリソース、関連するCA証明書検証情報、タイミング証明、HMACまたはAEADに基づくデータ整合性証明を要求して証明を計算し、チェーン上で必要な検証情報と検証アルゴリズムを維持することで、スマートコントラクトはキー情報を公開することなく、データソースの真正性、有効性、信頼性を検証できます。具体的なアルゴリズムの詳細についてはここでは説明しません。興味のある方はご自身で詳しく学習してください。

この技術的ソリューションの最大の利点は、Web2 HTTPS リソースの可用性を実現するためのコストが削減されることです。これにより、特にロングテール資産のオンチェーン価格取得の削減、Web2の世界の権威あるWebサイトを使用したオンチェーンKYCの実行、そしてDIDとWeb3ゲームの技術アーキテクチャ設計の最適化において、多くの新たな需要が刺激されました。もちろん、zkTLS は既存の Web3 企業、特に現在の主流の Oracle プロジェクトにも影響を与えていることがわかります。そのため、この影響に対処するために、ChainlinkやPythなどの業界大手は、関連方向の研究を積極的に進め、技術の反復プロセスで優位な地位を維持しようとしています。同時に、従来の時間ベースの課金から使用量ベースの課金への切り替え、サービスとしてのコンピューティングなど、新しいビジネスモデルも生まれます。もちろん、ここでの難しさはほとんどの ZK プロジェクトと同じで、コンピューティングコストを削減し、それを商業的に価値のあるものにする方法です。

まとめると、製品を設計する際には、zkTLS の開発にも注意を払い、このテクノロジースタックを適切な側面に統合することもできます。おそらく、ビジネスイノベーションと技術アーキテクチャの新しい方向性が見つかるかもしれません。