オラクル

オラクルとは、スマートコントラクト向けにオフチェーンのデータソースをブロックチェーンで利用できるようにするデータフィードを生成するアプリケーションです。イーサリアムベースのスマートコントラクトでは、デフォルトでブロックチェーンのネットワークの外に保存されている情報にアクセスできないため必要になります。

スマートコントラクトがオフチェーンデータを使用して実行できるようになることで、分散型アプリケーションの有用性と価値が広がります。例えば、オンチェーンの予測市場は、ユーザーの予測を検証するために使用する結果に関する情報を提供するために、オラクルに依存しています。アメリカの次期大統領が誰になるかという予測に、アリスさんが20 ETHを賭けたと仮定してみましょう。このユースケースの場合、予測市場を提供するDappは、選挙結果を確認し、ユーザー（例えば、アリス）が支払対象に含まれるかを確認するためにオラクルが必要になります。

前提条件

このページは、読者がノード、コンセンサスメカニズム、EVMなど、イーサリアムの基礎知識に精通していることを前提としています。また、スマートコントラクトとスマートコントラクトの構造、特にについて十分に理解している必要があります。

ブロックチェーンにおけるオラクルとは何か？

オラクルとは、ブロックチェーン上で実行されるスマートコントラクトに対し、外部情報（つまり、オフチェーンに保存された情報）を取得し、検証し、送信するアプリケーションです。オラクルは、オフチェーンデータを「プル」してイーサリアムでブロードキャストするだけでなく、ブロックチェーンから外部システムに情報を「プッシュ」することもできます。例えば、ユーザーがイーサリアムのトランザクションを介して料金を支払うと、スマートロックが解除されるといった具合です。

オラクルがなければ、スマートコントラクトは完全にオンチェーンのデータに限定されてしまいます。

オラクルには、データソースの種類（ソースが1つであるか複数であるか）、信頼モデル（集中型か分散型か）、およびシステムのアーキテクチャ（即時読み取り型、公開／講読型、および要求／対応型）により様々な種類があります。また、オラクルは、オンチェーンコントラクトが使用するために外部データを取得するか (入力オラクル)、ブロックチェーンからオフチェーンアプリケーションに情報を送信するか (出力オラクル)、オフチェーンで計算タスクを実行するか (計算オラクル) によって区別することもできます。

スマートコントラクトにオラクルが必要な理由

多くの開発者にとって、スマートコントラクトとは、ブロックチェーン上の特定のアドレスで実行されるコードの集合に過ぎません。しかし、スマートコントラクトのより一般的な見解は、特定の条件が満たされたときに当事者間の合意を強制することができる自己実行型ソフトウェアプログラムであるということです。それゆえに、「スマートコントラクト」と呼ばれます。

しかし、イーサリアムは決定論的なシステムであるため、スマートコントラクトを用いてユーザー間の合意を強制するプロセスは簡単には実現できません。決定論的システム (opens in a new tab)とは、初期状態と特定の入力が与えられた場合に常に同じ結果を生成するシステムのことであり、入力から出力を計算する過程にランダム性やばらつきがないことを意味します。

決定論的な実行を実現するため、ブロックチェーンは、ブロックチェーン自体に保存されているデータ_のみ_を使用して、単純な二者択一（真/偽）の質問についてノードがコンセンサスに達するように制限しています。このような質問の例としては、以下のようなものがあります：

「（公開鍵で特定された) アカウント所有者は、このトランザクションにペアの秘密鍵で署名したか？」
「このアカウントは、このトランザクションの実行に必要な十分な資金を持つか？」
「このトランザクションは、このスマートコントラクトの文脈において有効か？」等々。

ブロックチェーンでは、外部ソースからの情報（つまり、現実世界の情報）を参照する場合、決定論的な処理が不可能になり、ブロックチェーンの状態変化が正当であるか否かについて各ノードが合意できなくなります。価格情報を提供する一般的なAPIを通じて現在のETH/USDの交換レートを取得し、トランザクションを実行するスマートコントラクトの例を考えてみましょう。この為替レートは頻繁に変化すると予想されるため（このAPI自体が非推奨となったり、ハッキングされる可能性を無視したとしても）、このスマートコントラクトにおける同一のコードを実行するノードが得る出力は常に異なる可能性があります。

イーサリアムのように、世界中に数千ものノードがトランザクションを処理するパブリックブロックチェーンにとっては、決定論的な処理は欠くことができません。真実性を担保する中心的な権威が存在しないため、同じトランザクションを適用した後に同じ状態に到達するメカニズムがノードに必要になります。例えば、Aというノードがスマートコントラクトのコードを実行した場合の出力が「3」である一方で、Bというノードの出力が「7」である場合、コンセンサスが崩壊するため、イーサリアムが持つ分散型のコンピューティングプラットフォームとしての価値が損なわれます。

