Chainlink DECOを一文で理解する：プライバシー保護型オラクル

2023.01.29

共有先

TechFlow厳選深潮セレクト

Chainlink DECOを一文で理解する：プライバシー保護型オラクル

Web3はデータの価値を再定義したが、分散型構造のブロックチェーンは閉じられた決定性システムである。

2023.01.29 - 03:31:58

ChainlinkDECO

Web3業界の深掘り報道に専念し潮流を洞察

Web3はデータの価値を再定義したが、分散型構造のブロックチェーンは閉じられた決定性システムである。

執筆：kokii.eth、Qiming Venture Partners インターン

0. はじめに

Web3はデータの価値を再定義したが、分散型構造のブロックチェーンは閉じた決定性システムであり、スマートコントラクトは外部API呼び出し機能を実装していないため、スマートコントラクトが外部データを取得するために「オラクル」という仕組みが生まれた。

オンチェーンへのオフチェーンデータの取り込み自体は難しくないが、技術とメカニズム設計を通じて「信頼を創出する」ことが難しい。いわゆるオラクル問題とは、データソースから処理、価格提供（feed）に至るまでの信頼性をどう確保するかという課題である。

公的に認められるオラクルとなる基本条件は「非中央集権性（デセントラリゼーション）」、つまり単一障害点（SPOF）やデータ検証の可否にある。オフチェーンでの非中央集権化の一般的な解決策は、複数のデータノードを使用して非中央集権型オラクルネットワークを形成し、各ノードがデータを収集し、合意形成後にブロックチェーン上のスマートコントラクトへ入力することである。

Chainlink DECOを理解する：プライバシー保護型オラクル

Chainlink アーキテクチャ

現在、オラクルの主な用途はDeFi向けのPrice Feed（価格情報提供）であり、基礎資産の価格を安全かつ迅速に正確に更新することである。DefiLlamaのデータによると、Chainlinkは市場で最大のオラクルソリューションの一つであり、本稿執筆時点で約110億ドルの価値を担保しており、市場全体の46％を占めている。

Chainlink DECOを理解する：プライバシー保護型オラクル

オラクル市場のデータ

ブロックチェーンの発展に伴い、オフチェーンデータへの需要はますます高まっている。単なるDeFi向け価格供給では開発者のニーズを満たせなくなってきた。現実世界およびWeb2における大多数のデータは公開アクセスできないが、これらはWeb3の革新的なユースケース（信用貸付、ソーシャル、DID、KYC/AMLなど）を構築するために不可欠である。そのため、次世代オラクルには、機微データを含む複雑なユースケースをプライバシー保護の上でスマートコントラクトが利用可能にする機能が必要となる。

DECOは、Chainlinkがこの方向に向けて提供するソリューションであり、「ゼロ知識証明（ZKP）技術を活用し、ユーザーが機密データについてオフチェーンでの証明をスマートコントラクトに提供できるようにする一方で、データそのものを一般やオラクルノード自体にも開示しない」ものである。

DECOは既存のAPIに接続でき、エンドユーザーの認証が必要な場合（例：銀行口座残高取得のためのログイン）でも、APIデータプロバイダー側での変更は不要である。現在はアルファ段階にあり、複数のパートナーと共同で概念実証（PoC）のテストを進めている。

1. 背景知識

ここではTLSおよびZKPに関する必要最低限の背景知識を提供する。DECOはこれらのプロトコルに基づいて構築されている。

1.1 TLS

TLS（Transport Layer Security、トランスポート層セキュリティ）は、インターネット通信の秘匿性とデータセキュリティを促進するために設計された強力で広く普及しているセキュリティプロトコルであり、もともとのSSLの後継である。TLSはアプリケーションプロトコル層とTCP/IP層の中間に位置し、主な用途はWebアプリケーションとサーバー間の通信を暗号化することである。

HTTPによる通信はすべてプレーンテキスト形式で行われるため、盗聴、改ざん、なりすましのリスクがある。TLSを使用すると、ユーザーがウェブサイトに送信するHTTPデータ（クリック、フォーム入力など）と、ウェブサイトがユーザーに送信するHTTPデータがすべて暗号化され、受信者は鍵を使って暗号化されたデータを復号する必要がある。HTTPSはHTTPプロトコルにTLS暗号化を追加したものであり、現在のウェブサイトの標準的な手法である。ウェブサイトはオリジンサーバーにTLS証明書をインストールする必要があり、ブラウザはHTTPS以外のサイトをすべて「安全でない」と表示する。

