オラクル

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

スマート・コントラクトにオフチェーンのデータを使用して実行する機能を与えることで、分散型アプリケーション (dapp) の有用性と価値が拡張されます。たとえば、オンチェーンの予測市場は、ユーザーの予測を検証するために使用する結果に関する情報を提供するためにオラクルに依存しています。アリスが次の米国大統領になる人物に20 ETHを賭けたとします。その場合、予測市場のdappは、選挙結果を確認し、アリスが支払いを受ける資格があるかどうかを判断するためにオラクルを必要とします。

前提条件

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

ブロックチェーン・オラクルとは何ですか？

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

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

オラクルは、データソース（単一または複数）、トラストモデル（中央集権型または分散型）、およびシステムアーキテクチャ（即時読み取り、パブリッシュ・サブスクライブ、およびリクエスト・レスポンス）に基づいて異なります。また、オンチェーンのコントラクトで使用するために外部データを取得するか（入力オラクル）、ブロックチェーンからオフチェーンのアプリケーションに情報を送信するか（出力オラクル）、またはオフチェーンで計算タスクを実行するか（計算オラクル）に基づいてオラクルを区別することもできます。

なぜスマート・コントラクトにはオラクルが必要なのですか？

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

しかし、イーサリアムが決定論的であることを考えると、スマート・コントラクトを使用して人々の間の合意を強制することは簡単ではありません。決定論的システム (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にクエリを実行し、リクエストされた情報をブロックチェーンに保存できるシンプルなオラクル・サービスです。

pragma solidity >=0.4.21 <0.6.0;

contract Oracle {
  Request[] requests; //コントラクトに対して行われたリクエストのリスト
  uint currentId = 0; //増加するリクエストID
  uint minQuorum = 2; //最終結果を宣言する前に受け取るべき最小レスポンス数
  uint totalOracleCount = 3; // ハードコードされたオラクル数

  // 一般的なAPIリクエストを定義する
  struct Request {
    uint id;                            //リクエストID
    string urlToQuery;                  //API URL
    string attributeToFetch;            //レスポンスで取得するJSON属性（キー）
    string agreedValue;                 //キーからの値
    mapping(uint => string) answers;     //オラクルによって提供された回答
    mapping(address => uint) quorum;    //回答をクエリするオラクル（1=オラクルはまだ投票していない、2=オラクルは投票済み）
  }

  //ブロックチェーンの外部のオラクルをトリガーするイベント
  event NewRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch
  );

  //最終結果に関するコンセンサスが得られたときにトリガーされる
  event UpdatedRequest (
    uint id,
    string urlToQuery,
    string attributeToFetch,
    string agreedValue
  );

  function createRequest (
    string memory _urlToQuery,
    string memory _attributeToFetch
  )
  public
  {
    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
    Request storage r = requests[length-1];

    // ハードコードされたオラクルのアドレス
    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;

    // ブロックチェーンの外部のオラクルによって検出されるイベントを起動する
    emit NewRequest (
      currentId,
      _urlToQuery,
      _attributeToFetch
    );

    // リクエストIDを増やす
    currentId++;
  }

  //回答を記録するためにオラクルによって呼び出される
  function updateRequest (
    uint _id,
    string memory _valueRetrieved
  ) public {

    Request storage currRequest = requests[_id];

    //オラクルが信頼できるオラクルのリストにあるか確認する
    //そしてオラクルがまだ投票していないか
    if(currRequest.quorum[address(msg.sender)] == 1){

      //このアドレスが投票済みであることをマークする
      currRequest.quorum[msg.sender] = 2;

      //空き位置が見つかるまで回答の「配列」を反復処理し、取得した値を保存する
      uint tmpI = 0;
      bool found = false;
      while(!found) {
        //最初の空きスロットを見つける
        if(bytes(currRequest.answers[tmpI]).length == 0){
          found = true;
          currRequest.answers[tmpI] = _valueRetrieved;
        }
        tmpI++;
      }

      uint currentQuorum = 0;

      //オラクルのリストを反復処理し、十分なオラクル（最小クオラム）が
      //現在のものと同じ回答に投票したか確認する
      for(uint i = 0; i < totalOracleCount; i++){
        bytes memory a = bytes(currRequest.answers[i]);
        bytes memory b = bytes(_valueRetrieved);

        if(keccak256(a) == keccak256(b)){
          currentQuorum++;
          if(currentQuorum >= minQuorum){
            currRequest.agreedValue = _valueRetrieved;
            emit UpdatedRequest (
              currRequest.id,
              currRequest.urlToQuery,
              currRequest.attributeToFetch,
              currRequest.agreedValue
            );
          }
        }
      }
    }
  }
}

オラクル・ノード

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

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