このシナリオはさらに、外部ソースから情報を引き出すことが可能なブロックチェーンを設計する際の問題点を浮き彫りにします。しかし、オラクルはオフチェーンソースから情報を取得し、スマートコントラクトが利用できるようにブロックチェーンに保存することで、この問題を解決します。オンチェーンに保存された情報は変更不可能で公開されているため、イーサリアムのノードは、コンセンサスを破ることなく、オラクルがインポートしたオフチェーンのデータを安全に使用して状態の変更を計算できます。

このため、オラクルは通常、オンチェーンで実行されるスマートコントラクトと、いくつかのオフチェーンコンポーネントで構成されています。オンチェーンのコントラクトは、他のスマートコントラクトからデータのリクエストを受け取り、それをオフチェーンのコンポーネント（オラクルノードと呼ばれる）に渡します。このオラクルノードは、アプリケーション・プログラミング・インターフェース（API）などを用いてデータソースをクエリし、トランザクションを送信することで、リクエストされたデータをスマートコントラクトのストレージに保存することができます。

つまり、ブロックチェーンにおけるオラクルとは、ブロックチェーンと外部環境の間に存在する情報のギャップを橋渡しする役割を提供することで、「ハイブリッド型のスマートコントラクト」を実現するものです。ハイブリッドスマートコントラクトとは、オンチェーンのコントラクトコードとオフチェーンのインフラストラクチャの組み合わせに基づいて機能するものです。分散型の予測市場は、ハイブリッド型のスマートコントラクトの代表例だと言えます。その他の例としては、複数のオラクルを通じて特定の気候現象が発生したことが確認できた場合に保険金を支払うことができる農作物保険のスマートコントラクトが挙げられるでしょう。

オラクル問題とは何か？オラクルの問題点

オラクルは重要な問題を解決しますが、次のような複雑な問題も引き起こします。

コントラクトに読み込まれた情報が、適切なソースから抽出されているかや、改変されていないかを検証するにはどうすればよいか？
このデータが、常に参照可能で定期的に更新されることを保証するにはどうすればよいか？

このいわゆる「オラクル問題」は、ブロックチェーンのオラクルを用いてスマートコントラクトに情報を送信する際にどのような問題が発生するかを示しています。スマートコントラクトが正しく実行されるためには、オラクルからのデータが正しい必要があります。さらに、正確な情報を提供するためにオラクルのオペレータを「信頼」しなければならないことは、スマートコントラクトの「トラストレス」の側面を損なうことになります。

さまざまなオラクルが、オラクル問題に対して異なる解決策を用意しています。これについては後ほど説明します。オラクルは通常、次の課題にどのように対処するかによって評価されます。

正確性：オラクルは、無効なオフチェーンデータに基づいてスマートコントラクトが状態変更をトリガーする原因となるべきではありません。オラクルは、データの_真正性_と_完全性_を保証しなければなりません。真正性とはデータが正しいソースから取得されたことを意味し、完全性とはデータがオンチェーンに送信される前に無傷（つまり、変更されていない）であったことを意味します。
可用性：オラクルは、スマートコントラクトがアクションを実行し、状態変化をトリガーするのを遅らせたり、妨げたりしてはなりません。これは、オラクルからのデータが中断することなく_リクエストに応じて利用可能_でなければならないことを意味します。
インセンティブ整合性：オラクルは、オフチェーンのデータプロバイダーがスマートコントラクトに正しい情報を提出するようにインセンティブを与えるべきです。インセンティブ整合性には、_帰属性_と_説明責任_が含まれます。アトリビュータビリティとは、当該の外部情報とその提供者を相互に関連付けできる性質を指し、アカウンタビリティとは、データ提供者に対して提供するデータの品質について責任を負わせる性質を指します。そのため、提供された情報の質に基づいて報酬を与えたり、ペナルティを与えたりすることができます。

ブロックチェーンにおけるオラクルサービスの仕組み

ユーザー

ユーザーとは、特定のアクションを実行する上で、ブロックチェーンの外部にある情報を必要とするエンティティ（つまり、スマートコントラクト）を指します。オラクルサービスの基本的なワークフローでは、まずユーザーが、オラクルであるコントラクトに対してデータリクエストを送信します。通常、データリクエストは以下の質問のうちいずれか／全部に回答するものです：

オフチェーンノードは、要求された情報をどのソースから参照できますか？
レポーターは、データソースから取得した情報をどのように処理し、有益なデータポイントを抽出するか？
このデータを取得するために、関与できるオラクルノードの数はいくつか？
各オラクルによるレポートの不一致は、どのように管理されるか？
提出されたレポートを絞り込み、単一の値に集約するためには、どのようなメソッドを実装すべきか？