Chainlink DECOを理解する：プライバシー保護型オラクル

HTTPS未使用のウェブサイト

TLSの基本的な考え方は公開鍵暗号方式に基づく。ウェブサイトが公開するTLS/SSL証明書には公開鍵が含まれ、秘密鍵はオリジンサーバーに設置され、ウェブサイト所有者が管理する。クライアントはまずサーバーからデジタル証明書の公開鍵を要求し、それを用いて情報を暗号化して送信する。サーバーは暗号文を受け取った後、自身の秘密鍵で復号を行う。

しかし、公開鍵暗号の計算量は非常に大きく、会話の時間を短縮するために、各セッションでクライアントとサーバーは「セッション鍵（session key）」を生成し、これを使って情報を暗号化する。セッション鍵は共通鍵暗号（対称鍵暗号）であるため、演算速度が非常に速く、サーバーの公開鍵はセッション鍵自体の暗号化にのみ使用されるため、暗号化演算の時間的コストを削減できる。

したがって、TLSプロトコルは主に以下の2つの層に分けられる：

認証と鍵交換のためのハンドシェイクプロトコル (handshake protocol)：平文通信により、非対称鍵暗号を用いて相互に認証を行い、使用する暗号化アルゴリズムを決定し、記録プロトコルでの共通鍵暗号に使用する一貫したセッション鍵を生成する。
共通鍵暗号による転送の記録プロトコル (record protocol)：プロトコルの主体部分であり、データ転送の機密性と完全性を保護する。

Chainlink DECOを理解する：プライバシー保護型オラクル

TLSプロトコルスタック

TLSの暗号スイート（CipherSuite）は、以下の4つのアルゴリズムの組み合わせである：

認証 (Authentication)：身元の真偽を判断するもの。主流はRSA/DSA/ECDSA。
鍵交換 (Key exchange)：通信双方が暗号化に使用する鍵を合意するもの。主流はECDHE。
暗号化 (Encryption)：通信に使用する共通鍵暗号。最近の傾向はGCMの使用。
MAC (Message Authentication Code、メッセージ認証コード)：データの完全性と改ざん有無の検証に使用。主流はSHA256/SHA384/SHA1など。

TLSは非常に強力だが、一つの制限がある：ユーザーが、自分がアクセスしたデータが実際に特定のウェブサイトからのものであることを第三者に証明できない。これはデータ転送が共通鍵暗号を使用しており、ユーザーとサーバーは同じようにデータに署名できる能力を持つためである。直感的な例として、多くのウェブサイトのサーバーにはアリスの身分情報が保存されており、アリスが18歳以上であることを簡単に確認できるが、アリス本人がボブにそれを証明するのは難しい。アリスはウェブサイトのスクリーンショットを撮れるが、それは簡単に偽造できる。仮にスクリーンショットが本物と証明できたとしても、情報が漏洩してしまう――アリスの正確な生年月日だけでなく、「18歳以上」という事実だけを知らせるべきなのに。

オラクルは、単一のポイント（例：ウェブサイトサーバー）に依存しない形で、オフチェーンの機密データの出所（Provenance）を非中央集権的に証明し、プライバシーを損なうことなくスマートコントラクトで使用できるようにする必要がある。ゼロ知識証明はこうした機能を実現するのに役立つ。

1.2 ZKP

ゼロ知識証明（Zero Knowledge Proof, ZKP）は、ブロックチェーン分野で広く注目されている。主な応用はZK-Rollup（スケーラビリティ向上のためアルゴリズム設計で妥協が多く、厳密にはzkではないValidity Proof）とプライバシーテクノロジー（真のzk）である。ゼロ知識証明は、Prover（証明者）がVerifier（検証者）に対して、ある計算問題（Statement）に対する解（Witness）を持っていることを、その解に関する追加情報を一切開示せずに証明できる仕組みである。

