信頼の泉を探る：オラクルの原理、種類、現状と発展方向を理解する

この記事は19年10月9日にChainNewsに掲載され、内容は：呉為龍（Genaro CTO）、李画、内容整理：李画

コンピュータシステムと同様に、ブロックチェーンの機能もデータを処理することです。

データの出所には2種類あります。一つはブロックチェーン上に存在するデータ、例えばアカウント内のETHの数量です。もう一つはブロックチェーン上に存在しないデータ、例えばETHの価格です。ブロックチェーンシステムはどのようにして自らの外部データを取得するのでしょうか？それはオラクル（Oracle）を通じて行います。契約が外部データを必要とする場合、オラクルに依頼し、オラクルはオフチェーンでそのデータを取得し、契約にそのデータを伝えます。

このように見ると、オラクルは非常に重要です。オラクルがなければ、ブロックチェーンの発展はチェーン上のわずかな資産データの範囲に制限され、これは明らかに私たちの期待に反します。しかし、重要なものが必ずしもシステムの発展に影響を与える鍵となるわけではありません。例えば、酸素は人類にとって最も重要かもしれませんが、私たちを悩ませる問題を引き起こすことはほとんどありません。

インターネットとブロックチェーンを比較してみましょう。明らかに、インターネットのデータソースもほとんどが「ネット外」（チェーン外に対応）であり、同様にデータの「上網」（上チェーンに対応）問題がありますが、なぜインターネットはオラクルの問題に直面しなかったのでしょうか？

その理由は、インターネット上のアプリケーションがネット外からデータを読み取ることができるのに対し、ブロックチェーン上のアプリケーションはコンセンサスの必要性からオラクルを通じて一貫した外部データを読み込む必要があるからです。実際には、チェーン上のアプリケーションは自分自身のオラクルを簡単に作成し、外部データのインターフェースとして利用できます。重要な問題は、ユーザーがそのオラクルが提供するデータを信じるかどうかです。

根本的な原因は、従来のインターネットが中央集権的な構造であることにあります。このようなシステムでは、ユーザーはその中央集権的な機関を選択することで、その機関が提供するデータを信じなければなりません。データの信頼問題は中央への信頼問題に移行し、データの「上網」は中央集権的なサーバーによって行われます。もちろん、ユーザーは信じない選択をすることもできます。

一方、ブロックチェーンは分散型構造であり、私たちが目指すのはトラストレス（信頼不要）なシステムです。信頼は透明なメカニズムとそのメカニズムのオープンソースのコード実装に基づいて構築されます。こうすることで、中央集権的な機関はユーザーの信頼の必要性を利用して独占的な高壁を築き、その中で「やりたい放題」することができなくなります。

オラクルの問題においては、オラクルを通じてチェーンデータを上げることは難しくありません。単純な読み書き操作でオフチェーンのデータをチェーン上の契約に「与える」ことができます。しかし、信頼を生み出すことは非常に難しいのです。オラクルは技術とメカニズムの設計を通じて、自らが提供するデータがユーザーの信頼のニーズを満たすことができるようにしなければなりません。

したがって、機能的にはオラクルはデータの問題を解決しますが、本質的にはオラクルが解決すべきは信頼の問題です。これが、インターネットには「データ上網」の問題がないのに対し、ブロックチェーンには「データ上链」の問題がある理由です。

ブロックチェーンがオフチェーンデータを使用してより多くの方向性のアプリケーションを探求し実現する必要が生じると、オラクルは「信頼できるデータ」に対する要求を満たす必要があります。したがって、「ブロックチェーン基盤インフラ」というテーマの議論において、私たちはオラクルをその一つとして選びました。

一、オラクルの設計思路

オラクルの核心が信頼の問題を解決することにあると理解すれば、さまざまなオラクルの設計思路の主な違いは「信頼生産メカニズム」の違いにあることがわかります。

信頼の異なる出所に基づいて、現在の主流のオラクルは以下の3つのカテゴリに分けることができます。

1. 信頼できる中央機関がデータを提供する、例えば Provable（旧Oraclize）。
2. 分散型のノードがデータを提供する、例えば Chainlink。
3. 信頼できる連合がデータを提供する、例えば Maker のオラクル。