オラクルコントラクト

オラクルコントラクトは、オラクルサービスのオンチェーンコンポーネントです。他のコントラクトからのデータのリクエストをリッスンしており、データクエリーをオラクルーノードへ中継します。そして、オラクルノードから返送されたデータをクライアントコントラクトへブロードキャストします。さらに、オラクルコントラクトでは、返送されたデータポイントに対して一定の処理を実行し、リクエスト元のスマートコントラクトに集計値を送信することができます。

オラクルコントラクトは、クライアントのコントラクトがデータリクエストを行う際に呼び出す関数の一部を公開します。新しいクエリを受け取ると、スマートコントラクトはデータリクエストの詳細を含むログイベントを発行します。これはログを購読しているオフチェーンノード（通常はJSON-RPC eth_subscribe コマンドのようなものを使用）に通知し、ログイベントで定義されたデータを取得します。

以下は、Pedro Costaによるオラクルコントラクトの例 (opens in a new tab)です。これは、他のスマートコントラクトからのリクエストに応じてオフチェーンAPIをクエリし、リクエストされた情報をブロックチェーンに保存できるシンプルなオラクルサービスです：

1pragma solidity >=0.4.21 <0.6.0;
2
3contract Oracle {
4  Request[] requests; // コントラクトに対して行われたリクエストのリスト
5  uint currentId = 0; // リクエストIDをインクリメント
6  uint minQuorum = 2; // 最終結果を宣言する前に受け取る最小応答数
7  uint totalOracleCount = 3; // ハードコードされたオラクルの数
8
9  // 一般的なAPIリクエストを定義
10  struct Request {
11    uint id;                            // リクエストID
12    string urlToQuery;                  // APIのURL
13    string attributeToFetch;            // レスポンスで取得するJSON属性（キー）
14    string agreedValue;                 // キーからの値
15    mapping(uint => string) answers;     // オラクルから提供された回答
16    mapping(address => uint) quorum;    // 回答を照会するオラクル（1=オラクルはまだ投票していない、2=オラクルは投票済み）
17  }
18
19  // ブロックチェーンの外部でオラクルをトリガーするイベント
20  event NewRequest (
21    uint id,
22    string urlToQuery,
23    string attributeToFetch
24  );
25
26  // 最終結果についてコンセンサスが得られたときにトリガーされる
27  event UpdatedRequest (
28    uint id,
29    string urlToQuery,
30    string attributeToFetch,
31    string agreedValue
32  );
33
34  function createRequest (
35    string memory _urlToQuery,
36    string memory _attributeToFetch
37  )
38  public
39  {
40    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
41    Request storage r = requests[length-1];
42
43    // ハードコードされたオラクルのアドレス
44    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
45    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
46    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
47
48    // ブロックチェーンの外部でオラクルによって検出されるイベントを発生させる
49    emit NewRequest (
50      currentId,
51      _urlToQuery,
52      _attributeToFetch
53    );
54
55    // リクエストIDをインクリメント
56    currentId++;
57  }
58
59  // 回答を記録するためにオラクルから呼び出される
60  function updateRequest (
61    uint _id,
62    string memory _valueRetrieved
63  ) public {
64
65    Request storage currRequest = requests[_id];
66
67    // オラクルが信頼できるオラクルのリストに含まれているか確認
68    // かつ、オラクルがまだ投票していないか確認
69    if(currRequest.quorum[address(msg.sender)] == 1){
70
71      // このアドレスが投票済みであることをマーク
72      currRequest.quorum[msg.sender] = 2;
73
74      // 空きポジションが見つかるまで回答の「配列」を反復処理し、取得した値を保存
75      uint tmpI = 0;
76      bool found = false;
77      while(!found) {
78        // 最初の空きスロットを見つける
79        if(bytes(currRequest.answers[tmpI]).length == 0){
80          found = true;
81          currRequest.answers[tmpI] = _valueRetrieved;
82        }
83        tmpI++;
84      }
85
86      uint currentQuorum = 0;
87
88      // オラクルのリストを反復処理し、十分なオラクル（最小定足数）があるか確認
89      // 現在の回答と同じ回答に投票したか
90      for(uint i = 0; i < totalOracleCount; i++){
91        bytes memory a = bytes(currRequest.answers[i]);
92        bytes memory b = bytes(_valueRetrieved);
93
94        if(keccak256(a) == keccak256(b)){
95          currentQuorum++;
96          if(currentQuorum >= minQuorum){
97            currRequest.agreedValue = _valueRetrieved;
98            emit UpdatedRequest (
99              currRequest.id,
100              currRequest.urlToQuery,
101              currRequest.attributeToFetch,
102              currRequest.agreedValue
103            );
104          }
105        }
106      }
107    }
108  }
109}
すべて表示

オラクルノード

