Chainlink DECO を理解する: プライバシー保護のための Oracle

0. イントロ
Web3 はデータの価値を再形成しましたが、ブロックチェーンの分散構造は閉じた決定論的なシステムであり、スマート コントラクトは外部 API 呼び出しの機能を実装していません。その結果、スマート コントラクトが外部データを取得できるようにするために、Oracle メカニズムが誕生しました。 。
オフチェーンのデータをチェーンにアップロードすることは難しくありません。難しいのは、テクノロジーとメカニズムを通じて信頼を設計し生み出すことです。オラクルの問題では、データソースから処理、価格供給までの信頼の問題を解決する必要があります。
公的に認められたオラクルになるための基本条件は、分散化、つまり単一障害点とデータ検証が許可されるかどうかです。チェーン分散化の一般的なソリューションは、複数のデータ ノードを使用して分散型オラクル ネットワークを形成し、各ノードがデータを収集し、合意に達した後にブロックチェーン上のスマート コントラクトに入力します。
 
チェーンリンクのアーキテクチャ
オラクルの現在の主な用途は、DeFi に価格フィードを提供し、原資産の価格を安全、タイムリー、正確に更新することです。 DefiLlama のデータによると、Chainlink は市場最大のオラクル ソリューションの 1 つであり、本稿執筆時点で保証総額は約 110 億ドルで、市場全体の 46% を占めています。
 
オラクル市場​​データ
ブロックチェーンの発展に伴い、オフチェーンデータに対する需要はますます高まっており、単に DeFi に価格を提供するだけでは開発者のニーズを満たすことができなくなりました。現実世界と Web2 のデータの大部分は公的にアクセスできませんが、革新的な Web3 アプリケーション シナリオ (信用貸付、ソーシャル ネットワーキング、DID、KYC/AML など) を構築する必要があります。したがって、新世代のオラクルでは、スマート コントラクトがプライバシーを保護しながら機密データを含む複雑なユースケースをサポートできるようにする必要があります。
DECOは、この方向におけるChainlinkのソリューションであり、ゼロ知識証明技術を使用して、ユーザーがデータを公衆やオラクルノード自体に明らかにすることなく、スマートコントラクトに対するオフチェーンのプライベートデータ証明を生成できるようにします。 DECO は既存の API に接続でき、エンドユーザー認証が必要な場合でも (たとえば、銀行口座残高の取得にはログインが必要です)、API データ プロバイダーによる変更は必要ありません。現在はアルファ段階に達し、複数のパートナーと概念実証をテストしています。
1. 背景
TLS と ZKP に関する必要な背景はここで提供され、DECO はこれらのプロトコルの上に構築されます。
1.1 TLS
TLS (Transport Layer Security) は、アプリケーション プロトコル層と TCP/IP 層に位置する、インターネット通信のプライバシーとデータ セキュリティを促進するために設計された、以前は SSL であった強力で広く導入されているセキュリティ プロトコルです。その中で、主な使用例は次のとおりです。 Web アプリケーションとサーバー間の通信を暗号化します。
HTTP 経由の通信はプレーン テキストで行われるため、盗聴、改ざん、なりすましの危険性があります。 TLS を使用すると、ユーザーが Web サイトに送信する HTTP データ (クリック、フォームへの入力など) と Web サイトがユーザーに送信する HTTP データが暗号化され、受信者はキーを使用して暗号化されたデータを復号化する必要があります。 HTTPS は HTTP プロトコルに基づいて TLS 暗号化を実装しており、Web サイトの標準的な方法です。Web サイトはソース サーバーに TLS 証明書をインストールする必要があり、ブラウザはすべての非 HTTPS Web サイトを安全ではないとマークします。
 