異なるタイプのオラクルの具体的な実装を紹介する前に、以下の点に注意する必要があります。あるいは、私たちが考え、議論すべきことです。

• オラクルの役割は「真実のデータ」を提供することではなく、「信頼できるデータ」を提供することです。「真実」は主観的な概念であり、評価が難しい概念です。世界には「真実」を保証するツールは存在しないかもしれませんし、オラクルにその機能を果たさせることも現実的ではありません。私たちは真実を保証するメカニズムを設計することはできませんが、信頼性を高めるメカニズムを設計することはできます。オラクルに真実を提供することを求めると、オラクル無用論やブロックチェーン無用論に陥りやすくなります。なぜなら、彼らは確かに私たちの真実に対する要求を満たすことができないからです。
• 異なるアプリケーションシーンは信頼のニーズが異なります。すべてのデータが最高の信頼性の下でチェーン上に上げられる必要があるわけではありません。これは信頼のコスト問題に関わり、データの信頼性の重要性やデータの偽造の動機などの次元とも関連しています。
• 異なるアプリケーションシーンでは、信頼の出所/支えが異なります。つまり、ある種の信頼生産メカニズムが実現する信頼が最適であるとは限らず、他のメカニズムが実現する信頼が悪いとも限りません。

このように、オラクルプロジェクトを観察する際には、重要な焦点はそれがどのように信頼を生産するか、そしてそれが提供する信頼がそのサービス対象のアプリケーションシーンのニーズを満たすことができるかどうかに置かれます。

オラクルの設計には、データソースの問題、つまりオラクル内のデータ提供者がどこからデータを取得するかという重要な問題も含まれます。これは2種類に分けることができます。一つは単一のデータソースからデータを取得するもの、もう一つは複数のデータソースからデータを取得するものです。

二、オラクルの具体的な実装

信頼の出所から始めて、異なるタイプのオラクルの具体的な実装を理解してみましょう。

オラクルはブロックチェーンの重要な基盤インフラですが、オラクルは「魔法の」技術ではありません。彼らが行うことは、オフチェーンのデータをチェーン上のアプリケーションに提供することです。オラクルがどのようなものであっても、データ提供者の異なる実装形式に過ぎません。

私たちは小さな町を想像できます。町には時間を表示する大きな時計（データソース）があり、そこには盲人（ブロックチェーンアプリケーション）が住んでいます。盲人は時間を知りたいのですが、大きな時計を見ることができないため、誰かが時計の表示を教えてくれる必要があります。この人がオラクルです。

1. 信頼できる中央機関がデータを提供する

もし町に10人の盲人が住んでいて、時間が彼らにとって非常に重要であれば、オラクルはビジネスになる可能性があります。盲人は毎回この人に時間を尋ねるために1ドルを支払い、10人の盲人がそれぞれ1日に10回尋ねると、彼は毎日100ドルを稼ぐことができます。

この人が自分で時計を見て時間を教える場合、私たちはこの方法を信頼できる中央機関がデータを提供する方法と呼びます。この場合、盲人たちがこの人を選ぶ前提は、彼が彼らを欺かないと信じられることです。したがって、この人は自分が信頼できることを証明する必要があります。

一種の中央集権的オラクルの信頼保障は「真実性証明技術」です。例えば、ProvableはTLSNotaryアルゴリズムを採用しており、返された結果ごとに未改変の証明を提供できます。つまり、契約に提供されるデータがデータソースのある時点での正しいデータであることを示すことができます。

Town Crierもこのタイプのオラクルに属し、インテルSGX（ソフトウェア保護拡張）アーキテクチャを使用して、ブラックボックスのような環境でコードを実行し、データの改ざんを防ぐハードウェアベースの信頼提供方法です。

この種のオラクルには、TLSNotaryアルゴリズム自体の欠点や単一障害問題、データソースリスク問題などの技術的な弱点がありますが、低コストや高効率などの利点もあり、真実性証明技術も進化し続けています。

中央集権的な存在であるにもかかわらず、この種のオラクルは商業化されており、彼らはデータを提供することだけを行い、データの安全性は彼ら自身の発展に直接関連しています。そのため、彼らが悪事を働く動機は比較的小さいです。