典型的なZKシステムは、フロントエンドとバックエンドの2つに大別できる。

フロントエンド：コンパイラ。検証したい命題（Statement）をドメイン固有言語（DSL）で記述し、その後ZKフレンドリーな形式（例：算術回路）にコンパイルする。
バックエンド：証明システム。回路の正しさを検証するインタラクティブなアргументシステム。例：Marlin, Plonky2, Halo2。

Chainlink DECOを理解する：プライバシー保護型オラクル

ZKシステム

ブロックチェーンのようなオープンシステム上では、インタラクティブな質疑応答プロセスを構築するのは非常に複雑である。証明は誰でもいつでも検証可能である必要があるため、ブロックチェーン上のZKシステムは通常非インタラクティブ式であり、インタラクティブ式はFiat–Shamirヒューリスティックによって非インタラクティブ式に変換できる。

2. DECOの動作原理

DECOはHTTPS/TLSプロトコルを拡張しており、サーバー側の変更なしに利用可能である。

DECOの核心的なアイデアは、Prover（ユーザーまたはDECO Proverを実行するDApp）、Verifier（DECO Verifierを実行するChainlinkオラクル）、Server（データプロバイダー）の3者間で新たな三者ハンドシェイクプロトコルを構築することにある。

出所の証明（Provenance）：ProverがWebサーバーから情報を照会する際、Verifierがそのやり取りを観測し、ProverがTLSセッションデータから作成したコミットメント（Commitment）を受信することで、情報の真正な出所を検証できる。
プライバシー：データにプライバシー保護が必要ない場合は、Proverが直接Verifierにデータを復号できる鍵を提供し、DApp開発者がデータを利用できる。プライバシーが必要な場合は、Proverがゼロ知識証明を用いてデータを開示せずに証明を生成し、DAppに組み込む。

Chainlink DECOを理解する：プライバシー保護型オラクル

DECOの例

具体的には、DECOプロトコルは以下の3つのフェーズからなる：

三者ハンドシェイク：Prover、Verifier、Serverが特殊な形式のセッション鍵を確立し、データの偽造防止を保証する。
照会の実行：Proverは自身のプライベートパラメータθs（例：アカウントパスワード、APIキー）を含むQueryを使用し、Serverからデータを照会する。
証明の生成：Proverが、応答が所定の条件を満たすことを証明する。

Chainlink DECOを理解する：プライバシー保護型オラクル

DECOアーキテクチャ

2.1 三者ハンドシェイク

注：以下の説明はAES-CBC-HMAC暗号アルゴリズムに基づいている。TLS 1.3ではより安全なAEADが唯一の暗号アルゴリズムとして採用されており、暗号化とMACに同一の鍵を使用するため、MAC鍵は不要である。しかし、TLS 1.3の鍵独立性により、同程度の複雑さを持つ三者ハンドシェイクプロトコルを構築することが可能である。

Prover Pは、MAC鍵を取得した後にコミットメントを行ってはならない。そうでなければデータの偽造や改ざんが可能になってしまう。したがって、三者ハンドシェイクのアイデアは、Prover PとVerifier Vを共同でTLSクライアントとして扱い、TLSサーバーSと共有MAC鍵を確立することにある。MAC鍵kはクライアント側で分割され、Proverはkpを保持し、Verifierはkvを保持する。すなわちk = kp + kv。同時に、Pは対称鍵暗号化アルゴリズム用の暗号化鍵k^{Enc}も保持する。Verifierが悪意を持たない限り、三者ハンドシェイクプロトコルによりデータの偽造不可能性が保証される。

2.2 照会の実行

ハンドシェイク後、MAC鍵は秘密裏に共有されているため、PとVはインタラクティブなプロトコル（二人間の安全計算）を実行し、プライベートパラメータθsを用いてTLSメッセージQuery Qを構築する。その後、Pは標準的なTLSクライアントとしてQをSに送信する。この過程ではPとSのみが通信し、Pが送信する照会内容はVに漏れない。

Sから応答Rを受け取った後、Pは暗号文RˆをVに送信してセッションをコミットし、Vからkvを受信して応答Rの真正性を検証する。

2.3 証明の生成

