元のタイトルを転送する「Web3でWeb2データの使用を実際にプライベートかつ検証可能にする方法は？」

web3が新しいインターネットであると主張する多くの人々は、「読む、書く、所有する」というフレーズでそれを定義しています。「読む」と「書く」の部分は明確ですが、データの「所有」という点に関しては、今日、私たちがほとんど何も所有していないと言えます。

ユーザーデータはしばしば企業によって盗まれ、彼らに利益をもたらす方法で使用されます；インターネット上にあるものは実際には私たちの所有物ではありません。

ただし、Web3だけが存在する世界に移行するわけにはいかない。いいえ、私たちはまだ共有する必要がありますが、必要なものだけです。

弱いパスポートを持つ人として、私はeビザを申請し、特定のビザに適格であることを証明するために自分自身についての詳細を延々と提出することになってしまいます。そして、いつも自分自身に問いかけることになります：

• 特定の収入水準を確認する必要があるだけなのに、なぜ私は全銀行取引明細書を共有する必要がありますか？

• なぜ、この国のホテルを予約したことを証明するだけでなく、正確なホテル予約を提出する必要がありますか？

• 現在の国の居住地を確認する必要があるだけなのに、なぜ私はフルパスポートの詳細を提出する必要がありますか？

ここでの主な懸念事項は2つあります: サービスは必要以上に多くを知っており、提供しているデータはプライベートではありません。しかし、これは暗号通貨のセキュリティとプライバシーにどのように関連していますか？

Web3は、web2データなしでは成功しないでしょう。

ほとんどの方がご存知のように、スマートコントラクトは基本的にBTC、ETH、SOL、または他のどんな資産がいくらであるかを知る術がありません。このタスクはオラクルに委任されており、オラクルは常に外部世界からの公開データをスマートコントラクトに投稿しています。

イーサリアムの世界では、この役割はほぼgateに独占されています@chainlink彼らのオラクルネットワークと連携して、単一のノードに依存しないようにします。したがって、特定の資産の価格を知る以上のユースケースにWeb2データが本当に必要です。

ただし、これは公開データにのみ適用されます。しかし、銀行口座やTelegramアカウントを安全に接続し、公開されていないが私にとってはプライベートな機密情報を共有したい場合はどうすればよいですか？

最初に考えたのは、このデータをブロックチェーンに取り込み、個人データが安全であることを証明するにはどうすればよいかということです。

残念ながら、サーバーは送信する応答に署名しないため、スマート契約でそのようなものを信頼性を持って検証することはできません。

コンピュータネットワークを介した通信を保護するプロトコルは、TLS(Transport Layer Security)と呼ばれます。聞いたことがなくても、毎日使っています。たとえば、この記事を読んでいると、ブラウザのアドレスバーに「https://」が表示されます。

「http://」接続(「s」なし)でWebサイトにアクセスしようとすると、ブラウザは接続が安全でないことを警告します。リンクの「s」はTLSの略で、接続を保護し、プライバシーを確保し、送信しているデータを盗まれるのを防ぎます。

2. その接続はすでに安全です。Web3で輸送して使用するだけでいいのではありませんか？

以前に述べたように、私たちは検証の問題に直面しています：サーバーは送信する応答に署名しないため、実際にデータを検証することができません。

データソースがデータを共有することに同意したとしても、標準のTLSプロトコルではそのデータの信頼性を他者に証明することはできません。単に応答を渡すだけでは不十分です。クライアントは簡単にデータをローカルで変更でき、これらの応答を完全に公開することは、ユーザーのプライバシーを危険にさらします。

検証可能性の問題に対する 1 つのアプローチは、zkTLS と呼ばれる TLS の拡張バージョンです。

zkTLSの動作メカニズムはTLSと似ていますが、わずかに異なります。こういった仕組みです。

• 安全なTLS接続を介してウェブサイトを訪れ、必要なリクエストを送信します。

