これからスマートコントラクトを活用したブロックチェーンネットワークは急激に拡大していくことを考えると、それに伴い必要なデータも増えていきます。なぜなら現実社会のさまざまな産業にまたがってブロックチェーンが用いられると、それらの産業におけるデータがブロックチェーン内部で必要になるからです。
このようなネットワーク外部に存在するデータを内部に引っ張ってきてくれるシステムをオラクル(Oracle)と呼びます。（データベースのオラクルとは別物です）オラクルがブロックチェーンと現実社会の橋渡しとなって、柔軟なブロックチェーンの活用を可能にしてくれるのです。
つまり、オラクルが発達すると、サプライチェーン、ヘルスケア、農業、音楽、飛行機の予約までさまざまな産業において、スマートコントラクトおよびブロックチェーンの導入が加速することが期待できます。
そこで、当記事では今後非常に重要なシステムになってくるであろうオラクルの現状と課題点、そして具体的なオラクルシステムの事例を解説していきます。
オラクルとは
オラクルとは、ブロックチェーンネットワーク外部の情報を取得してくれるシステムです。ブロックチェーンとインターネットの間を橋渡ししてくれるプラットフォームとも表現できます。
つまり、ネットワーク内部の情報に関係のない外部情報を得るためにオラクルは使用されるのです。
それでは、どのようなときに外部情報が必要になるのでしょうか。これは分散型予測市場アプリケーションをイメージすると一番分かりやすいです。
例えば、「来週末のサッカー試合でチームAとチームBのどちらが勝つのか」を予測する市場では外部データが必ず必要になります。なぜなら、サッカー試合のデータはブロックチェーンネットワーク内部には存在しないからです。
しかし、スマートコントラクトの実行や合意形成はブロックチェーンネットワーク内部で行う必要があるので、このサッカー試合に関する外部データを内部に引っ張ってくる必要があります。
このようなときにオラクルシステムが活躍し、ネットワーク内部には存在しない外部データについてスマートコントラクトを実行することができるようになるのです。
「外部データの取得」を考えるとただ単にAPIで参照するだけで簡単に行うことができると感じますが、ブロックチェーンの分散型ネットワークの場合ではとても難しくなります。
なぜなら、「その外部データが本当に正しいのか」ということを判断することがとても難しいからです。例えば、そのオラクルシステムは本当に正しい情報源を参照しているのでしょうか。正しい情報源を参照できていたとしても、その情報自体は正しいのでしょうか。情報自体が正しい場合でも、その正しい情報からネットワーク内部で参照するための正しい外部データを生成できているのでしょうか。
さらに、「そのオラクルが正しい情報を持ってきた」ということを分散型ネットワークでどうやって「正しい情報」と判断すればいいのでしょうか。どうやって「正しい情報」であると分散型ネットワークで合意形成を行えばいいのでしょうか。
このようにオラクルがブロックチェーンとインターネットの橋渡しになるためには解決すべきさまざまな課題点があるのです。
集中型オラクルと分散型オラクル
オラクルとは、外部データを取得してくれるシステムであると表現しました。このオラクルはさらに集中型オラクル(Centralized oracle)と分散型オラクル(Decentralized oracle)に分けることができます。
集中型オラクルは、オラクルがひとつの主体（システム）によって管理されています。一方、分散型オラクルではネットワーク全体で分散して管理されることになります。
集中型オラクルは、あるひとつの主体が管理するのでとても効率的に外部データを参照することができます。なぜなら、その管理主体が責任を持って、外部データの情報源と情報自体の「正しさ」を担保してくれるからです。
ネットワーク参加者はその集中型オラクルを正当であると「信頼」するだけで、効率的なオラクルシステムが実現することになります。
実際、現状のオラクルは99％以上が集中型オラクルであり実際に動いているものは集中型オラクルのみです。しかし、この集中型オラクルには大きな問題点があります。
それはオラクルシステムを「信頼」しなければならないことです。そのオラクルが絶対に正しい外部データを持ってきてくれることを信頼し、絶対に不具合を起こすことはない、と信頼しなければならないのです。
従来のシステムではひとつの管理主体を信頼することは当たり前のことでした。しかし、これからのシステムでは分散化が求められます。ネットワークが分散化しているのにオラクルシステムだけ集中化していてはネットワーク全体が分散化していることにはならないでしょう。
そのため現在、分散型オラクルの開発が積極的に行われているのです。
分散型オラクルの難しさ
このような「集中型」VS「分散型」の関係は仮想通貨取引所と同様の問題に見えますが、分散型オラクルの実現は分散型取引所(DEX)よりも実現が難しいと考えられます。
なぜなら、分散型オラクルネットワークを維持するためのインセンティブ設計がとても難しいからです。
例えば、0xプロジェクトというDEXでは取引手数料を運用者に与えることでDEXを動かすためのインセンティブを与えています。しかし、分散型オラクルでは「取引」をするわけではないので手数料は得られず、分散型オラクルを運用するインセンティブを与えることができないのです。
参考：分散型取引所(DEX)で高速かつ安価な取引を目指す「0xプロジェクト」とは
他にも、外部データの信憑性を確認、合意形成するのに時間がかかってしまうことなどの課題点もあげられます。
このような分散型オラクルの課題点に対して、ChainLinkでは分散型オラクルを維持するためのChainLinkネットワークを構成し、LINKトークンの経済圏を作ることでノードにインセンティブを与えようとしています。
複数の異なるデータソースから複数のオラクルノードにより実行されることで分散型オラクルを実現していこうというアプローチをしているのです。
それでは、OraclizeやGnosisなどにおける実際のオラクルの事例を見ていきましょう。
オラクルの事例
Oraclize
現状、一番メジャーなオラクルシステムがOraclizeになります。Oraclizeでは下図のように信憑性の証明(authenticity proof)という暗号学的アルゴリズムに基いて外部データの信憑性を担保しています。
WEBにおける情報の信憑性を証明するTLSNotary証明など複数のアルゴリズムを組み合わせることで正しいデータの情報源から正しいデータをネットワークに送れるように工夫しているのです。
(source: Introducing the ProofShield)
また、以前までは信憑性の証明はオフチェーンでのみ可能でした。なぜなら、この証明プロセスはとても複雑でEVMがサポートしきれず、さらにgas（手数料）が高額になってしまうからです。
オラクルにおいてオフチェーンでの証明が問題である理由としては、外部データがスマートコントラクトに届けられた後にそのデータが正しいのか確認する、というプロセス順序になってしまうことがあげられます。
本来であれば、スマートコントラクトに届けられる前にデータの正しさは確認されなければなりません。つまり、オフチェーンでの信憑性の証明はセキュリティ面で問題があります。
そこで、Oraclizeではオンチェーンにおいて信憑性の証明が行えるように改善していこうとしています。複雑なauthenticity proofの結果をProof Shieldという方法でよりシンプルな形で出力することでオンチェーンでも処理できるように開発されています。
これにより、ブロックチェーン内部でスマートコントラクトが外部データの正当性を確認することができ、その検証プロセスの結果に基いてデータが正しければネットワークにブロードキャストし、正しくなければ廃棄するといったことが可能になるのです。
Gnosis
Gnosisはイーサリアムブロックチェーンをベースとして、分散型予測市場のプラットフォームを目指しているプロジェクトです。冒頭でも例をあげたように予測市場ではオラクルシステムが非常に重要であるので、Gnosisでも特徴的なオラクルが導入されています。
Gnosisでは、複数の異なるタイプのオラクルを導入してそれらを組み合わせることで外部データの信憑性、データ取得の効率性を高めていく方針に重点を置いています。
(source: GNOSIS white paper)
オンチェーンオラクル（オンチェーンに関する情報の取得）、集中型オラクル、分散型オラクルを組み合わせてハイブリッドオラクルとして機能させているのです。（ただ現状は集中型オラクルしか利用されていません）
さらに、上述したOraclizeなどの外部オラクルシステムを積極的に導入していくことでハイブリッドオラクルの機能を高めていこうとしています。
ここでは、Gnosisの分散型オラクルはどのような仕組みで動いているのか見ていきましょう。Gnosisの分散型オラクルは下図のようにネットワークでの投票（賭け）により「分散型」を実現しようとしています。
(source: GNOSIS white paper)
もしオラクルの結果に対して異議がある場合、オラクルの結果が提示されて12時間以内に合計で100ETH以上の投票が集まればオラクルの投票プロセスに移行することができます。
ここでは、ユーザーは自分の正しいと思うオラクルの結果に投票（トークンを賭ける）することができます。そして、一方の結果の投票数が多い状態が24時間以上続くとその結果がオラクルの結果データとして、ネットワークにブロードキャストされるのです。
出力結果となる選択肢に投票したユーザーは賭けた金額だけ報酬がもらえ、他方の少数派の選択肢に投票したユーザーは損をすることになります。
しかし、このような投票システムによる分散型オラクルには致命的な問題点があげられます。
それは、富める者が投票結果を操作し、結果的にオラクルが取得する外部データを変更できてしまうことです。例えば複数の攻撃者が結託して、誤っている選択肢に多くのトークンを投票すると、その選択肢が多数派になりオラクルの結果データに反映されることになってしまいます。
さらに、攻撃者は賭けに勝つことができたことになるので儲けももらえてしまいます。つまり、このような投票システムでは攻撃することにインセンティブを与えてしまっていることになります。
通常のユーザーにとっても自身の資金が減るリスクを負って、本当は正しいはずの少数派の選択肢に賭けるよりも攻撃者に乗って不正な多数派の選択肢に賭けた方が儲けることができるのです。
なので、現状Gnosisでは集中型オラクルを使用しています。ただ、現状の予測市場は外部データを簡単に取得できる市場に限られているので集中型オラクルで十分であるとも言えます。
これから外部データの取得が難しい予測市場であったり、結果が曖昧な場合などはより柔軟な分散型オラクルが必要不可欠になるでしょう。
参考：トークンを使った予測市場の実現を目指す「Gnosis」の仕組み