次に、Pは暗号文Rˆに対応する平文Rが特定の属性を満たすことを証明する必要がある。プライバシーが不要であれば、暗号化鍵k^{Enc}を直接開示すればよい。プライバシーが必要な場合は、ゼロ知識証明を使用する。

平文がいくつかのデータブロックから構成される場合R=(B1,...,Bn)、DECOは選択的開示（Selective Opening）を用いてゼロ知識証明を生成する：

特定のデータ行のみを公開：他のデータブロックを開示せずに、Rの第i番目のデータブロックがBiであることを証明する。
プライバシーを含むデータ行を隠蔽：R_{-i}とRが等しいこと（ただしBiを除く）を証明する。

Chainlink DECOを理解する：プライバシー保護型オラクル

しかし、多くの場合、Verifierは公開されたサブ文字列が正しい文脈に含まれているかを検証する必要があり、上記の方法では文脈の完全性保護が不十分である。これを補うために、DECOは「ゼロ知識二段階解析（Two-stage Parsing）」という技術を活用する：Proverはローカルでセッションデータを解析し、Verifierを納得させる最小のサブ文字列を特定し、それをVerifierに送信する。これによりプライバシーが実現される。

簡潔な非インタラクティブ型（NIZK）ゼロ知識証明は、計算量とメモリ使用量においてProver側で高いオーバーヘッドを生むことが多い。しかし、DECOのZKPにおけるVerifierは指定されている（Chainlinkのオラクル）ため、より効率的なインタラクティブ型ゼロ知識証明（より少ないメモリ使用、信頼設定不要、低コストな計算など）を利用できる。

現在のAlpha Testでは、依然としてDAppがProverの役割を果たしているが、今後の反復では、Proverがエンドユーザーの端末（例：スマートフォン）にローカルに配置されるか、あるいは信頼できる実行環境（TEE）内に配置される予定である。

3. 応用分野

DECOは、ユーザーのオフチェーン身分情報の有効性を検証しつつ、データのプライバシーを守ることができるため、金融からソーシャルまで、Web3の革新的なユースケースを多数解放する。

セルフホスティング型ソーシャルリカバリー/法的身分証明（あなたは誰か）：DECOを使い、既に成熟した身分検証メカニズムを持つ機関のウェブサイト（銀行、SNSなど）を、ソーシャルリカバリーのガーディアンの一つとして活用できる。

Chainlink DECOを理解する：プライバシー保護型オラクル

信用貸付/資金証明（あなたはいくら持っているか）：TellerはDeFiの信用貸付プロトコルであり、DECOプロトコルを用いて、ユーザーのオフチェーン銀行口座残高がローンの動的最低閾値を超えてることを証明する。

Chainlink DECOを理解する：プライバシー保護型オラクル

ファン証明/インタラクション証明（あなたは誰と交流したか）：Cliqueはソーシャルオラクルであり、各種SNSプラットフォーム（例：Twitter API）を横断するオフチェーンユーザーコミュニティ影響力、忠誠度、貢献度の深層分析を提供するソリューションを開発中である。
デジタルID/ソーシャルアカウント証明（あなたはあるオンラインアカウントを持っているか）：PhotoChromicはデジタルIDソリューションであり、DECOを用いてWeb3ユーザーをそのTwitterやDiscordアカウントと紐づけつつ、個人識別情報を開示せず、アプリが本物のユーザーをフィルタリングできるようにする。
DAOにおけるシビル攻撃対策、SBT、KYC/AMLなど。

4. その他のプレイヤー

AxiomはUniswap TWAP向けにZKオラクルを構築。完全にオンチェーンの検証可能なデータソースを利用しており、Indexingに近い（例：Hyper Oracle）。DECOとは競合というより補完関係にある：ますます多くの経済活動がオンチェーンで発生するため、純粋なオンチェーンオラクルは一つの方向性であり、一方でますます多くのオフチェーンデータをオンチェーンに持ち込む必要があるため、オフチェーンプライバシー型オラクルもまた重要な方向性である。
Empiric Networkはzk計算を用いてオラクル全体をオンチェーンに移行。データが通過する必要のあるオフチェーンインフラが存在しないため、DECOとは異なる方向性にある。