• zkTLSは、データを検証するzkプルーフを生成し、ユーザーが証明したい特定の詳細のみを明らかにしながら、他のすべてをプライベートに保ちます。

• 生成されたzkプルーフは、提供された情報が正しいことを他のアプリケーションが確認および検証するために使用されます。

zkTLSとは、zkTLSを利用するプロジェクトのことですが、さまざまなソリューションを使用したデータの検証可能性にはさまざまなアプローチがあります。

1. TEE (Trusted Execution Environment)
2. MPC (Multi-Party Computation)
3. プロキシ

興味深いことに、それぞれのアプローチは独自のユースケースを紹介します。では、それらはどのように異なるのでしょうか？

3. なぜzkTLSには単一の標準がないのですか？それらはどう異なりますか？

zkTLSは1つの技術ではない。なぜなら、秘密のウェブデータを露出せずに検証することは複数のアプローチから取り組むことができ、それぞれには独自のトレードオフがあるからだ。核心のアイデアはTLSを証明と拡張することだが、どのようにそれらの証明を生成し、検証するかは基礎となるメカニズムに依存する。

以前に述べたように、TEE-TLS、MPC-TLS、またはProxy-TLSを使用する主なアプローチが3つあります。

TEEは、データが処理され、証拠が生成される安全な「ブラックボックス」を作成するために、Intel SGXやAWS Nitro Enclavesなどの専用ハードウェアに依存しています。ハードウェアは、データがプライベートであり、計算が改ざんされないことを保証します。

TEEベースのzkTLSセットアップでは、TEEがプロトコルを実行し、TLSセッションの実行とコンテンツを証明します。検証者はTEE自体であり、信頼はTEEの製造業者と攻撃に対する耐性に依存します。このアプローチは、計算およびネットワークのオーバーヘッドが低く効率的です。

ただし、重大な欠陥があります。ハードウェアメーカーを信頼する必要があり、TEEの脆弱性（サイドチャネル攻撃など）がシステム全体を破壊する可能性があります。

Proxy-TLSとMPC-TLSは、より広範なユースケースを持つため、最も広く採用されています。プロジェクトはgateのようなものです@OpacityNetworkand@reclaimprotocol、その上に構築されている @eigenlayer,これらのモデルを活用して、データセキュリティとプライバシーを確保し、さらに経済セキュリティの追加レイヤーを提供します。

これらのソリューションがどれだけ安全か、zkTLSプロトコルが可能にするユースケース、そして今日すでに稼働しているものを見てみましょう。

4. MPC-TLSとOpacity Networkの特別な点は何ですか？

TLSハンドシェイク中（クライアントとサーバーが暗号化キーを共有することで安全に通信方法に合意する場面）に、ウェブサイトの役割は変わらず、しかし、ブラウザの処理は異なることを行います。

独自の秘密鍵を生成する代わりに、MPCを使用してノードのネットワークを介して多重当事者秘密鍵を作成します。この鍵はブラウザのためのハンドシェイクを実行し、単一のエンティティが共有鍵を知らないことを保証します。

暗号化および復号には、すべてのノードとブラウザが協力する必要があり、データがウェブサイトに到達する前または離れる前に、それぞれが順次暗号化の一部を追加または削除します。MPC-TLSは強力なセキュリティを提供し、誰もがすべての権力を持っていないように分散することができます。

Opacity Networkがクラシックを強化します @tlsnotary信頼の問題を最小限に抑えるためのセーフガードを追加することで、フレームワークを構築します。次のような複数のセキュリティ対策を採用しています。

1. web2アカウントIDのオンチェーン検証
2. コミットスキーム
3. リベール計画
4. ランダムMPCネットワークサンプリング
5. 試行の検証可能なログ

アカウントIDは、web2システムでは静的であり、10個の異なるノードが所有権を確認する必要がある委員会による証明を可能にします。これにより、アカウントがユニークなウォレットにリンクされ、異なるウォレットを使用して共謀ノードを見つけるための繰り返し試行を防ぎます。