オラクルノードは、オラクルサービスのオフチェーンコンポーネントです。外部ソース（サードパーティのサーバーでホストされているAPIなど）から情報を抽出し、スマートコントラクトが利用できるようにオンチェーンに配置します。オラクルノードは、オンチェーンのオラクルコントラクトからのイベントをリッスンし、ログに記載されたタスクを完了させます。

オラクルノードの一般的なタスクは、HTTP GET (opens in a new tab)リクエストをAPIサービスに送信し、レスポンスを解析して関連データを抽出し、ブロックチェーンで読み取り可能な出力にフォーマットし、オラクルコントラクトへのトランザクションに含めてオンチェーンに送信することです。オラクルノードはまた、「真正性証明」を用いて、提出された情報の正当性および完全性を証明するように要求される場合がありますが、これについては以下のセクションで説明します。

計算オラクルも、ガス代やブロックサイズの制限からオンチェーンでの実行が非現実的な計算タスクを実行するために、オフチェーンノードに依存します。例えば、ランダムであることが検証可能な値を生成するタスク（ブロックチェーンベースのゲームで用いる）につき、オラクルノードが活用される場合があります。

オラクルの設計パターン

オラクルには、即時読み取り、パブリッシュ/サブスクライブ、_リクエスト/レスポンス_などさまざまなタイプがあり、後の2つはイーサリアムのスマートコントラクトで最もよく使われています。ここでは、出版/購読型モデルとリクエスト/レスポンス型モデルについて簡単に説明します。

このタイプのオラクルでは、他のコントラクトが定期的に情報を読み込むことが可能な「データフィード」を提供します。このデータフィードにおけるデータは頻繁に変化すると想定されるため、クライアントであるコントラクトは、オラクルのストレージに含まれるデータが更新されたかどうかをリッスンする必要があります。例えば、最新の ETH-USDにおける価格情報をユーザーに提供するオラクルがあります。

リクエスト/レスポンス型オラクル

リクエスト/レスポンス型のメカニズムにおいては、クライアントのコントラクトは出版/購読型のオラクルでは提供されない任意のデータをリクエストできます。リクエスト/レスポンス型のオラクルは、データセットが大きすぎてスマートコントラクトのストレージに保存できない場合や、ユーザーが常時データのごく一部しか必要としない場合に適しています。

リクエスト/レスポンス型のオラクルは、出版/購読型よりも複雑ですが、基本的な機能は上記セクションで説明した通りです。オラクルは、データリクエストを受信し、それを処理のためにオフチェーンノードに渡すオンチェーンコンポーネントを持ちます。

データクエリを開始するユーザーは、オフチェーンソースから情報を取得するためのコストを負担する必要があります。クライアントのコントラクトはさらに、オラクルコントラクトが当該リクエストで指定されたコールバック機能を通じてレスポンスを提供する際に発生するガス代につき、これを負担するのに十分な資金を持つ必要があります。

中央集権型オラクルと分散型オラクルの比較

中央集権型オラクル

中央集権型オラクルは、オフチェーンの情報を集約し、要求に応じてオラクルコントラクトのデータを更新する責任を負う単一のエンティティによって管理されます。集中型のオラクルは、単一の真実ソースを持つため、効率的であると言えます。集中型のオラクルは、広く承認された署名を持つ所有者が直接、独自のデータセットを公開する場合においてはよく機能します。しかし、次のような欠点があります。

低い正確性の保証

集中型のオラクルでは、提供された情報が正しいか否かを確認する方法がありません。たとえ「評判の良い」プロバイダーであっても、不正が行われたり、ハッキングを受ける可能性はあります。当該オラクルが改ざんされた場合、スマートコントラクトは不適切なデータに基づいて実行されることになります。

低い可用性

中央集権型オラクルは、他のスマートコントラクトに対してオフチェーンのデータを常に提供することを保証しません。プロバイダーがサービスを停止したり、ハッカーがオラクルのオフチェーンコンポーネントを乗っ取ったりすると、あなたのスマートコントラクトはサービス拒否（DoS）攻撃のリスクにさらされます。

低いインセンティブ整合性

集中型のオラクルでは、データ提供者に対して正確／未改変の情報を送信するようにインセンティブを提要する仕組みが存在しないか、設計が不十分な場合が少なくありません。正確であるがゆえにオラクルに支払っても、必ずしも公正であるとは限りません。この問題は、スマートコントラクトによって管理される金額が増加するにつれて大きくなります。

分散型オラクル

分散型のオラクルは、障害が発生しうる単一の箇所を除去することで、集中型オラクルにおける様々な欠点を克服するように設計されています。分散型オラクルサービスは、ピアツーピアネットワークの複数の参加者で構成され、スマートコントラクトに送信する前にオフチェーンデータについてコンセンサスを形成します。

