はじめに

ブロックチェーンオラクルの仕組みについて、疑問に思ったままの方は意外に多いかもしれません。

日本語の詳しい記事が、意外に少ないと自分は感じております。

ethereum.orgにてオラクルに関する記事が、数か月前に大幅に改訂されました。

現在、内容が非常に充実しています。

しかし、翻訳ボランティアが足りておらず、日本語記事の公開には至っておりません。

有益な情報なので今回は、下訳した内容を要約してお伝えします。

オラクルとは

オラクルは、以下２つのことを可能にする仕組みです。

1. ブロックチェーンの外にある現実世界のデータを利用可能にする

ブロックチェーンの外にある情報をブロックチェーン内に取り込みます。

スマートコントラクトは、この仕組みを使って、ブロックチェーンの外の情報 (例えば、相場情報、天気情報、選挙結果、ニュースの結果など）を利用することができます。

2. ブロックチェーン内の情報をブロックチェーン外で利用可能にする

ブロックチェーン内の結果を現実世界に伝えます (例えば、イーサリアムで料金を支払ったら、乗り物などのロックを解除して動作可能にするなど) 。

このように、オラクルは、ブロックチェーンと現実世界のブリッジ（橋）として機能します。

オラクルの分類方法

オラクルは、以下のようにさまざまな観点で分類することができます。

• データソース（情報源）による分類：相場情報などのソースを1つまたは複数エンティティから取得するものがあります。
  
  
• 信頼モデルによる分類：集中型 (Centralized) または分散型(Decentralized)の信頼モデルがあります。
  
  
• システムアーキテクチャ：即時読み取り型、出版-購読型、リクエスト-レスポンス型などのアーキテクチャがあります。
  
  
• 区分による分類
  
  
  • 出力オラクル：ブロックチェーンからアプリケーションに情報を送信します。
    
    
  • 入力オラクル：外部からデータを取得してオンチェーンで利用します。
    
    
  • 計算オラクル：オフチェーンで計算タスクを実行します。

オラクルが必要な理由

スマートコントラクトで、ブロックチェーンに保存されていない外部の情報を利用してトランザクションを実行できるとしましょう、そうすると各ノードで異なる結果を返す可能性があります。

例えば、相場情報などは取得するタイミングで価格が違います。ノードが、そのデータを取得するタイミングで結果が変わってしまいます。

異なる結果をを返すと、ブロックチェーンは、コンセンサスに至ることができません。

これを解決するために、オラクルが、外界（オフチェーン）の情報を取得してブロックチェーンに保存します。

スマートコトラクトは、その情報を取得して計算することでコンセンサスが損なわれることなく状態変化が可能になります。

外の情報を取り入れつつコンセンサスに至るには、オラクルの仕組みが必要です。

オラクルの構成

オラクルは、以下のコンポーネントで構成されています。

• オンチェーンコントラクト：他のスマートコントラクトからデータのリクエストを受け取り、オラクルノードというオフチェーン（外部）にあるコンポーネントに渡します。
  
  
• オラクルノード：API (アプリケーションプログラミングインターフェース）を使ってデータをクエリし、リクエストされたデータをオンチェーンコントラクトのストレージに保存するトランザクションを送信します。
  
  
  

オラクル問題

オラクル問題とは、ブロックチェーンオラクルを使用してスマートコントラクトに対して入力値を送信する際に生じる問題のことです。

オラクルでは、情報の正確性が重要です。これをトラストレスに実現する必要があります。

問題例）

• オラクルが取得する情報源が正しいのか、改ざんされていないのか確認するにはどうするのか？
  
  
• データが常に利用可能で定期的に更新するにはどうすればよいか？
  
  

オラクルによって、オラクル問題を解決するアプローチは違います。

正確性、可用性、インセンティブ両立性の課題をどう扱うかによって評価します。

正確性、可用性、インセンティブ両立性の定義は、実際の記事を参考にしてください。

オラクルサービスの仕組み

オラクルサービスは、以下のような構成になっています。

• ユーザー：
  
  オラクルサービスにとってユーザーは、オラクルのデータを利用するスマートコントラクトです。
  
  
• オラクルコントラクト：
  
  オラクルサービスのを構成するオンチェーンのコンポーネントです。
  
  
  • 他のコントラクト（ユーザー）からのデータリクエストをリッスンしています。
    
    
  • データのクエリをオラクルノードへリレーします。
    
    
  • クライアントのコントラクトへデータをブロードキャストします。データを集計して送信する場合もあります。
    
    
• オラクルノード：
  
  オラクルサービスのオフチェーンのコンポーネントで、APIなどを使って、外部ソースから情報を抽出します。
  
  オラクルコントラクトに情報を配置します。情報の有効性と完全性の証明に「真正性証明」を利用します。

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

最も使われているメジャーなパターンは以下の２つです。

1. 出版-購読型のオラクル

他のコントラクトが定期的に読むことができるデータフィードを公開します。

例えば、最新のETH-USDの価格情報を提供する場合に適しています。

2. リクエスト-レスポンス型のオラクル

クライアントコントラクト（ユーザー）は、任意の情報をクエリします。クエリをオフチェーンのオラクルノードで処理します。

以下条件に適しています。

• データセットが大きくスマートコントラクトのストレージに保存できない
  
  
• ユーザーがいずれかの時点のごく一部の情報が必要

オラクルの信頼モデル

集中型オラクル

単一のエンティティによって制御されています。これには、以下問題があります。

• 低い正確性保証：ハッキングなどで情報が改ざんされやすい。
  
  
• 低い可用性：一台落ちるとサービスが止まってしまう。
  
  
• 低いインセンティブ両立性：正直な情報提供へのインセンティブ設計が不十分になります。
  

上記のように、集中型オラクルは、オラクル問題を上手く解決できません。

分散型オラクル

複数の情報源、複数のオラクルノードにより分散し、単一障害点を排除したオラクルです。以下メリットがあります。

理想を追求すれば、パーミッションレス、トラストレス、管理者フリーにできます。

中には分散型オラクルネットワークを構成し、スタンドアロンブロックチェーンによる分散化を行い、不正行為を罰するコンセンサスメカニズムを定義しているものもあります。

以下にてメリットを挙げます。

1. 高い正確性保証

真正性証明を利用し、複数のエンティティでオフチェーンデータの有効性に集合的に合意することが可能です。

真正性証明の例

• トランスポート層セキュリティ (TLS) 証明：セッションの内容が変更されていないことを確認する。
  
  
• 信頼された実行環境 (TEE) アテステーション：ホストシステムから分離されている計算環境で情報が無傷で機密な状態の保持を証明する。
  
  
• コンセンサスベースの情報検証：複数のオラクルノードに情報をクエリし、不一致が発生した場合に対処する。
  
  
• データの正確性の投票、ステーキング：トークンを利用した経済合理性の仕組み。
  
  
• シェリングポイント・メカニズム：ゲーム理論を利用した仕組み。

詳細は、実際の記事を参考にしてください。

2. 高可用性

オフチェーンの情報源と、オンチェーンの情報転送するノードの両方を分散化していることで耐障害性が保証できます。しかし、情報ソースを分散化しないと本質的に集中型オラクルと同じ情報汚染の問題が生じるので注意が必要です。

詳細は、実際の記事を参考にしてください。

3. 優れたインセンティブ両立性

分散型オラクルでは、以下のように優れたインセンティブデザインを実装できます。

• 信頼性の低いオラクルノードをフィルタリングする仕組み
  
  
• 正直なサービスを提供するノードへの報酬
  
  
• 間違っている情報を提供するノードへのステークのスラッシング
  
  

詳細は、実際の記事を参考にしてください。

オラクルアプリケーションの例

• 金融取引データの取得：Uniswapの時価加重平均価格 (TWAP)等
  
  
  
• 検証可能なランダム性の生成：Chainlink VRF (検証可能なランダム関数) 等
  
  
  例）ギャンブルなど、ブロックチェーンベースのゲームで利用
  
  
• イベントの結果を取得：保険スマートコントラクトが利用者に支払うための気象データ、災害報告等
  
  
  例) オラクルが特定の気象現象が発生したと決定すると、農作物保険スマートコントラクトによってユーザーへ保険金が支払われる。
  
  
• スマートコントラクトの自動化：スマートコントラクトは自動実行機能がありません。このオラクルにより、スマートコントラクトの自動化が可能です。
  
  例）Chainlink Automationなどのオラクルを使いスマートコントラクトの自動実行が可能です。

詳細は、実際の記事を参考にしてください。

分散型オラクルの図

以下に上記内容を含め、図にまとめてみました、間違っておりましたらご指摘いただけると幸いです。

実在するオラクルサービスの一覧

実際の記事にオラクルサービスの一覧があります。参考にしてください。

まとめ

以上、オラクルについてコンパクトにまとめました。

オラクルによって、ブロックチェーンアプリケーションのユースケースを拡張できます。

また、需要のあるオラクルサービスを構築することで継続的にトークン収益を得る仕組みが開発できそうです。

しかし、オラクル問題をどう扱うかによりますが、分散型オラクルの構築は難易度が非常に高いと思われます。

詳細内容に興味のある方は、ethereum.orgの本記事をご参照ください。

日本語訳に興味ある方は、現在の翻訳をCrowdinにて見ることができます。

また、ethereum.orgでは、翻訳ボランティアを募集しています。

翻訳ボランティアに興味をお持ちのかたは、こちらを参考にしてください。

翻訳ボランティアへの参加、心よりお待ちしております！