下の詳細でOpacityがどのように機能するかを見ることができます。

透過性ノードはTEE内で動作し、TEEが安全であればほぼ不可能な共謀を行います。TEE以外にも、OpacityはAVSを活用するためにEigenlayerを使用し、ノードが32 stETHを再ステークする必要があります。違反行為に対して即時にスラッシュを行い、クールダウンに関連する遅延を回避します。

OpacityがMPCとTEEの両方を使用していることがわかりますが、MPCはzkTLSに使用されているため、TEEは基本的にノードセキュリティに使用されているため、それはまだMPC-TLSと呼ばれています。

ただし、TEEが失敗した場合、ノードがMPC内で共謀する可能性があるため、このような行動を防ぐために追加の経済セキュリティ層が必要となります。

それがOpacityが告発者メカニズムを開発している理由でもあります。証明できるユーザーは、公証人が不適切に行動したことを証明できる場合、公証人のステークに課せられた罰金の一部を報酬として受け取ることができます。

その統合の簡単さ、セキュリティ、およびプライバシーの提供により、Opacityは消費者、DeFi、AIエージェントセクター全体にわたるさまざまなプロトコルの注目を集めています。

チームから @earnos_ioブランドがユーザーにエンゲージメントやタスク完了の報酬を提供できるプラットフォームを開発中です。EarnOSは、個人情報を明らかにせずに人気のあるアプリを通じて特性を証明するOpacityの技術を使用し、ユーザーがプライバシーを保ちながら報酬を獲得できるようにします。

Opacityは、また統合されています@daylightenergy_プロトコルは、ユーザーがクリーンエネルギーのソリューションに貢献して報酬を得ることができる分散型電力ユーティリティネットワークを開発しています。Opacityのおかげで、ユーザーは専用のハードウェアなしにチェーン上でエネルギーデバイスの所有権を証明することができます。

透明性はAIエージェントと統合することさえ可能であり、現在重大な課題に直面している分野にさらなる検証可能性と透明性をもたらすことができます。zkTLSが最近になって統合されました@elizaOS, プライバシーの損失なしに検証可能なAIインタラクションを可能にします。

ただし、TEE-TLSとMPC-TLSはzkTLSの2つのバリエーションに過ぎず、Proxy-TLSという3番目のバリエーションもあります。このモデルの最も有名な表現であるReclaim Networkを使用する。では、他の2つのバリエーションと比較して、技術的にはどのように異なり、Proxy-TLSによって有効になるユースケースはどれですか？

5. Proxy-TLSとリクレームプロトコルの特別な点は何ですか？

インターネット上で一般的なHTTPSプロキシは、その内容をアクセスせずに暗号化されたトラフィックを転送します。zkTLSプロキシモデルでは、わずかな追加でほぼ同じように機能します。

•ブラウザはプロキシを介してWebサイトにリクエストを送信し、プロキシもWebサイトの応答を処理します。

• プロキシはすべての暗号化された交換を見て、それらの信頼性を証明し、それがリクエストかレスポンスかを記録します。

• ブラウザはその後、共有キーでこのデータを暗号化できることを示すzkプルーフを生成し、キーを明らかにせずに結果を示します。

•これは、データを意味のあるものに変える偽のキーを作成することはほぼ不可能であるため、復号化できることを示すだけで十分であるためです。

キーを公開すると、ユーザー名やパスワードなどの機密データを含むすべての以前のメッセージが危険にさらされます。プロキシTLSは非常に高速で手頃な価格であり、大容量のデータをうまく処理するため、高スループット設定に理想的です。

ほとんどのサーバーは、異なるIPアドレスに基づいてアクセスを制限しないため、この方法はかなり広く適用されています。