分散型のオラクルは、（理想的には）パーミッションレスであり、中央組織による管理が存在しないものでなくてはなりませんが、実際には、分散型オラクルがどの程度分散的であるかは各オラクルにより異なります。例えば、あらゆるユーザーが参加できるものの、「オーナー」による承認が必要であり、過去の行動に基づき特定のノードを削除できる半分散型のオラクルネットワークも存在します。その一方で、完全に分散型のオラクルネットワークも存在しており、これらは通常スタンドアロンのブロックチェーンとして実行され、各ノード間の連携や不正行為の処罰のためのコンセンサス・メカニズムが設定されています。

分散型のオラクルは、以下のような利点を持ちます：

高い正確性の保証

分散型のオラクルでは、様々な用いてデータの正しさを確認しようと試みます。これには、返された情報の真正性と完全性を証明する証明の使用や、複数のエンティティがオフチェーンデータの有効性について集合的に合意することを要求することが含まれます。

真正性の証明

真正性の証明とは、外部ソースから取得した情報の真正性を独立的に証明できる暗号化のメカニズムです。これらの証明は、情報ソースを検証すると共に、取得したデータが改変されているかを検出することができます。

真正性の証明には、以下のようなものがあります：

トランスポートレイヤーセキュリティ（TLS）証明：オラクルノードは、多くの場合、トランスポートレイヤーセキュリティ（TLS）プロトコルに基づく安全なHTTP接続を使用して、外部ソースからデータを取得します。一部の分散型オラクルでは、TLSセッションを検証し（つまり、ノードが特定のサーバーとの間で情報を交換したことを確認し）、当該セッションにおける内容が未改変であることを確認するために、真正性証明を利用します。

高信頼実行環境（TEE）アテステーション：高信頼実行環境 (opens in a new tab) (TEE) は、ホストシステムの運用プロセスから隔離されたサンドボックス化された計算環境です。 TEEでは、当該の計算環境においおて保存／使用されるアプリケーションコードまたはデータの完全性、機密性、および不変性が保証されます。ユーザーはまた、当該のアプリケーション・インスタンスが信頼された実行環境において実行されていることを証明するアテステーションを生成することもできます。

分散型オラクルの中には、オラクルノードの運用者に対してTEEのアテステーションを要求するものもあります。このアテステーションは、ノードの運用者がオラクルクライアントのインスタンスを信頼された実行環境で実行していることを、ユーザーに保証するものです。 TEEでは、当該アプリケーションのコードおよびデータを改変したり、読み取るような外部プロセスが実行できないため、このようなアテステーションを通じて、オラクルノードが当該情報を未改変かつ機密の状態に保ったことを証明できます。

コンセンサスベースの情報検証

集中型のオラクルでは、スマートコントラクトにデータを提供する際に、単一の真実ソースに依存するため、不正確な情報を公開する可能性が存在します。分散型オラクルは、複数のオラクルノードに依存してオフチェーン情報をクエリすることで、この問題を解決します。複数のソースからのデータを比較することで、分散型オラクルはオンチェーンコントラクトに無効な情報が渡されるリスクを低減します。

しかし、分散型オラクルは、複数のオフチェーンソースから取得した情報の不一致に対処する必要があります。取得した情報の不一致を最小化し、オラクルコントラクトに提供されるデータが全オラクルノードの集合的な意見を反映したものであることを保証するために、分散型のオラクルでは以下のメカニズムを活用します：

データの正確性に関する投票／ステーキング

一部の分散型オラクルでは、参加者に対し、データクエリ（例：「2020年の米国大統領選挙では誰が当選したか？」）への回答に対して、投票またはステーキングを要求します。この際の投票／ステーキングには、当該ネットワークのネイティブトークンが使用されます。この投票およびステーキングは、集計プロトコルにより集約され、多数派が支持した回答が正当な回答とされます。

多数派の回答とは異なる回答を提供したノードは、ペナルティとして、より適切な値を提供したユーザーに保有トークンを奪われることになります。各ノードに対して、データ提供前に担保の差し出しを義務付けることで、リターン最大化を目指す合理的な経済アクターと想定されるユーザーに対し、正直な行動を取るように誘導するインセンティブを与えることができます。

ステーキングや投票は、悪意のあるアクターがコンセンサスシステムを悪用するために複数のIDを作成するから分散型オラクルを保護します。しかし、ステーキングによっても、「フリーローディング」（他のユーザーから情報をコピーするオラクルノード）や、「怠惰な検証」（自身で検証せずに、多数派の意見に従うオラクルノード）の発生を防ぐことはできません。

シェリングポイントのメカニズム