非HTTPSウェブサイト
TLS の基本的な考え方は、公開キー暗号化を使用することです。Web サイトによって公的に共有される TLS/SSL 証明書には公開キーが含まれており、秘密キーはソース サーバーにインストールされ、Web サイトによって所有されます。クライアントはまずサーバーにデジタル証明書の公開キーを要求し、次にその公開キーを使用して情報を暗号化します。サーバーは暗号文を受信した後、独自の秘密キーを使用して暗号化を解除します。
ここで問題が発生します。公開キー暗号化には多くの計算が必要です。セッションにかかる時間を短縮するために、クライアントとサーバーはセッションごとに「セッション キー」を生成し、それを使用して情報を暗号化します。 「セッションキー」は対称的に暗号化されるため処理速度が非常に速く、サーバー公開鍵は「セッションキー」自体の暗号化にのみ使用されるため、暗号化処理にかかる時間が短縮されます。
したがって、TLS プロトコルは主に 2 つの層に分けることができます。
認証キーのネゴシエーションのためのハンドシェイク プロトコル: 平文通信、非対称暗号化による相互確認、相互検証、使用する暗号化アルゴリズムの確立、および契約の対称暗号化を記録するための一貫したセッション キーの生成
対称的に暗号化された送信用のレコード プロトコル: データ送信の機密性と完全性を保護するプロトコルの本体
 
TLSプロトコルスタック
TLS 暗号スイート (CipherSuite) は、次の 4 つのアルゴリズムの組み合わせです。
認証: ID の信頼性を判断します。主流は RSA/DSA/ECDSA です。
鍵交換: 通信当事者が暗号化に使用する鍵をネゴシエートします。主流は ECDHE です。
暗号化: 通信には対称暗号化が使用され、GCM を使用する傾向が見られます。
MAC（Message Authentication Code、Message Authentication Code）：データの整合性やデータが改ざんされていないかを検証するために使用されるもので、SHA256/SHA384/SHA1などが主流です。
TLS は非常に強力ですが、制限があります。データ送信には対称暗号化が使用されるため、ユーザーはアクセスするデータが実際に特定の Web サイトからのものであることを第三者に証明できません。データに署名する機能も同様です。直感的な例としては、アリスの身元情報が多くの Web サイトのサーバーに保存されていることが挙げられます。アリスが 18 歳以上であることは簡単に確認できますが、アリスがこれをボブに証明するのは困難です。アリスは Web サイトからスクリーンショットを撮ることができましたが、スクリーンショットは簡単に偽造され、スクリーンショットが本物であることが証明されたとしても、アリスが 18 歳以上であるという事実だけでなく、アリスの正確な生年月日などの情報が暴露されてしまいます。
オラクル マシンは、オフチェーンのプライベート データの出所を証明し、プライバシーを漏らすことなくスマート コントラクトで使用できるように、分散型 (Web サイト サーバーなどの単一点に依存しない) である必要があります。ゼロ知識証明はこれらの機能の実現に役立ちます。
1.2 クリック単価
Zero Knowledge Proof (ZKP) はブロックチェーンで広く注目されており、その主な用途は ZK-Rollup (ZK の Validity Proof を使用せず、拡張効率を向上させるためにアルゴリズム設計に多くの妥協が加えられています) とプライバシー技術です。 （リアルzk）。ゼロ知識証明を使用すると、証明者は、解決策 (証人) に関する追加情報を明らかにすることなく、特定の計算問題 (ステートメント) を解決できる解決策 (証人) があることを検証者に証明できます。
一般的な ZK システムは、フロントエンドとバックエンドに分けることができます。
フロントエンド: コンパイラ。検証が必要なステートメントをドメイン固有言語 (DSL) に書き込み、算術回路などの ZK に適した形式にコンパイルします。
バックエンド: Marlin、Plonky2、Halo2 など、回路の正しさをチェックする証明システム、対話型デモンストレーション システム。
 
