オリジナル記事： @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、ChaCha 20) を使用してデータを保護し、盗聴を防止します。
2. ID 認証: 指定された組織に対してサードパーティが発行したデジタル証明書 (X.509 証明書など) を使用して、サーバーの ID を検証し、中間者攻撃 (MITM) を防止します。
3. データの整合性: HMAC (ハッシュ メッセージ認証コード) または AEAD (認証済み暗号化) を使用して、データが改ざんされていないことを確認します。
データ相互作用プロセスにおける TLS プロトコルに基づく HTTPS プロトコルの技術的な詳細を簡単に説明しましょう。プロセス全体は 2 つの段階に分かれています。1 つ目はハンドシェイク段階で、クライアントとサーバーがセキュリティ パラメータをネゴシエートし、暗号化されたセッションを確立します。 2 番目は、セッション キーを使用して暗号化された通信を行うデータ転送段階です。具体的なプロセスは 4 つのステップに分かれています。
1. クライアントはClientHelloを送信します。
クライアント (ブラウザなど) は、次の内容を含む ClientHello メッセージをサーバーに送信します。
サポートされている TLS バージョン (TLS 1.3 など)
サポートされている暗号化アルゴリズム (AES-GCM、ChaCha 20 などの暗号スイート)
クライアントランダム（キー生成に使用）
キー共有パラメータ（ECDHE公開キーなど）
SNI (サーバー名表示) (オプション、HTTPS で複数のドメイン名をサポートするために使用)
その目的は、サーバーにクライアントの暗号化機能を知らせ、セキュリティ パラメータを準備することです。
2. サーバーは ServerHello を送信します。
サーバーは、次の内容を含む ServerHello メッセージで応答します。
選択された暗号化アルゴリズム
サーバーランダム
サーバーの証明書（X.509証明書）
サーバーの鍵共有パラメータ（ECDHE公開鍵など）
完了メッセージ（ハンドシェイクが完了したことを確認するために使用）
その目的は、クライアントにサーバーの ID を知らせ、セキュリティ パラメータを確認することです。
3. クライアントがサーバーを認証します。
クライアントは次のことを実行します。
サーバー証明書を確認します。証明書が信頼できる CA (証明機関) によって発行されていることを確認し、証明書の有効期限が切れていないか、取り消されていないかを確認します。
共有キーを計算します。独自の ECDHE 公開キーとサーバーの ECDHE 公開キーを使用してセッション キーを計算します。このセッション キーは、後続の通信の対称暗号化 (AES-GCM など) に使用されます。
完了メッセージを送信します。ハンドシェイク データの整合性を証明し、中間者攻撃 (MITM) を防止します。
その目的は、サーバーの信頼性を確保し、セッション キーを生成することです。
4. 暗号化通信を開始します。
クライアントとサーバーは、ネゴシエートされたセッション キーを使用して暗号化されて通信するようになりました。
対称暗号化 (AES-GCM、ChaCha 20 など) を使用してデータを暗号化し、速度とセキュリティを向上させます。
データ整合性保護: 改ざんを防ぐために 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 の開発にも注意を払い、このテクノロジー スタックを適切な側面に統合することもできます。おそらく、ビジネス イノベーションと技術アーキテクチャの新しい方向性が見つかるかもしれません。