シェリングポイント (opens in a new tab)とは、複数のエンティティがコミュニケーションなしに問題に対する共通の解決策に常にデフォルトで従うと仮定するゲーム理論の概念です。シェリングポイントのメカニズムは、分散型のオラクルネットワークにおいて、データリクエストへの回答について各ノードがコンセンサスを得るためにしばしば利用されます。

これに関する初期のアイデアは SchellingCoin (opens in a new tab) でした。これは、参加者がデポジットとともに「スカラー」の質問（「ETHの価格は？」など、回答が大きさで記述される質問）への回答を送信する、提案されたデータフィードです。 25パーセンタイルと75パーセンタイル (opens in a new tab)の間の値を提供したユーザーは報酬を受け取りますが、中央値から大きく外れた値を提供したユーザーはペナルティを受けます。

SchellingCoinは現在存在しませんが、多くの分散型オラクル、特にMakerプロトコルのオラクル (opens in a new tab)は、シェリングポイントのメカニズムを使用してオラクルデータの正確性を向上させています。各Makerオラクルは、担保資産の市場価格を提出するオフチェーンのP2Pネットワークのノード（「リレイヤー」と「フィード」）と、提供されたすべての値の中央値を計算するオンチェーンの「Medianizer」コントラクトで構成されています。定められた遅延期間が経過すると、この中央値が当該資産における新たな参照価格になります。

シェリングポイントメカニズムを使用するオラクルの他の例としては、Chainlinkオフチェーンレポーティング (opens in a new tab)やWitnet (opens in a new tab)などがあります。どちらのシステムでも、P2Pネットワークに含まれるオラクルノードからの回答は、平均値あるいは中央値といった単一の値に集約されます。各ノードは、自らの回答がこの集約値とどれほど一致／乖離しているかに応じて、報酬／罰金を受けます。

シェリングポイントメカニズムは、分散化を保証しつつ、オンチェーンのフットプリントを最小限に抑えるため（送信する必要があるトランザクションは1つだけ）、魅力的です。このメカニズムで分散化が可能なのは、各ノードに対して、提出済みの回答リストが平均値／中央値を算出するアルゴリズムに投入される事前に、同リストにサインオフすることが要求されるためです。

可用性

分散型オラクルサービスは、スマートコントラクトに対するオフチェーンデータの高い可用性を保証します。これは、オフチェーン情報のソースと、情報をオンチェーンに転送する責任を負うノードの両方を分散化することで達成されます。

この可用性により、オラクルコントラクトは、他のコントラクトのクエリを実行するために複数のノードに依存でき、これらの複数のノード自体もまた複数のデータソースに依存するため、障害耐性が高まります。ソースレベル_と_ノードオペレーターレベルでの分散化は非常に重要です。同じソースから取得した情報を提供するオラクルノードのネットワークは、中央集権型オラクルと同じ問題に直面します。

また、ステークベースのオラクルが、データリクエストに迅速に応答しないノードオペレーターをスラッシュすることも可能です。これにより、オラクルノードに対して障害耐性を持つインフラに投資し、迅速にデータを提供するように促すことができます。

高いインセンティブ整合性

分散型オラクルは、オラクルノード間のビザンチン (opens in a new tab)的な振る舞いを防ぐために、さまざまなインセンティブ設計を実装しています。具体的には、_帰属性_と_説明責任_を実現します：

分散型オラクルのノードに対しては、データリクエストに対してレスポンスを提供する際に当該データに対する証明が要求される場合が多いです。この署名情報は、データをリクエストする際に信頼性が低いオラクルノードを排除するなど、オラクルノードの過去の行動を評価する際に有益です。一例として、Witnetのアルゴリズム評価システム (opens in a new tab)が挙げられます。
すでに述べたように、分散型のオラクルでは、提出するデータの真実性に対するノード本人の確信に対してステーキングを義務付ける場合があります。このノードのクレームが確認されれば、このステークは、正直な行動への報酬と共に返却されます。ただし、提出した情報が正しくない場合には没収される可能性があるため、一定の説明責任を担保する手段となります。

スマートコントラクトにおけるオラクルのアプリケーション

以下に、イーサリアムにおけるオラクルの一般的なユースケースを紹介します：

金融データの取得

分散型金融（DeFi）アプリケーションは、資産のピアツーピアの貸し借りや取引を可能にします。これらのサービスを提供するには、為替データ（仮想通貨における法定通貨建ての価値を算出するため、あるいはトークンの価格を比較するため）や、資本市場に関するデータ（トークン化された金や米ドル等の資産の価値を算出するため）など、様々な金融情報を取得する必要があります。

例えばDeFiの貸出プロトコルでは、担保として預け入れられた様々な資産（例：ETH）の現在の市場価格をクエリできる機能が必要になります。これは、コントラクトに対して、担保資産の価値を評価し、ユーザーがシステムからどれだけ借入可能かを決定する機能を提供するためです。