Reclaim Protocolは効率的なデータ検証のためにProxy-TLSを使用し、大規模なプロキシブロックを防ぐためにプロキシを使用してWeb2ファイアウォールをバイパスします。

Here’s how it works:

主な問題は共謀です：ユーザーと証明者が共謀すると、基本的に何でも署名し、悪意を持って行動することができます。これを緩和するために、Reclaim は、ランダム性を導入し、そのような悪用をブロックするために選択された検証者のサブセットを組み込んでいます。

Reclaimは、EigenのAVSを使用してデータの検証を分散化します。EigenLayerオペレーターはアテスターとして機能できますが、サービスのアテステーションロジックを指定するには、独自のAVSをデプロイする必要があります。

Reclaimは、交通アプリ用のライドシェアリングデータのインポート、ブロックチェーン経済のためのオフチェーンデータのブリッジ、国民IDデータによるIDの検証、開発者ツールを介したカスタムデータソリューションの作成など、独自のユースケースを可能にするプラットフォームです。

The Reclaim ecosystem is home to 20+ projects, but I’d like to highlight 4 of them in the money markets, digital identity, consumer, and hiring sectors.

@3janexyzBaseは、暗号通貨ユーザーに対して信用力と将来のキャッシュフローを評価し、オンチェーンおよびオフチェーンの金融データを使用して、担保付きクレジットラインを提供する、最初のクレジットベースのマネーマーケットです。

3Janeは、VantageScore、Cred、Coinbase、およびPlaidからのクレジットデータを検証するためにReclaimのプロキシモデルを使用し、このデータのプライバシーを確保します。

credit scores with zkTLSを使用するもう一つの用途は、@zkme_‘s feature, zkCreditScore. It uses Reclaim Protocol to get your US credit score securely with zkTLS. This lets zkMe check a user’s credit score and make unique soulbound tokens (SBTs) to store this data.

信用スコア以外のユースケースはあり得ますか？もちろん、あります。

私たちは取ることができます @zkp2p例として、ユーザーのTicketmasterデータを検証するためにReclaimを活用してユーザーの支払いを検証する消費財マーケットプレイスです。

同時に、@bondexapp, which is one of the most popular job boards in crypto, uses Reclaim for getting proof of work of profiles, verifying that the data is real, private, and verifiable.

zkTLSで可能なユースケースを見ると、TLSトランスクリプトをオンチェーンで検証する機能は、すでに多くの新機能を解き放っており、ユーザーは大企業の許可を必要とせずに自分のデータを管理することができます。

さらに重要なことに、zkTLSは、個人データがあなたに対して使用されないようにするために作られています。では、これからどこに向かっているのでしょうか？

6. zkTLSはこれからも続くのでしょうか？

まだやるべきことはありますが、さまざまなzkTLSプロトコルが、ユーザーに電力を再分配する新しいユースケースをすでに導入しています。

@Tim_Roughgardena16zクリプトポッドキャストでzkプルーフが1985年に提案されましたが、ブロックチェーンアプリケーションでの人気を博していることが強調されました。これは、数百人の開発者がプルーフのサイズとコストを削減するために取り組んだ成果です。

そして今、ブロックチェーン業界からの貢献は、単なる暗号通貨そのものを超えて、他の領域でも活用されています。

zkTLSについても同様のストーリーが展開されると予想しています。まずWeb3での実装から始まり、その先に広がっていくでしょう。なぜなら、今の状況では私たちは「読む」ことも「書く」こともしていますが、ほとんど保護されておらず、自分自身のデータさえほとんど「所有」していないからです。

免責事項：

1. この記事は[から転載されましたパヴェル・パラモノフ]. すべての著作権は元の著者に帰属します [Pavel Paramonov]. If there are objections to this reprint, please contact the gate Learnチーム、そして彼らは迅速に対応します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. gate Learn チームは、記事を他の言語に翻訳します。翻訳された記事のコピー、配布、または盗用は、特に言及されていない限り禁止されています。