技術を通じて信頼を提供するオラクルの他に、もう一つの信頼できる中央機関のオラクルがあります。町の大きな時計に時報機能が追加されたらどうなるでしょうか？盲人が時計のそばに行き、ボタンを押すと、時計が直接彼に現在の時間を教えてくれます。

ブロックチェーンが特定の権威機関（国家機関や銀行など）のデータを必要とする場合、その機関が自らオラクルを構築してデータを提供することは良い方法かもしれません。この時、重要なのはオラクルの技術ではなく、データソース自体がインターフェースを開放する意志があるかどうかです。信頼の出所はオラクルの設計ではなく、その機関自体です。

これはオフチェーンの信頼をオンチェーンに引き継ぐ方法であり、従来の信頼生産メカニズムによってもたらされる信頼を信じています。高度に中央集権的ですが、少なくともかなりの長い歴史の中で積極的かつ重要な意義があります。例えば、貸付や商業貸付のシーンにおいてです。ブロックチェーンは他のすべての信頼の生成方法を否定するものではありません。

国家機関を例にとると、この種のオラクルの特徴を理解するのは容易ですが、このカテゴリには商業的なデータソースやオラクルも存在する可能性があります。これらは特定のデータニーズにサービスを提供し、そのデータは大量の特殊データの計算結果であり、専門の機関だけがそのデータ結果を提供できるのです。

2. 分散型のノードがデータを提供する

オラクルが解決すべきは信頼の問題です。信頼できる中央機関がデータを提供するオラクルは技術によって自らの信頼性を証明/保障しますが、分散型ノードがデータを提供するオラクルはメカニズムの設計によって自らの信頼性を保障します。後者は去中心化オラクル、去中心化オラクルネットワークとも呼ばれます。

小さな町に戻りましょう。去中心化オラクルネットワークは、町のすべての人が時間を報告することができることを意味します。盲人が時間を尋ねると、これらの参加者/ノードが自分が見た時間を統計係に伝え、統計係が最も多くの人から受け取った時間を盲人に伝えます。

このように、オラクルの設計思路はブロックチェーンの分散型思想と一致しているため、ブロックチェーン上のアプリケーションに新しい信頼タイプを追加することはありません。新しい信頼タイプを追加しないことで、事態の複雑さは高まりません。しかし、この方法にも限界があります。例えば、参加者に多くの報酬を支払う必要があるため、相対的に高価です。また、ネットワークの規模が必要であり、参加者の数と質はデータの信頼性に関連しています。

Chainlinkはこのタイプのオラクルです。以下の図のように、分散型のオラクルノード/オラクルサービスプロバイダーは分散したデータソースからデータを取得し、そのデータをChainlinkのオンチェーン集約契約に提出します（中長期戦略ではガス費用を節約するためにオフチェーン集約に変更される予定です）。この契約はアルゴリズムによってデータ結果を計算し、その結果をデータを要求したブロックチェーンアプリケーションに送信します。

Chainlinkでは、オラクルサービスの購入者が最初に自分のサービスレベルを指定し、その後Chainlinkがオラクルノードをマッチングします。ノードの質と数量を含みます。

例えば、購入者の契約が10万ドルのDeFi市場であれば、5つのオラクルノードを選択してネットワークを構成する必要があります。もしその契約が100万ドルの市場に成長すれば、15のオラクルノードを選択する必要があるかもしれません。Chainlinkの働き方は、ユーザーのニーズに応じてカスタマイズされた動的なオラクルネットワークを提供することです。

上記の特別なオラクルプロジェクトの他に、予測市場、例えばAugurも去中心化オラクルの一種として考えられます。なぜなら、その予測結果をブロックチェーン契約の入力データとして使用できるからです。各予測の参加者はオラクルノードであり、これらの参加者はデータソースそのものでもあります。

予測市場が提供するオラクル機能は、他のカテゴリのオラクルには代替できないかもしれません。なぜなら、そのデータソースの独自性、例えば中央集権的な信頼に依存しないことや、感情や知識を表現するデータを提供できることなどがあります。予測市場は将来的に独自のオラクルアプリケーションシーンを持つかもしれません。しかし、その弱点も顕著で、オラクルネットワークを構成するノードの数に高い依存性があり、データ提供の効率が低いのです。