DeFiで人気のある「価格オラクル」（しばしばそう呼ばれる）には、Chainlink Price Feeds、CompoundプロトコルのOpen Price Feed (opens in a new tab)、Uniswapの時間加重平均価格（TWAP） (opens in a new tab)、Maker Oracles (opens in a new tab)などがあります。

ビルダーは、プロジェクトにこれらの価格オラクルを組み込む前に、導入に伴う注意事項についてよく理解しておく必要があります。こちらの記事 (opens in a new tab)では、前述の価格オラクルのいずれかを使用する際に考慮すべき点について、詳細な分析を提供しています。

以下のサンプルコードは、Chainlinkの価格フォードを使用してスマートコントラクト上で最新のETH価格を取得するものです：

1pragma solidity ^0.6.7;
2
3import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
4
5contract PriceConsumerV3 {
6
7    AggregatorV3Interface internal priceFeed;
8
9    /**
10     * Network: Kovan
11     * Aggregator: ETH/USD
12     * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
13     */
14    constructor() public {
15        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
16    }
17
18    /**
19     * Returns the latest price
20     */
21    function getLatestPrice() public view returns (int) {
22        (
23            uint80 roundID,
24            int price,
25            uint startedAt,
26            uint timeStamp,
27            uint80 answeredInRound
28        ) = priceFeed.latestRoundData();
29        return price;
30    }
31}
すべて表示

検証可能なランダム性の生成

ブロックチェーンベースのゲームや宝くじなど、一部のブロックチェーン・アプリケーションでは、適切に機能するために高度な予測不可能性およびランダム性が要求されます。しかし、ブロックチェーンは決定論的な実行という特性を持つため、ランダム性を獲得する手段がありません。

元々のアプローチはblockhashのような疑似乱数暗号関数を使用することでしたが、これらはマイナーによって操作される可能性 (opens in a new tab)がありました。プルーフ・オブ・ワークアルゴリズムを解決します。また、イーサリアムのプルーフ・オブ・ステークへの移行により、開発者はオンチェーンのランダム性のためにblockhashに頼ることができなくなりました。その代わりに、ビーコンチェーンのRANDAOメカニズム (opens in a new tab)が代替のランダム性のソースを提供します。

ランダムな値をオフチェーンで生成してオンチェーンに送信することも可能ですが、そうするとユーザーに高い信頼性が要求されます。ユーザーは、生成された値が本当に予測不可能なメカニズムによって生成され、転送に伴う改変が生じていないことを信じなければならないためです。

オフチェーン計算用に設計されたオラクルは、プロセスの予測不可能性を証明する暗号学的証明とともに、オフチェーンで安全に生成したランダムな結果をオンチェーンでブロードキャストすることで、この問題を解決します。一例として、予測不可能な結果に依存するアプリケーションのための信頼できるスマートコントラクトを構築するのに役立つ、証明可能で公正かつ改ざん防止の乱数生成器（RNG）であるChainlink VRF (opens in a new tab)（検証可能なランダム関数）があります。

イベントの結果を取得する

オラクルを活用することで、現実世界で発生したイベントに応答できるスマートコントラクトを手軽に開発できます。オラクルサービスは、コントラクトがオフチェーンコンポーネントを介して外部APIに接続し、それらのデータソースから情報を消費できるようにすることで、これを可能にします。例えば、前述の予測dappは、信頼できるオフチェーンソース（例：AP通信）から選挙結果を返すようオラクルに要求することがあります。

オラクルを使用して現実世界の結果に基づいてデータを取得することで、斬新なユースケースを可能になります。ユースケースの例として、分散型保険商品が効果的に機能させることがあります。この分野では、天気、災害などに関する正確な情報を必要としています。

スマートコントラクトの自動化

スマートコントラクトは、自動的に実行される訳ではありません。正確に言うと、スマートコントラクトのコードを実行するには、外部所有アカウント（EOA）まあたはその他のコントラクトアカウントが適切な関数をトリガーする必要があります。大部分の場合、スマートコントラクトに含まれる関数の大部分は公開されており、EOAおよびその他のコントラクトにより呼び出すことができます。

しかし、コントラクト内には、他のユーザーからはアクセスできない_プライベート関数_も存在します。これらは、dapp全体の機能にとって非常に重要です。例としては、ユーザーのために定期的に新しいNFTをミントする mintERC721Token() 関数、予測市場で支払いを授与する関数、またはDEXでステークされたトークンのロックを解除する関数などが挙げられます。

開発者は、アプリケーションのスムーズな動作を保証するために、これらの関数を一定の間隔でトリガーする必要があります。しかし、このようなアプローチでは、開発者が反復的なタスクのために費やす時間が増加してしまうため、スマートコントラクトを自動的に実行するアプローチが有益なのです。