計算オラクルも、ガス・コストやブロック・サイズの制限を考慮するとオンチェーンで実行するのが非現実的な計算タスクを実行するために、オフチェーンのノードに依存しています。たとえば、オラクル・ノードは、検証可能なランダムな数値を生成するタスク（ブロックチェーンベースのゲームなど）を課される場合があります。

オラクルのデザインパターン

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

このタイプのオラクルは、他のコントラクトが情報を定期的に読み取ることができる「データフィード」を公開します。この場合のデータは頻繁に変更されることが予想されるため、クライアント・コントラクトはオラクルのストレージ内のデータの更新をリッスンする必要があります。例としては、最新のETH-USDの価格情報をユーザーに提供するオラクルがあります。

リクエスト・レスポンス・オラクル

リクエスト・レスポンスのセットアップにより、クライアント・コントラクトは、パブリッシュ・サブスクライブ・オラクルによって提供されるデータ以外の任意のデータをリクエストできます。リクエスト・レスポンス・オラクルは、データセットが大きすぎてスマート・コントラクトのストレージに保存できない場合や、ユーザーが特定の時点でデータの小さな部分しか必要としない場合に最適です。

パブリッシュ・サブスクライブ・モデルよりも複雑ですが、リクエスト・レスポンス・オラクルは基本的に前のセクションで説明したものです。オラクルには、データ・リクエストを受け取り、処理のためにオフチェーンのノードに渡すオンチェーン・コンポーネントがあります。

データ・クエリを開始するユーザーは、オフチェーンのソースから情報を取得するコストを負担する必要があります。クライアント・コントラクトはまた、リクエストで指定されたコールバック関数を介してレスポンスを返す際にオラクル・コントラクトで発生するガス・コストをカバーするための資金を提供する必要があります。

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

中央集権型オラクル

中央集権型オラクルは、オフチェーンの情報を集約し、リクエストに応じてオラクル・コントラクトのデータを更新する責任を負う単一のエンティティによって制御されます。中央集権型オラクルは、単一の信頼できる情報源に依存しているため効率的です。独自のデータセットが、広く受け入れられている署名とともに所有者によって直接公開される場合には、より適切に機能する可能性があります。ただし、次のような欠点もあります。

低い正確性の保証

中央集権型オラクルでは、提供された情報が正しいかどうかを確認する方法がありません。「評判の良い」プロバイダーであっても、不正を働いたりハッキングされたりする可能性があります。オラクルが破損した場合、スマート・コントラクトは不正なデータに基づいて実行されます。

乏しい可用性

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

乏しいインセンティブの互換性

中央集権型オラクルは多くの場合、データプロバイダーが正確で変更されていない情報を送信するためのインセンティブが不十分に設計されているか、存在しません。正確性に対してオラクルに支払うことは、誠実さを保証するものではありません。この問題は、スマート・コントラクトによって制御される価値の量が増加するにつれて大きくなります。

分散型オラクル

分散型オラクルは、単一障害点を排除することで中央集権型オラクルの制限を克服するように設計されています。分散型オラクル・サービスは、ピア・ツー・ピア・ネットワーク内の複数の参加者で構成されており、スマート・コントラクトに送信する前にオフチェーンのデータについてコンセンサスを形成します。

分散型オラクルは（理想的には）パーミッションレスで、トラストレスであり、中央の当事者による管理から解放されているべきです。しかし現実には、オラクル間の分散化はスペクトルの上にあります。誰でも参加できる半分散型のオラクル・ネットワークもありますが、過去のパフォーマンスに基づいてノードを承認および削除する「所有者」が存在します。完全に分散化されたオラクル・ネットワークも存在します。これらは通常、スタンドアロンのブロックチェーンとして実行され、ノードを調整し、不正行為を罰するための定義されたコンセンサス・メカニズムを備えています。

分散型オラクルを使用すると、次のような利点があります。

高い正確性の保証

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

真正性の証明

真正性の証明は、外部ソースから取得した情報の独立した検証を可能にする暗号化メカニズムです。これらの証明は、情報のソースを検証し、取得後のデータの変更の可能性を検出できます。

真正性の証明の例には、次のようなものがあります。

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

Trusted Execution Environment (TEE) アテステーション: Trusted Execution Environment (opens in a new tab) (TEE) は、ホストシステムの運用プロセスから分離されたサンドボックス化された計算環境です。TEEは、計算環境に保存/使用されるアプリケーションコードやデータが、完全性、機密性、および不変性を保持することを保証します。ユーザーは、アプリケーションインスタンスがTEE内で実行されていることを証明するアテステーションを生成することもできます。