ZKシステム
ブロックチェーンのようなオープン システム上でインタラクティブな質問を構築するプロセスは非常に複雑であり、その証明はいつでも誰でも検証する必要があるため、ブロックチェーン アプリケーション上の ZK システムは通常非インタラクティブであり、Fiat-Shamir-ヒューリスティック変換を非対話的に使用できます。
2. DECOの仕組み
DECO は HTTPS/TLS プロトコルに基づいて拡張されており、サーバーを変更せずに使用できるようになります。
DECO の核となるアイデアは、Prover (DECO Prover を実行するユーザーまたは Dapp)、Verifier (DECO Verifier を実行する Chainlink オラクル)、およびサーバー (データプロバイダー) の間で新しい 3 者間ハンドシェイク プロトコルを構築することです。
来歴: 証明者が Web サーバーから情報をクエリすると、検証者は対話プロセスを目撃し、TLS セッション データに対して証明者によって作成されたコミットメントを受け取ります。これにより、検証者は情報の真のソースを検証できます。
プライバシー: データにプライバシーが必要ない場合、Prover は開発者がデータを Dapp に追加するためにデータを復号化できる鍵を Verifier に直接提供できます。プライバシーが必要な場合、Prover は ZKP を使用して開発者にデータを漏洩しない証明を生成します。 Dappに追加します。
 
DECOの例
具体的には、DECO プロトコルは 3 つのフェーズで構成されます。
3 者間のハンドシェイク、証明者、検証者、およびサーバーは、データが偽造できないことを保証するために特別な形式でセッション キーを確立します。
クエリの実行では、証明者はプライベート パラメータ θs (アカウント パスワード、API キーなど) を使用してクエリを使用し、サーバーからのデータをクエリします。
証明の生成、証明者は応答が必要な条件を満たしていることを証明します。
 
DECOアーキテクチャ
2.1 三者間のハンドシェイク
注: 次の手順は、AES-CBC-HMAC 暗号化アルゴリズムに基づいており、TLS 1.3 は暗号化アルゴリズムとしてより安全な AEAD のみを保持し、暗号化と MAC に 1 つのキーを使用し、MAC キーは必要ありません。ただし、TLS 1.3 の主要な独立性により、同様の複雑さを持つ 3 者間ハンドシェイク プロトコルも構築できます。
証明者 P は、MAC キーを取得した後にコミットメントを行うことができません。そうでないと、データを偽造したり改ざんしたりする可能性があるため、3 者ハンドシェイクのアイデアは、証明者 P と検証者 V を一緒に TLS クライアントとして使用して、共有鍵を確立することです。 TLS サーバー S の MAC キー。 MAC キー k はクライアント側で分割され、証明者は kp を保持し、検証者は kv を保持します (k=kp+kv)。同時に、P は対称暗号化アルゴリズムに使用される暗号化キー k^{Enc} も保持します。 Verifier が悪さをしなければ、スリーパーティ ハンドシェイク プロトコルによってデータが偽造不可能であることが保証されます。
2.2 クエリの実行
ハンドシェイク後、MAC キーは秘密に共有されるため、P と V は対話型プロトコル (二者間秘密計算) を実行し、プライベート パラメーター θs を使用して暗号化されたクエリ TLS メッセージ Query Q を構築します。次に、P は標準 TLS クライアントとして Q を S に送信します。このプロセスでは、P のみが S と通信し、送信されたクエリは V に漏洩することはありません。
S から応答 R を受信した後、P は暗号文 R ^ を V に送信してセッションにコミットし、V の kv を受信して​​応答 R の信頼性を検証します。
2.3 証明生成
次に、P は、暗号文 R ^ に対応する平文 R が特定の属性を満たすことを証明する必要があります。プライバシーが必要な場合は、暗号鍵 k^{Enc} を直接明らかにする必要があります。使用済み。
平文が複数のデータ ブロック R=(B1,...,Bn) で構成されている場合、DECO は選択的開始を使用してゼロ知識証明を生成します。
特定のデータ行のみを明らかにする: 他のデータ ブロックを明らかにせずに、R の i 番目のデータ ブロックが Bi であることを証明します。
プライベート データを含むデータ行を非表示にする: Bi が削除されることを除いて、R_{-i} と R が等しいことを証明します。
 