一部の分散型オラクルネットワークは自動化サービスを提供しており、これによりオフチェーンのオラクルノードがユーザーによって定義されたパラメータに従ってスマートコントラクト関数をトリガーできます。このような自動化サービスは通常、ターゲットとなるコントラクトを当該のオラクルサービスに「登録」する必要がある他、オラクルの運用者に対して手数料を支払い、当該コントラクトをトリガーする際の条件または時間を指定する必要があります。

ChainlinkのKeeper Network (opens in a new tab)は、スマートコントラクトが定期的なメンテナンス作業を、信頼性を最小限に抑え、分散化された方法で外部委託するためのオプションを提供します。コントラクトをKeeper互換にし、Upkeepサービスを利用する方法については、公式のKeeperのドキュメント (opens in a new tab)をお読みください。

ブロックチェーンオラクルの使い方

イーサリアムのDappで使用できるオラクル・アプリケーションとしては、以下があります：

Chainlink (opens in a new tab) - Chainlinkの分散型オラクルネットワークは、改ざん防止の入力、出力、および計算を提供し、あらゆるブロックチェーン上の高度なスマートコントラクトをサポートします。

RedStone Oracles (opens in a new tab) - RedStoneは、ガスを最適化したデータフィードを提供する分散型モジュラー型オラクルです。リキッドステーキングトークン（LST）、リキッドリステーキングトークン（LRT）、ビットコインステーキングデリバティブなど、新しい資産の価格フィード提供に特化しています。

Chronicle (opens in a new tab) - Chronicleは、真にスケーラブルでコスト効率の高い、分散型かつ検証可能なオラクルを開発することで、オンチェーンでのデータ転送における現在の制約を克服します。

Witnet (opens in a new tab) - Witnetは、パーミッションレス、分散型、検閲耐性のあるオラクルで、スマートコントラクトが強力な暗号経済学的保証をもって現実世界のイベントに反応するのを助けます。

UMA Oracle (opens in a new tab) - UMAのオプティミスティック・オラクルにより、スマートコントラクトは保険、金融デリバティブ、予測市場など、さまざまなアプリケーションのためにあらゆる種類のデータを迅速に受け取ることができます。

Tellor (opens in a new tab) - Tellorは、あなたのスマートコントラクトが必要なときにいつでも簡単にデータを取得できる、透明でパーミッションレスなオラクルプロトコルです。

Band Protocol (opens in a new tab) - Band Protocolは、現実世界のデータとAPIを集約し、スマートコントラクトに接続するクロスチェーンデータオラクルプラットフォームです。

Pyth Network (opens in a new tab) - Pyth Networkは、改ざん防止、分散化、自己持続可能な環境で、継続的な実世界のデータをオンチェーンで公開するために設計されたファーストパーティの金融オラクルネットワークです。

API3 DAO (opens in a new tab) - API3 DAOは、スマートコントラクト向けの分散型ソリューションにおいて、ソースの透明性、セキュリティ、スケーラビリティを向上させるファーストパーティのオラクルソリューションを提供しています。

Supra (opens in a new tab) - すべてのブロックチェーン（パブリック（L1およびL2）またはプライベート（企業））を相互にリンクする、垂直統合されたクロスチェーンソリューションのツールキットで、オンチェーンおよびオフチェーンのユースケースで使用できる分散型オラクル価格フィードを提供します。

Gas Network (opens in a new tab) - ブロックチェーン全体にリアルタイムのガス価格データを提供する分散型オラクルプラットフォームです。 Gas Networkは、主要なガス価格データプロバイダーからのデータをオンチェーンに持ち込むことで、相互運用性の推進を支援しています。 Gas Networkは、イーサリアムメインネットや多くの主要なL2を含む35以上のチェーンのデータをサポートしています。

参考リンク

記事

ブロックチェーンオラクルとは何か？ (opens in a new tab) — Chainlink
ブロックチェーンオラクルとは何か？ (opens in a new tab) — Patrick Collins
分散型オラクル：包括的な概要 (opens in a new tab) — Julien Thevenard
イーサリアムでブロックチェーンオラクルを実装する (opens in a new tab) – Pedro Costa
スマートコントラクトはなぜAPIコールができないのか？ (opens in a new tab) — StackExchange
価格オラクルを使いたいあなたへ (opens in a new tab) — samczsun

動画

オラクルとブロックチェーンの有用性の拡大 (opens in a new tab) — Real Vision Finance

チュートリアル

Solidityでイーサリアムの現在価格を取得する方法 (opens in a new tab) — Chainlink
オラクルデータの利用 (opens in a new tab) — Chronicle

プロジェクト実例

Solidityによるイーサリアム向けの完全なChainlinkスタータープロジェクト (opens in a new tab) — HackBG