特定のクラスの分散型オラクルでは、オラクル・ノードのオペレーターにTEEアテステーションの提供を要求します。これにより、ノードオペレーターがTEE内でオラクルクライアントのインスタンスを実行していることがユーザーに確認されます。TEEは、外部プロセスがアプリケーションのコードやデータを変更したり読み取ったりするのを防ぐため、これらのアテステーションは、オラクル・ノードが情報を無傷で機密に保っていることを証明します。

コンセンサスに基づく情報の検証

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

ただし、分散型オラクルは、複数のオフチェーンのソースから取得した情報の不一致に対処する必要があります。情報の違いを最小限に抑え、オラクル・コントラクトに渡されるデータがオラクル・ノードの集合的な意見を反映するようにするために、分散型オラクルは次のメカニズムを使用します。

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

一部の分散型オラクル・ネットワークでは、参加者がネットワークのネイティブ・トークンを使用して、データ・クエリへの回答（例：「2020年の米国選挙で誰が勝ったか？」）の正確性について投票またはステークすることが求められます。その後、集約プロトコルが投票とステークを集約し、過半数によって支持された回答を有効なものとして採用します。

過半数の回答から逸脱した回答をしたノードは、より正しい値を提供した他のノードにトークンが分配されることでペナルティを受けます。データを提供する前にノードに保証金の提供を強制することは、ノードがリターンの最大化を意図する合理的な経済主体であると想定されるため、誠実な回答を促すインセンティブとなります。

ステーキング/投票はまた、悪意のあるアクターが複数のアイデンティティを作成してコンセンサス・システムを操作するから分散型オラクルを保護します。ただし、ステーキングは「フリーライディング」（オラクル・ノードが他のノードから情報をコピーすること）や「怠惰な検証」（オラクル・ノードが情報を自分で検証せずに過半数に従うこと）を防ぐことはできません。

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

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

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

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

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

シェリングポイント・メカニズムは、分散化を保証しながらオンチェーンのフットプリントを最小限に抑える（送信する必要があるトランザクションは1つだけ）ため、魅力的です。後者が可能なのは、平均値/中央値を生成するアルゴリズムに供給される前に、ノードが提出された回答のリストに署名する必要があるためです。

可用性

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

これにより、オラクル・コントラクトは他のコントラクトからのクエリを実行するために複数のノード（複数のデータソースにも依存している）に依存できるため、フォールトトレランスが保証されます。ソース_および_ノードオペレーターレベルでの分散化は非常に重要です。同じソースから取得した情報を提供するオラクル・ノードのネットワークは、中央集権型オラクルと同じ問題に直面することになります。

ステークベースのオラクルでは、データ・リクエストに迅速に応答しないノードオペレーターをスラッシングすることも可能です。これにより、オラクル・ノードがフォールトトレラントなインフラストラクチャに投資し、タイムリーにデータを提供する強力なインセンティブが働きます。

優れたインセンティブの互換性

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

分散型オラクル・ノードは多くの場合、データ・リクエストに応じて提供するデータに署名することが求められます。この情報は、オラクル・ノードの過去のパフォーマンスを評価するのに役立ち、ユーザーがデータ・リクエストを行う際に信頼できないオラクル・ノードをフィルタリングできるようにします。例としては、Witnetのアルゴリズム・レピュテーション・システム (opens in a new tab)があります。
分散型オラクルは、前述のように、提出するデータの真実性に対する自信にステークを置くことをノードに要求する場合があります。請求が確認された場合、このステークは誠実なサービスに対する報酬とともに返還されます。しかし、情報が不正確な場合はスラッシングされる可能性もあり、これによりある程度の説明責任が提供されます。

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

以下は、イーサリアムにおけるオラクルの一般的なユースケースです。

財務データの取得

分散型金融 (DeFi)アプリケーションは、ピア・ツー・ピアのレンディング、借り入れ、および資産の取引を可能にします。これには多くの場合、為替レートのデータ（暗号資産の法定通貨の価値を計算したり、トークンの価格を比較したりするため）や資本市場のデータ（金や米ドルなどのトークン化された資産の価値を計算するため）など、さまざまな財務情報を取得する必要があります。

たとえば、DeFiのレンディング・プロトコルは、担保として預けられた資産（ETHなど）の現在の市場価格をクエリする必要があります。これにより、コントラクトは担保資産の価値を決定し、システムからどれだけ借り入れることができるかを決定できます。

DeFiで人気のある「プライス・オラクル」（よくそう呼ばれます）には、チェーンリンクのプライス・フィード、Compoundプロトコルのオープン・プライス・フィード (opens in a new tab)、ユニスワップの時間加重平均価格（TWAP） (opens in a new tab)、およびMakerオラクル (opens in a new tab)などがあります。

ビルダーは、これらのプライス・オラクルをプロジェクトに統合する前に、それに伴う注意事項を理解する必要があります。この記事 (opens in a new tab)では、言及されているプライス・オラクルのいずれかを使用する計画を立てる際に考慮すべきことについて詳細な分析を提供しています。