ただし、多くの場合、Verifier は、明らかにされた部分文字列が正しいコンテキストに表示されるかどうかを検証する必要があり、上記の方法ではコンテキストの整合性を保護するには十分ではありません。これを補うために、DECO はゼロ知識 2 段階解析と呼ばれるテクノロジーを利用します。Prover はセッション データをローカルで解析し、Verifier を納得させることができる最小の部分文字列を決定し、そのデータを Verifier に送信します。このようにしてプライバシーが確保されます。
ニート非インタラクティブ (NIZK) ゼロ知識証明は、通常、計算とメモリの点で証明者側に高いオーバーヘッドをもたらします。 DECOによって実行されるZKPのVerifierが指定されているため(Chainlinkのオラクル)、メモリ使用量の削減、信頼できる設定の回避、安価な計算など、より効率的な対話型のゼロ知識証明を使用できます。
現在のアルファ テストでは、DECO は引き続き Dapp を使用して証明者として機能します。今後の反復では、証明者をエンド ユーザー (携帯電話など) によってローカルに展開するか、信頼できる実行環境 (TEE) に展開できるようにする予定です。
3. 応用
DECO は、データのプライバシーを確​​保しながらユーザーのオフチェーン ID 情報の有効性を検証できるため、経済から社会に至るまで多くの革新的な Web3 アプリケーション シナリオが可能になります。
自己ホスト型の社会的回復/法的身元証明 (誰ですか): DECO を使用して、社会的回復の保護者の 1 つとして機能する成熟した認証メカニズムをすでに備えている機関の Web サイト (銀行、ソーシャル メディア) を活用します。
 
信用貸付/資金証明（所持金）: Teller は、DECO プロトコルを使用して、オフチェーン銀行口座内のユーザーの資産残高が融資に必要な動的な最小しきい値を超えていることを証明する DeFi 信用貸付プロトコルです。
 
フォロワー証明/インタラクション証明 (誰とやりとりしたか): Clique は、オフチェーン ユーザーの影響力、さまざまなソーシャル メディア プラットフォーム (Twitter API などを使用したものなど) にわたるロイヤルティ、投稿の詳細な分析を提供するソリューションを開発しているソーシャル オラクルです。
デジタル ID/ソーシャル ID 証明 (オンライン アカウントを持っている): PhotoChromic は、DECO を使用して Web3 ユーザーを Twitter または Discord ソーシャル アカウントにバインドするデジタル ID ソリューションであり、そのプロセスで基礎となる個人を特定できるデータを公開することなく、アプリケーションは実際のデータをフィルタリングできます。ユーザー。
シビル攻撃、SBT、KYC/AML などに対する DAO の耐性
4. 他のプレイヤー
Axiom は、チェーンからの検証可能なデータ ソースを完全に使用して、Uniswap TWAP 用の ZK オラクルを構築します。これはインデックス作成に似ており (例: Hyper Oracle)、DECO は競合するものというよりも補完的です。ますます多くの経済活動がチェーン上で純粋に発生します。 -チェーンオラクルは一方向であり、ますます多くのオフチェーンデータをチェーンにアップロードする必要があり、オフチェーンプライバシーオラクルも一方向です。
Empiric Network は、ZK コンピューティングを使用してオラクル全体をチェーン上に配置します。データが通過する必要があるオフチェーン インフラストラクチャは DECO と同じ方向ではありません。
4. 結論
Chainlink は、DECO オラクルを通じて、プライバシー保護を前提として、大量のオフチェーンのプライベート データがオンチェーンのスマート コントラクトによって呼び出され、金融からアイデンティティ、ソーシャル ネットワーキングに至るまで、多くのアプリケーション シナリオが可能になります。潜在的なリスクは、Prover の証明生成速度と Verifier の集中化の問題です。