3. 信頼できる連合がデータを提供する

もし特定のアプリケーションやアプリケーションの種類が外部データに対して高頻度かつ高品質のニーズを持っている場合、市場のオラクルがそのニーズを満たせない場合（例えば、安全性が不十分である、コストパフォーマンスが良くないなど）、これらのアプリケーションは特定のニーズにサービスを提供するための専用のオラクルが必要になるかもしれません。そして、信頼できる連合がデータを提供する方法は、このシーンに適した設計思路です。

「信頼できる連合がデータを提供する」というのは「分散型ノードがデータを提供する」の特殊な形態です。その特異性は、オラクルネットワークを構成するノードが指定されていることです。MakerのV2版オラクルはこのタイプに分類されるかもしれません。そのノードは匿名の個人の価格提供者だけでなく、0x、dYdX、Set Protocol、Gnosisなどの指定された価格提供機関も含まれる可能性があります。

前の2つのタイプのオラクルと比較して、このタイプのオラクルの信頼構成は相対的に複雑です。システムのメカニズム設計に対する信頼、ノードに対する信頼は、ノード自体の利害関係者としての身分やノード自体の機関の評判に大きく依存します。また、ノードを選択するMakerとMaker自身のメカニズムに対する信頼も含まれます。

連合（ノードとノード選択メカニズム）への信頼は中央集権的な色合いを持っていますが、特定のシーンにおいては「高コストパフォーマンス」の信頼を生み出すことができるため、実際のアプリケーションにおいてこの種のオラクルは実用的なデータ上链の方法となる可能性があります。特にブロックチェーン業界が発展初期で、商業化されたオラクルがまだ成熟していない場合です。

MakerのオラクルはMakerが主導していますが、DeFi分野の信頼できるデータのニーズを満たすことができるため、他の契約もこのオラクルを使用しています。私たちは、第三者が提供する信頼できる連合のオラクルサービスを想像することもできます。それはDeFi分野で信頼されている機関/ノードで構成されたオラクルネットワークであり、分散型金融に専門的なデータサービスを提供します。もしブロックチェーンが次の新しいアプリケーションシーンを生み出すなら、その分野の信頼できるノードで構成された連合型のオラクルサービスが必要になるかもしれません。

三、発展の道

ブロックチェーンが発展するにつれて、オフチェーンデータのニーズはますます強くなり、オラクルの重要性もますます顕著になります。しかし、前述のように、オラクル分野ではさまざまな形態が共存する市場が出現する可能性が高いです。私たちは、中央集権型から連合型、そして分散型へと、データ提供者の粒度が大から小へと変化することを考えることができます。そして、異なる粒度はそれぞれの属性を決定し、それぞれのサービスシーンに適したものを決定します。

オラクルも分散型ノードネットワークで構成されることができますが、私たちがブロックチェーンとオラクルを見つめる視点や評価基準は異なります。ブロックチェーンは探求的な作業を行い、「この問題は私が解決するのに適しているか？」と問います。一方、オラクルは機能的な作業を行い、「私はこの問題をどのように解決するか？」と問います。

したがって、オラクルの設計は可用性と実用性を追求します。オラクルはニーズにサービスを提供し、ビジョンにはサービスを提供しません。最も理解しやすい点は、コストパフォーマンスを追求する必要があるということです。

信頼の問題を技術とメカニズムで解決するだけでなく、オラクルの設計にはデータのプライバシー問題やハッキング攻撃への耐性問題など、多くの他の側面も含まれます。これらはすべてオラクルの可用性に関わるからです。このため、オラクルの設計は多くの分野に関わる総合的なエンジニアリングです。

記事の最後に、オラクルはブロックチェーンの重要な基盤インフラですが、オラクルの発展がブロックチェーンの発展を制約することを意味するわけではありません。むしろ、ブロックチェーンの発展状況がオラクルの発展により大きな影響を与えるかもしれません。オンチェーン契約がオフチェーンデータに広範かつ切実なニーズを持ち、そのデータに対して支払いを行うとき、オラクルは真に全面的に発展する可能性があります。