以下は、チェーンリンクのプライス・フィードを使用してスマート・コントラクトで最新のETH価格を取得する方法の例です。

pragma solidity ^0.6.7;

import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";

contract PriceConsumerV3 {

    AggregatorV3Interface internal priceFeed;

    /**
     * ネットワーク: Kovan
     * アグリゲーター: ETH/USD
     * アドレス: 0x9326BFA02ADD2366b30bacB125260Af641031331
     */
    constructor() public {
        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
    }

    /**
     * 最新の価格を返す
     */
    function getLatestPrice() public view returns (int) {
        (
            uint80 roundID,
            int price,
            uint startedAt,
            uint timeStamp,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();
        return price;
    }
}

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

ブロックチェーンベースのゲームや宝くじのスキームなど、特定のブロックチェーン・アプリケーションが効果的に機能するためには、高いレベルの予測不可能性とランダム性が必要です。しかし、ブロックチェーンの決定論的な実行はランダム性を排除します。

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

オフチェーンでランダムな値を生成してオンチェーンに送信することは可能ですが、そうすることでユーザーに高い信頼の要件が課せられます。ユーザーは、その値が予測不可能なメカニズムを介して真に生成され、転送中に変更されなかったと信じなければなりません。

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

イベントの結果の取得

オラクルを使用すると、現実世界のイベントに応答するスマート・コントラクトを簡単に作成できます。オラクル・サービスは、コントラクトがオフチェーンのコンポーネントを通じて外部APIに接続し、それらのデータソースから情報を消費できるようにすることで、これを可能にします。たとえば、前述の予測dappは、信頼できるオフチェーンのソース（AP通信など）から選挙結果を返すようにオラクルにリクエストする場合があります。

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

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

スマート・コントラクトは自動的には実行されません。外部所有アカウント（EOA）または別のコントラクト・アカウントが、コントラクトのコードを実行するための適切な関数をトリガーする必要があります。ほとんどの場合、コントラクトの関数の大部分はパブリックであり、EOAや他のコントラクトから呼び出すことができます。

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

開発者は、アプリケーションをスムーズに実行し続けるために、一定の間隔でそのような関数をトリガーする必要があります。しかし、これは開発者にとってありふれたタスクに費やす時間を増やすことにつながる可能性があり、それがスマート・コントラクトの実行を自動化することが魅力的である理由です。

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

チェーンリンクのキーパー・ネットワーク (opens in a new tab)は、スマート・コントラクトがトラストを最小限に抑えた分散型の方法で定期的なメンテナンスタスクをアウトソーシングするためのオプションを提供します。コントラクトをキーパーと互換性のあるものにし、アップキープ・サービスを使用する方法については、公式のキーパーのドキュメント (opens in a new tab)をお読みください。

ブロックチェーン・オラクルの使用方法

イーサリアムのdappに統合できるオラクル・アプリケーションは複数あります。

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

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

Chronicle (opens in a new tab) - Chronicleは、真にスケーラブルで、費用対効果が高く、分散化され、検証可能なオラクルを開発することで、データをオンチェーンに転送する際の現在の制限を克服します。

Witnet (opens in a new tab) - Witnetは、パーミッションレスで分散化された検閲耐性のあるオラクルであり、強力な暗号経済的保証を備えた現実世界のイベントにスマート・コントラクトが反応するのを支援します。

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

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

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以上のチェーンのデータをサポートしています。

DIA (opens in a new tab) - すべての主要な資産クラスにわたる20,000以上の資産の検証可能なデータフィードを提供するクロスチェーンのオラクル・ネットワークです。DIAは、100以上のプライマリー市場から直接生の取引データを調達し、それをオンチェーンで計算することで、あらゆるユースケースのカスタム構成で完全なデータの透明性と検証可能性を保証します。

Stork (opens in a new tab) - Storkは超低遅延で価格データを提供し、無期限先物市場、レンディング・プロトコル、DeFiエコシステムなど、幅広いユースケースをサポートし、上場時に新しい資産を迅速にサポートします。

参考文献

記事

ブロックチェーン・オラクルとは何ですか？ (opens in a new tab) — チェーンリンク
ブロックチェーン・オラクルとは何ですか？ (opens in a new tab) — パトリック・コリンズ
分散型オラクル：包括的な概要 (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) — チェーンリンク
オラクル・データの消費 (opens in a new tab) — Chronicle
オラクル・チャレンジ (opens in a new tab) - Speedrun Ethereum

プロジェクトの例

Solidityでのイーサリアム向け完全なチェーンリンク・スターター・プロジェクト (opens in a new tab) — HackBG